Use CNI v0.6.x in Kubernetes v1.9.0

[luxas]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature

It's time to decide which CNI version to use for v1.8.
We should do early in the cycle to catch regressions in the CNI <-> k8s integration.
We don't want the thing that happened in v1.6 to occur again, so we need to be very careful.

Currently, we're using v0.5.1 and consuming tarballs via a sha pushed by this Makefile: https://github.com/kubernetes/kubernetes/blob/master/build/cni/Makefile

We did this earlier because CNI didn't provide binary artifacts for all platform that kubernetes supports.
Since v0.5.2, they do, so we can get rid of build/cni/Makefile 🎉

Also, we don't want to consume a strange SHA as the version indicator, instead we want to use a version number and possibly a SHA for verification.

I guess it would make sense to bump CNI to v0.5.2 for the v1.8 cycle.
Agree/disagree? It's not clear to me when v0.6.0 will be released, but the rc has been out for some time already...

cc @kubernetes/sig-network-feature-requests @ixdy @freehan @kubernetes/sig-cluster-lifecycle-feature-requests @dcbw

[luxas]

cc @bboreham

[bboreham]

CNI v0.6 should be out this week

There are a bunch of small fixes; also this is the first version that includes the portmap plugin.

[luxas]

@bboreham So you're advocating for using v0.6?
Well, that's fine by me.

I just want to be sure we track all the action items correctly and make sure we test everything properly in time.

What we (at least) need to do:

• Bump the CNI vendored libraries
• Remove build/cni
• Update all binary download references to v0.5.1 to v0.6.0
• Update debs/rpm packages to use v0.6.0
• Make sure all CNI network providers are compatible with the CNI v0.3.1 spec
• Make sure CRI properly integrates with CNI v0.6.0
• Resolve Create pod latency increase #54651

More action items?

[dixudx]

/cc

[timothysc]

Is there a changelog we should be following?
I'd like to properly build the rpms now as well.

[bboreham]

No changelog file but releases are visible in https://github.com/containernetworking/cni/releases and https://github.com/containernetworking/plugins/releases and announced on the CNI mailing list and Kubernetes sig-network mailing list.

[luxas]

CNI v0.6.0 is out https://github.com/containernetworking/cni/releases/tag/v0.6.0 🎉, but it's too late in the cycle for us to update.
I think we should target k8s to use v0.6.x in v1.9 (and then include portmap, etc. etc.)

@dixudx is this something you'd want to work on?

[dixudx]

@luxas I would like to work on this. Thanks. Will send out a PR later.

[roberthbailey]

Shouldn't we ask @kubernetes/sig-network-misc which CNI version we should be supporting with 1.8? And try to make the CNI version consistent across all of the install tools?

[dixudx]

Shouldn't we ask @kubernetes/sig-network-misc which CNI version we should be supporting with 1.8? And try to make the CNI version consistent across all of the install tools?

@roberthbailey +1. Waiting for the reply.

[k8s-ci-robot]

@dixudx: Reiterating the mentions to trigger a notification:
@kubernetes/sig-network-misc.

In response to this:

Shouldn't we ask @kubernetes/sig-network-misc which CNI version we should be supporting with 1.8? And try to make the CNI version consistent across all of the install tools?

@roberthbailey +1. Waiting for the reply.

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.

[luxas]

@roberthbailey I'm not dictating, here I'm asking what version is targeted 😄.
Seems like folks are happy with this; no objections so far.
Think it's definitely too late to upgrade CNI at this point, so upgrading as @bboreham mentioned makes sense to me in v1.9

[feiskyer]

Think it's definitely too late to upgrade CNI at this point, so upgrading as @bboreham mentioned makes sense to me in v1.9

Agreed, time too late now. v1.9 is preferred.

[danehans]

/area ipv6

[danehans]

@feiskyer I am part of a team adding IPv6 support to k8s. CNI 0.6.0 is needed for assigning IPv6 addresses to pods. Several users are interested in k8s IPv6 support. It would be very helpful to get the cni bump into 1.8. However, I respect your decision if you choose to wait until 1.9.

[feiskyer]

@danehans Is IPv6 feature a blocker of 1.8?

/cc @kubernetes/sig-network-misc

[danehans]

@feiskyer I'm a relatively new contributor. Can you help me understand or point me to documentation that explains what qualifies a feature as a blocker for a release? IPv6 is a feature several users are waiting for us to release.

[danehans]

/assign @thockin

[caseydavenport]

but I would like to hold this open until we know how it's going to work.

@enisoc Sounds fine to me - who is making that decision?

[chrislovecnm]

@caseydavenport which decision?

[caseydavenport]

In particular, we need a plan to make sure k8s 1.9 uses CNI 0.6.0, while keeping k8s 1.8 and below on CNI 0.5.x.

@chrislovecnm this one ^

[danehans]

@luxas @caseydavenport now that a 1.9 branch has been cut, can CNI get bumped?

[dixudx]

now that a 1.9 branch has been cut, can CNI get bumped?

@danehans Already bumped in #51250 (merged). Only get kubernetes/release#446 left, should be shipped ASAP, since v1.9 is coming out.

[danehans]

@dixudx I have added IPv6 support details to the 1.9 release notes.

[danehans]

@dixudx what needs to be done to close this issue? The 1.9 burndown kubernetes/sig-release#38 (comment) is highlighting this issue:

CNI 0.6.0: (#49480): issue still lacks
an "owner" who is going to make sure that the deploy & packaging changes happen. There have been
some updates on this, but a critical outstanding issue is making sure that people can still install version 1.8 with the correct CNI.

[k8s-github-robot]

[MILESTONENOTIFIER] Milestone Issue Current

@luxas @thockin

Note: This issue is marked as priority/critical-urgent, and must be updated every 1 day during code freeze.

Example update:

ACK.  In progress
ETA: DD/MM/YYYY
Risks: Complicated fix required

Issue Labels

• sig/cluster-lifecycle sig/network sig/node: Issue will be escalated to these SIGs if needed.
• priority/critical-urgent: Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels.
• kind/feature: New functionality.

Help

• Additional instructions
• Commands for setting labels

[dixudx]

what needs to be done to close this issue?

@danehans Can be closed when kubernetes/release#486 get merged. PTAL.

[resouer]

I think all CRI runtimes has been upgraded, ref: kubernetes-retired/frakti#270

[danehans]

@dixudx kubernetes/release#486 has ben merged. Can we close this issue?

[caseydavenport]

I think so - @enisoc do you agree?

[luxas]

Can we close this now with kubernetes/release#486 merged? I think so

[enisoc]

@pipejakob is still working on back-filling packages for old k8s versions to prevent them from picking up kubernetes-cni 0.6.0. I think we can close this once that's done.

[enisoc]

@pipejakob reported last night that the back-fill is done and staged in unstable. He's tested the updated packages, so we just need to re-tag that package set as stable this morning before pushing v1.9.0 in the afternoon.

[pipejakob]

Thanks for remembering to update here, @enisoc. All of the backfill builds are now promoted to stable (with easy rollback instructions in case anything goes wrong). Should be good to go today with the 1.9 debs/rpms after the release is cut.

[luxas]

Thanks @pipejakob for helping with this!