Support for using hostPort when using calico

[felipejfc]

For enabling hostPort we need to turn on portmap cni plugin.
In this PR I updated calico and calico-cni images to latest version which already includes the portmap binary, and then I only needed to modify the cni config file to enable it and change its extension from .conf to .conflist.

This is related to:
#3132

I think we should do the same for kube-router, flannel and weave (are there any other cni plugin supported by kops?)

[k8s-ci-robot]

Hi @felipejfc. 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 /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.

[felipejfc]

/assign @caseydavenport

[felipejfc]

/assign @justinsb

[justinsb]

@caseydavenport are you able to have a look at the calico side of things here? It seems we have a lot of calico changes all trying to get in at the same time - is there an official calico manifest we should be synchronizing with?

The only kops thing is that we also should bump the version in bootstrapchannelbuilder.go

[k8s-github-robot]

@felipejfc PR needs rebase

[chrislovecnm]

@blakebarnett if you want to take a peak as well

[blakebarnett]

👍

[caseydavenport]

Sorry for the long delay, I've been OOO for a couple of weeks and I'm still catching up on my backlog.

@justinsb there are official manifests at docs.projectcalico.org and a PR to add hostport support to those manifests as well: projectcalico/calico#903

[chrislovecnm]

We need to bump the version number of calico in the bootstrap code as well, or kops will not apply the changes to existing clusters. Let me know if you are not familiar with the version I am talking about in go

[zimbatm]

@chrislovecnm do you mind giving me pointers to the bootstrap code? I'm facing the same issue and trying to cook a solution.

[tmjd]

LGTM (as far as Calico changes are concerned)
Sidenote: I looked into the 'snat' setting for the portmap plugin because I noticed that the PR that @caseydavenport has up with similar changes for Calico had that set false. I came to the conclusion and ran it by Casey that it is ok to have that set and Calico even sets the sysctl flag that it depends on being set.

[felipejfc]

@chrislovecnm I guess that you mean I have to set calico version to something other than 2.4.1 (even though I'm using it as image version), something like: version := "2.4.1-kops", right?

[chrislovecnm]

Look at the file history, I cannot remember the semantics of the numbering, but yes we did a version with a -kops in it at onne point.

[chrislovecnm]

/ok-to-test

[felipejfc]

@chrislovecnm sorry for the delay changing the version in bootstrapchannel, I just pushed it. Can you validate the changes? thanks

[chrislovecnm]

@blakebarnett per your thumbs up

/lgtm

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chrislovecnm

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• OWNERS [chrislovecnm]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue. .

[ringods]

@chrislovecnm @felipejfc I am using kops 1.8.0-alpha-1 for the additional systemd manifest support in hooks. But this PR breaks my clusters. Calico CNI is not coming up on my k8s 1.6.4 cluster.

Looking at the changes in this PR, I see v2.4.1 listed in k8s-1.6.yaml.template, but v2.4.1-kops.1 in the bootstrapchannelbuilder.go file. I have v2.4.1 running on my failed node, with /etc/cni/net.d/10-calico.conflist as config file. It is a conflist extension, so probably not picked up with the plain v2.1.4 container.

Searching on quay.io, I don't see any image calico/node tagged v2.4.1-kops.1. Am I missing something?

[blakebarnett]

looks like a dev tag left in accidentally.

[ringods]

@blakebarnett reading back the conversation of this PR from around 1 Sept, it doesn't seem like it happened accidentally.

[blakebarnett]

Yeah you're right, I just didn't recognize that tag from when I was working on a different PR that also needed to update this. Guess it's the new convention.

[felipejfc]

@ringods the image version should be 2.4.1 in the daemonset not v2.4.1-kops.1

[ringods]

@felipejfc it is quay.io/calico/node:v2.4.1 in the daemonset. But what is that other version number then? Still, I have CNI+Calico problems all over the place on my 1.6.4 cluster with kops 1.8.0-alpha. Should k8s 1.6 clusters still be supported by this kops version?

[felipejfc]

@ringods I guess it should be... Can you detail the problems a little more? like, are the calico pods Running? do they log any error?

The other number is just for kops to know that it has to apply the updates to clusters that were already running with calico v2.4.1 before my PR was merged.