Note: If using the Weave CNI
Plugin from a prior full install of Weave Net with your
cluster, you must first uninstall it before applying the Weave-kube addon.
Shut down Kubernetes, and on all nodes perform the following:

weave reset

Remove any separate provisions you may have made to run Weave at
boot-time, e.g. systemd units

rm /opt/cni/bin/weave-*

Then relaunch Kubernetes and install the addon as described
above.

Upgrading Kubernetes to version 1.6

In version 1.6, Kubernetes has increased security, so we need to
create a special service account to run Weave Net. This is done in
the file weave-daemonset-k8s-1.6.yaml attached to the Weave Net
release.

Also, the
toleration
required to let Weave Net run on master nodes has moved from an
annotation to a field on the DaemonSet spec object.

If you have edited the Weave Net DaemonSet from a previous release,
you will need to re-make your changes against the new version.

Upgrading the Daemon Sets

For Kubernetes 1.6 and above the DaemonSet definition specifies
Rolling Updates,
so when you apply a new version Kubernetes will automatically restart
the Weave Net pods one by one.

Kubernetes v1.5 and below does not support rolling upgrades of daemon sets,
and so you will need to perform the procedure manually:

Kill each Weave Net pod with kubectl delete and then wait for it to reboot before moving on to the next pod.

Note: In versions prior to Weave Net 2.0, deleting all Weave Net pods at the same time
will result in them losing track of IP address range ownership, possibly leading to
duplicate IP addresses if you then start a new copy of Weave Net.

CPU and Memory Requirements

Kubernetes manages
resources
on each node, and only schedules pods to run on nodes that have enough
free resources.

The components of a typical Kubernetes installation (with the master
node running etcd, scheduler, api-server, etc.) take up about 95% of a
CPU, which leaves little room to run anything else. For all of Weave
Net’s features to work, it must run on every node, including the
master.

The best way to resolve this issue is to use machines with at least
two CPU cores. However if you are installing Kubernetes and Weave Net
for the first time, you may not be aware of this requirement. For this
reason, Weave Net launches as a DaemonSet with a specification that
reserves at least 1% CPU for each container. This enables Weave Net to
start up seamlessly on a single-CPU node.

Depending on the workload, Weave Net may need more than 1% of the
CPU. The percentage set in the DaemonSet is the minimum and not a
limit. This minimum setting allows Weave Net to take advantage of
available CPU and “burst” above that limit if it needs to.

Pod Eviction

If a node runs out of CPU, memory or disk, Kubernetes may decide to
evict
one or more pods. It may choose to evict the Weave Net pod, which will
disrupt pod network operations.

You can reduce the chance of eviction by changing the DaemonSet to
have a much bigger request, and a limit of the same value.

This causes Kubernetes to apply a “guaranteed” rather than a
“burstable” policy.
However a similar request for disk space can not
be made, and so please be aware of this issue and monitor your
resources to ensure that they stay below 100%.

You can see when pods have been evicted via the kubectl get events command

Note: as of version 1.9 of Weave Net, the Network Policy
Controller allows all multicast traffic. Since a single multicast
address may be used by multiple pods, we cannot implement rules to
isolate them individually. You can turn this behaviour off (block
all multicast traffic) by adding --allow-mcast=false as an
argument to weave-npc in the YAML configuration.

Troubleshooting

The status of Weave Net can be checked by running its CLI commands. This can be done in various ways:

Select the relevant container, for example, if you want to look at host2 then pick weave-net-oai50 and run:

$ kubectl logs <weave-pod-name-as-above> -n kube-system weave-npc

When the Weave Network Policy Controller blocks a connection, it logs the following details about it:

protocol used,

source IP and port,

destination IP and port,

as per the below example:

TCP connection from 10.32.0.7:56648 to 10.32.0.11:80 blocked by Weave NPC.
UDP connection from 10.32.0.7:56648 to 10.32.0.11:80 blocked by Weave NPC.

Things to watch out for

Don’t turn on --masquerade-all on kube-proxy: this will change the
source address of every pod-to-pod conversation which will make it
impossible to correctly enforce network policies that restrict which
pods can talk.

If you do set the --cluster-cidr option on kube-proxy, make sure
it matches the IPALLOC_RANGE given to Weave Net (see below)

Changing Configuration Options

Using cloud.weave.works

You can customise the YAML you get from cloud.weave.works by passing some of Weave Net’s options, arguments and environment variables as query parameters:

version: Weave Net’s version. Default: latest, i.e. latest release. N.B.: This only changes the specified version inside the generated YAML file, it does not ensure that the rest of the YAML is compatible with that version. To freeze the YAML version save a copy of the YAML file from the release page and use that copy instead of downloading it each time from cloud.weave.works.

password-secret: name of the Kubernetes secret containing your password.
Example:

seLinuxOptions.NAME=VALUE: add SELinux option NAME and set it to VALUE, e.g. seLinuxOptions.type=spc_t

The list of variables you can set is:

CHECKPOINT_DISABLE - if set to 1, disable checking for new Weave Net
versions (default is blank, i.e. check is enabled)

HAIRPIN_MODE - Weave Net defaults to enabling hairpin on the bridge side of
the veth pair for containers attached. If you need to disable hairpin, e.g. your
kernel is one of those that can panic if hairpin is enabled, then you can disable it
by setting HAIRPIN_MODE=false.

IPALLOC_RANGE - the range of IP addresses used by Weave Net
and the subnet they are placed in (CIDR format; default 10.32.0.0/12)

EXPECT_NPC - set to 0 to disable Network Policy Controller (default is on)

KUBE_PEERS - list of addresses of peers in the Kubernetes cluster
(default is to fetch the list from the api-server)

IPALLOC_INIT - set the initialization mode of the IP Address
Manager
(defaults to consensus amongst the KUBE_PEERS)

WEAVE_EXPOSE_IP - set the IP address used as a gateway from the
Weave network to the host network - this is useful if you are
configuring the addon as a static pod.

WEAVE_MTU - Weave Net defaults to 1376 bytes, but you can set a
smaller size if your underlying network has a tighter limit, or set
a larger size for better performance if your network supports jumbo
frames - see here for more
details.