Update weave-kube docs and YAML files to leverage Launch Generator

[marccarre]

Context:

The current Kubernetes YAML for weave-kube

1. is static, which forces people to manually edit the file in order to customise it, to add environment variables, etc. and
2. exists in two versions, one for Kubernetes v1.5, and one for v1.6 and above, which forces users to make choices about how they install weave-kube, hence increasing mental burden.

The latest version of the Launch Generator supports, among others:

• passing additional options, arguments, and environment variables (weaveworks/launch-generator#66), which addresses 1. above;
• passing the output of kubectl version to automatically extract Kubernetes' "server version" and return appropriate YAML configuration (weaveworks/launch-generator#79) without having users to care about it, which addresses 2. above.

Changelog:

1. Update documentation to cover point 1. from the above "Context" section.
2. Update documentation to cover point 2. from the above "Context" section.
3. Update Weave-Kube daemonset YAML files to standardise configuration based on Launch Generator's output.

Related work:

• weaveworks/launch-generator#66
• weaveworks/launch-generator#79
• weaveworks/launch-generator#88
• weaveworks/launch-generator#91

This PR and the above ones:

• fix weaveworks/launch-generator#43
• fix Launch generator for weave-kube #2754

cc: @errordeveloper

[weaveworksbot]

Documentation changes:

modified kube-addon

[bboreham]

One thought: on release, we need to update the git.io short URLs, but there is no way to synchronise that with the release.

I guess it's ok if we update the static files first, then update the short URLs, and the docs are wrong about the mapping in the meantime.

[marccarre]

If we proceed in the order described below, though, it should be OK?
There will indeed be a window of time during which things will be inconsistent with "Note: URLs", but I suspect very few people will read this and most will stop at the main instructions?

1. Release LG
   No one uses /k8s/net and /k8s.yaml (cloud) doesn't include Net, so serving 2.0's YAML before 2.0 is actually released should be fine.
2. Release Net, static files and docs (normal Net release process)
   a. people following the new docs will then start to use the LG, which serves up-to-date YAML. Again, I suspect most people will ignore "Note: URLs"
   b. people having scripted something based on the git.io short URLs will point to the static files, themselves just a copy of what the LG generates, i.e. 2.0's YAML
3. Update git.io short URLs to point to the LG -- when this is eventually done by GitHub's support, then "Note: URLs" will finally be consistent.

Alternatively we could just keep the git.io short URLs pointing to the static files and remove "Note: URLs", but I did it this way because we apparently wanted to have all users leverage the LG.

[bboreham]

If we proceed in the order described below, though, it should be OK?

Yes; I was just musing about the lack of synchronisation and the docs being wrong in the interim.

[bboreham]

cc @abuehrle if you want to review the docs changes

[marccarre]

N.B.: I'll fix the conflicts once weaveworks/launch-generator/issues/106 and weaveworks/launch-generator/issues/107 have been approved, and will simply re-generate the YAML files using the Launch Generator.

[abuehrle]

I had some changes around the YAML to download and edit based on the version of Net you have set.

[marccarre]

YAML for Kubernetes 1.5 seems to work fine:

master$ sudo kubeadm reset && sudo rm -r -f /opt/cni/bin/*weave*
master$ k8s_version="$(kubelet --version | grep -oP "(?<=Kubernetes )v[\d\.\-beta]+")"
master$ k8s_version_option="$([[ "$k8s_version" > "v1.6" ]] && echo "kubernetes-version" || echo "use-kubernetes-version")"
master$ sudo systemctl start kubelet && sudo kubeadm init --$k8s_version_option=$k8s_version
master$ git clone https://github.com/weaveworks/weave.git && cd weave && git checkout issues/2754-launch-generator-for-net

worker$ sudo kubeadm reset && sudo rm -r -f /opt/cni/bin/*weave*
worker$ sudo systemctl start kubelet && sudo kubeadm join --token=260b6a.c036d577c3919d8f 10.128.0.5

master$ kubectl apply -f prog/weave-kube/weave-daemonset.yaml
serviceaccount "weave-net" created
daemonset "weave-net" created

master$ kubectl get po --all-namespaces
NAMESPACE     NAME                              READY     STATUS    RESTARTS   AGE
default       weave-net-9jsr1                   2/2       Running   0          1m
default       weave-net-bh8fk                   2/2       Running   0          1m
default       weave-net-ch6hr                   2/2       Running   0          1m
kube-system   dummy-2088944543-m3rnp            1/1       Running   0          3m
kube-system   etcd-k15-0                        1/1       Running   0          2m
kube-system   kube-apiserver-k15-0              1/1       Running   2          2m
kube-system   kube-controller-manager-k15-0     1/1       Running   0          2m
kube-system   kube-discovery-1769846148-l8918   1/1       Running   0          3m
kube-system   kube-dns-2924299975-xwbzc         4/4       Running   0          3m
kube-system   kube-proxy-flgk8                  1/1       Running   0          2m
kube-system   kube-proxy-l6v5n                  1/1       Running   0          2m
kube-system   kube-proxy-n32vx                  1/1       Running   0          3m
kube-system   kube-scheduler-k15-0              1/1       Running   0          2m

hosts$ curl -sS http://127.0.0.1:6784/status
        Version: git-4f20f545dc44 (up to date; next check at 2017/05/26 18:49:28)

        Service: router
       Protocol: weave 1..2
           Name: XX:XX:XX:XX:XX:XX(k15-0|1|2)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 3
    Connections: 3 (2 established, 1 failed)
          Peers: 3 (with 6 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: 10.32.0.0/12
  DefaultSubnet: 10.32.0.0/12

master$ kubectl run nettest --image=weaveworks/network-tester:latest --replicas=3 -- -peers=3 -dns-name=nettest.default.svc.cluster.local.
deployment "nettest" created

master$ kubectl get po
NAME                       READY     STATUS    RESTARTS   AGE
nettest-4020221811-rr8nm   1/1       Running   0          33s
nettest-4020221811-tj4k3   1/1       Running   0          33s
nettest-4020221811-vq7r0   1/1       Running   0          33s
weave-net-9jsr1            2/2       Running   0          6m
weave-net-bh8fk            2/2       Running   0          6m
weave-net-ch6hr            2/2       Running   0          6m

master$ kubectl create -f - <<EOF
> apiVersion: v1
> kind: Service
> metadata:
>   name: nettest
> spec:
>   clusterIP: None
>   ports:
>   - port: 80
>     targetPort: 8080
>     protocol: TCP
>   selector:
>     run: nettest
> EOF
service "nettest" created

master$ podIP=$(kubectl get pods -l run=nettest -o go-template='{{(index .items 0).status.podIP}}' 2>/dev/null)
master$ echo $podIP
10.32.0.3
master$ curl -s -S http://$podIP:8080/status
pass