Update weave to use the correct CIDR for pods

[jordanjennings]

Per conversations on slack and discussions in #1171 and #2085, this pull request sets the IP range for weave by setting the env variable IPALLOC_RANGE to .KubeControllerManager.ClusterCIDR.

Everything working as expected, see below for more testing details.

Tested Scenarios

New Cluster Creation

• Cluster was created with this branch and k8s 1.6.2.
• Default of nonMasqueradeCIDR: 100.64.0.0/10 was kept
• IPALLOC_RANGE in for weave validated in the state store as:

 env:
   - name: IPALLOC_RANGE
     value: 100.96.0.0/11

• Guestbook deployed, pods were given IPs in the expected range:

NAME                 READY     STATUS    RESTARTS   AGE       IP            NODE
guestbook-3t2l6      1/1       Running   0          7m        100.104.0.2   ip-10-253-84-250.ec2.internal
guestbook-6318f      1/1       Running   0          7m        100.120.0.2   ip-10-253-85-151.ec2.internal
guestbook-g196z      1/1       Running   0          7m        100.116.0.2   ip-10-253-85-108.ec2.internal
redis-master-ctd02   1/1       Running   0          7m        100.120.0.3   ip-10-253-85-151.ec2.internal
redis-slave-j7g0p    1/1       Running   0          7m        100.104.0.3   ip-10-253-84-250.ec2.internal
redis-slave-z0xkr    1/1       Running   0          7m        100.120.0.4   ip-10-253-85-151.ec2.internal

All networking working as expected (pod to pod, pod to external, external to pod)

Cluster Upgrade

• Cluster created with kops 1.6.0 and k8s 1.6.2
• Default of nonMasqueradeCIDR: 100.64.0.0/10 was kept
• No IPALLOC_RANGE set for weave (as expected)
• Deployed guestbook, working as expected with default weave pod IP ranges:

NAME                 READY     STATUS    RESTARTS   AGE       IP          NODE
guestbook-1wqfd      1/1       Running   0          1h        10.44.0.2   ip-10-253-84-75.ec2.internal
guestbook-f4pnl      1/1       Running   0          1h        10.39.0.1   ip-10-253-84-63.ec2.internal
guestbook-s2239      1/1       Running   0          1h        10.36.0.3   ip-10-253-85-167.ec2.internal
redis-master-clx2j   1/1       Running   0          1h        10.39.0.2   ip-10-253-84-63.ec2.internal
redis-slave-cjhnk    1/1       Running   0          1h        10.44.0.3   ip-10-253-84-75.ec2.internal
redis-slave-h87gj    1/1       Running   0          1h        10.39.0.3   ip-10-253-84-63.ec2.internal

• Cluster edited with this branch, k8s updated to 1.6.4
• kops update cluster showed the expected diff and I confirmed state store was updated
• After kops rolling-update cluster I validated the previous deployment IP addresses:

NAME                 READY     STATUS    RESTARTS   AGE       IP            NODE
guestbook-1t0m3      1/1       Running   0          6m        100.124.0.4   ip-10-253-84-153.ec2.internal
guestbook-d2tt3      1/1       Running   0          6m        100.124.0.2   ip-10-253-84-153.ec2.internal
guestbook-jbzkc      1/1       Running   0          6m        100.112.0.2   ip-10-253-84-31.ec2.internal
redis-master-fzjs8   1/1       Running   0          6m        100.112.0.3   ip-10-253-84-31.ec2.internal
redis-slave-4gq9k    1/1       Running   0          6m        100.124.0.3   ip-10-253-84-153.ec2.internal
redis-slave-qpnb5    1/1       Running   0          6m        100.112.0.4   ip-10-253-84-31.ec2.internal

• All IP addresses now in the expected range of 100.96.0.0/11
• All networking working as expected
• Did a new deployment of guestbook, also worked as expected

Note: the known issue with Weave 1.9.7 and NodePort services is still present here. That will be addressed separately.

---

This change is 

[k8s-ci-robot]

Hi @jordanjennings. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with @k8s-bot ok to test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[jordanjennings]

CC @chrislovecnm

[chrislovecnm]

@k8s-bot ok to test

[chrislovecnm]

Awesome

[chrislovecnm]

/lgtm

[chrislovecnm]

Waiting on e2e