Promote IPv4/IPv6 dual-stack support to Stable in 1.23

[bridgetkromhout]

We anticipate moving dual-stack to stable and removing the feature gate in 1.23.

Enhancements issue: kubernetes/enhancements#563
Kubernetes PR: kubernetes/kubernetes#104691

Signed-off-by: Bridget Kromhout [email protected]

[tengqm]

/hold
This looks like a placeholder because the upstream change is not there yet.

[sftim]

Hi. We'll also need to revise some more pages to get the documentation ready for dual-stack as a stable feature:

• https://kubernetes.io/docs/concepts/cluster-administration/networking/
• https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/

and possibly:

• https://kubernetes.io/docs/concepts/services-networking/
• https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/dual-stack-support/

My view is that https://kubernetes.io/docs/concepts/services-networking/dual-stack/ (as a concept) should disappear, being superseded by a new task page about configuring dual-stack networking. We should reword https://kubernetes.io/docs/concepts/services-networking/ so that it mentions dual-stack in the page text, and also link to the page about configuring it.

We might also want a page about making sure that your cluster runs single stack networking, as you won't be able to use a feature gate any more to achieve that.

[sftim]

/sig network

[bridgetkromhout]

My view is that https://kubernetes.io/docs/concepts/services-networking/dual-stack/ (as a concept) should disappear, being superseded by a new task page about configuring dual-stack networking.

We can definitely move many examples to the tasks page. We'll also want to keep a concept page, as there are details that may confuse people encountering this for the first time. I'll submit an update to this PR.

[sftim]

I'm imagining that at some point when you visit https://kubernetes.io/docs/concepts/services-networking/dual-stack/ you are redirected to https://kubernetes.io/docs/concepts/services-networking#dual-stack

I think we should then have pages in the reference section about networking that cover the 3 cases we support:

• dual stack
• IPv4-only
• IPv6-only

and those can go into lots of detail. The reference section is the right home for that detail. Treating each of those 3 cases as equally valid feels important; people might well prefer to run a single-stack cluster and we shouldn't make them feel like second class readers; the same is true for people who want to run dual-stack.

I'm happy to help tidying up this effort; I've got general IPv6 experience dating back well over a decade. I've got pretty much zero experience of IPv6 with Kubernetes though.

[reylejano]

/milestone 1.23
/cc @jlbutler

[jlbutler]

/assign @nate-double-u

[sftim]

@kubernetes/sig-network-misc this looks fine to me in terms of there being no problematic omissions or inaccuracies - would someone from the SIG be willing to add a tech sign off to say you agree?

(As far as I'm concerned, we can get that signoff in place even if the hold remains).

[netlify]

👷 Deploy Preview for kubernetes-io-vnext-staging processing.

🔨 Explore the source changes: a209e3d

🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/6199281e715fcf00080505f5

[bridgetkromhout]

I was first writing a release blog, and now I'm getting back to this PR. Updates will come in short order.

[bridgetkromhout]

/hold cancel

[bridgetkromhout]

While @sftim has excellent ideas for docs refactoring, those may not fit in the desired timeframe - while this PR is an attempt to make the docs for 1.23 as accurate as is feasible.

[bridgetkromhout]

/assign @jimangel

[bridgetkromhout]

Hi @jlbutler @jimangel @nate-double-u and all of the docs team - while we can continue to improve the docs, what we have in place in this PR is factually accurate and as ready for merge as it can be. Thanks!

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: fcd1b31e6973cc7464eb29c6316dacd577b0cd2a

[bridgetkromhout]

Alternately we can slap a squash label on the PR.

@jimangel let's go with this, since it's way too late at night for me to resolve conflicts in the feature-gate list, and I don't want to hold things up. Thanks!

[sftim]

@bridgetkromhout if you're happy for me to, I can force-push a squashed version (that would retain LGTM).

[sftim]

I suggest we also update https://kubernetes.io/docs/tasks/network/validate-dual-stack/ to change the min-kubernetes-server-version, and add a text explanation (ie: you can validate with an earlier version but the feature was only GA and officially supported since v1.23) after the version-check shortcode.

Do we also need to update https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/dual-stack-support/ ?

[bridgetkromhout]

@sftim You have the advantage time-zone wise! I'm happy to have you do whatever works best; sounds like we aren't quite ready to squash anyhow, because of these:

I suggest we also update https://kubernetes.io/docs/tasks/network/validate-dual-stack/ to change the min-kubernetes-server-version, and add a text explanation (ie: you can validate with an earlier version but the feature was only GA and officially supported since v1.23) after the version-check shortcode.

Do we also need to update https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/dual-stack-support/ ?

I'll look today.

[sftim]

Thanks. This PR is in good shape to meet the ready-for-review deadline: it's already there, and now we're looking at snags.

[bridgetkromhout]

Thanks. This PR is in good shape to meet the ready-for-review deadline: it's already there, and now we're looking at snags.

@sftim Thanks! I pushed a PR to address the two things you mentioned today - please take a look - hopefully we can get to squash-and-LGTM-again later today.

[sftim]

I spotted one more thing.

We should reword:

Currently, the kube-controller-manager flags --node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6 are being left with default values. See enable IPv4/IPv6 dual stack.

• remove “Currently”
• reword if technically incorrect for v1.23

Let's address that in a separate PR.

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 5ab85d7957c5e3b16e8ad47b3eba2bfff066f72e

[sftim]

@khenidak if you re-add LGTM, I can also approve this (I'd rather not both approve and LGTM commits that I pushed).

[sftim]

Also relevant to:
/sig cluster-lifecycle

[jlbutler]

I've been monitoring this and looks ok to approve. But looks like you're asking for additional review so you can approve @sftim. Ok by me, just let me know if you'd rather I just merge it. Thanks.

[jlbutler]

Chatted with TIm on Slack, thanks for everyone's work on this!

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jlbutler, khenidak

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

The pull request process is described here

Needs approval from an approver in each of these files:

• content/en/OWNERS [jlbutler]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment