Skip to content

Commit ea8039d

Browse files
Dual-stack to stable
Signed-off-by: Bridget Kromhout <[email protected]>
1 parent 74dbf2d commit ea8039d

File tree

2 files changed

+30
-54
lines changed

2 files changed

+30
-54
lines changed

keps/sig-network/563-dual-stack/README.md

Lines changed: 25 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -1232,14 +1232,18 @@ be run individually, with the same initial configurations.
12321232
v1.16: Implemented phase 1 & 2 defined in the [implementation plan](#implementation-plan)
12331233
and launched in `Alpha`
12341234
1235-
v1.17: Implemented phase 3 defined [iplementation plan](#implementation-plan)
1235+
v1.17: Implemented phase 3 defined [implementation plan](#implementation-plan)
12361236
1237-
v1.18: Took user feedback on potentiall issues caused in feature enablement/disablement. Which lead us to redesign dual stack Services
1237+
v1.18: Took user feedback on potential issues caused in feature enablement/disablement, which led us to redesign dual-stack Services.
12381238
1239-
v1.19: Implemented redesigned duals stack Services see [PR 91824](https://github.com/kubernetes/kubernetes/pull/91824)
1239+
v1.19: Implemented redesigned dual-stack Services see [PR 91824](https://github.com/kubernetes/kubernetes/pull/91824)
12401240
12411241
v1.20: Relaunched to `Alpha`
12421242
1243+
v1.21: Moved from `Alpha` to `Beta`
1244+
1245+
v1.22: Moved from `Beta` to `Stable`
1246+
12431247
## Alternatives
12441248
12451249
### Dual-stack at the Edge
@@ -1386,9 +1390,10 @@ This capability will move to stable when the following criteria have been met.
13861390
13871391
13881392
* **How can this feature be enabled / disabled in a live cluster?**
1389-
- [X] Feature gate (also fill in values in `kep.yaml`)
1390-
- Feature gate name: IPv6DualStack
1391-
- Components depending on the feature gate: kube-apiserver, kube-controller-manager, kube-proxy, and kubelet
1393+
- With this feature moving to stable, the feature will always be enabled.
1394+
- While disabling the feature is not possible, using it is not required. Any
1395+
cluster can be provisioned with the `spec.ipFamilyPolicy` field set to
1396+
`SingleStack`.
13921397
13931398
* **Does enabling the feature change any default behavior?**
13941399
Pods and Services will remain single-stack until cli flags have been modified
@@ -1399,26 +1404,11 @@ This capability will move to stable when the following criteria have been met.
13991404
14001405
* **Can the feature be disabled once it has been enabled (i.e. can we roll back
14011406
the enablement)?**
1402-
Yes. If you decide to turn off dual-stack after turning on:
1403-
1. Ensure all services are converted to single-stack first (downgraded to
1404-
single-stack as described in this KEP)
1405-
2. Remove the CLI parameters.
1406-
3. Disable the feature.
1407-
1408-
Notes:
1409-
1. When the user disables dual-stack from the controller manager,
1410-
endpointSlices will no longer be created for the alternative IP family.
1411-
2. Existing endpointSlices for the alternative family will not be
1412-
automatically removed; this is left to the operator.
1413-
3. Existing dual-stack service configurations will remain in place when
1414-
the feature is disabled, but no routing will happen and no
1415-
endpointSlices will be created while the feature is disabled.
1407+
As the feature is stable, it is always available. However, it need not be used.
14161408
14171409
* **What happens if we reenable the feature if it was previously rolled back?**
14181410
1419-
If the system has no existing dual-stack services, then it will be treated
1420-
as a new enablement. However, if dual-stack services exist in the cluster,
1421-
the controller manager will automatically update endpoints and endpointSlices
1411+
The controller manager will automatically update endpoints and endpointSlices
14221412
to match the service IP families. When the feature is reenabled, kube-proxy
14231413
will automatically start updating iptables/ipvs rules for the alternative
14241414
ipfamily, for existing and new dual-stack services.
@@ -1430,28 +1420,27 @@ This capability will move to stable when the following criteria have been met.
14301420
iptables rules are fully propagated.
14311421
14321422
* **Are there any tests for feature enablement/disablement?**
1433-
The feature is being tested using integration tests with gate on/off. The
1423+
The feature was tested before stable, using integration tests with gate on/off. The
14341424
tests can be found here: https://github.com/kubernetes/kubernetes/tree/master/test/integration/dualstack
14351425
1436-
The feature is being tested on a cloud provider and kind.
1426+
The feature was tested on a cloud provider and kind.
14371427
1. azure dual-stack e2e: https://testgrid.k8s.io/sig-network-dualstack-azure-e2e
14381428
2. kind dual-stack iptables: https://testgrid.k8s.io/sig-network-kind#sig-network-kind,%20dual,%20master
14391429
3. kind dual-stack ipvs: https://testgrid.k8s.io/sig-network-kind#sig-network-kind,%20ipvs,%20master
14401430
14411431
### Rollout, Upgrade and Rollback Planning
14421432
14431433
* **How can a rollout fail? Can it impact already running workloads?**
1434+
14441435
Users **must** avoid changing existing CIDRs for both pods and services.
14451436
Users can only add an alternative ip family to existing CIDRs. Changing
14461437
existing CIDRs will result in nondeterministic failures depending on how the
14471438
cluster networking was configured.
14481439
1449-
Existing workloads are not expected to be impacted during rollout. When you
1450-
disable dual-stack, existing services aren't deleted, but routes for
1451-
alternative families are disabled. A component restart during rollout might
1452-
delay generating endpoints and endpointSlices for alternative IP families.
1453-
If there are *new* workloads that depend on the endpointSlices, these
1454-
workloads will fail until the endpoint slices are created.
1440+
Existing workloads are not expected to be impacted during rollout. A component
1441+
restart during rollout might delay generating endpoints and endpointSlices for
1442+
alternative IP families. If there are *new* workloads that depend on the
1443+
endpointSlices, these workloads will fail until the endpoint slices are created.
14551444
14561445
Because of the nature of the gradual rollout (node by node) of the dual-stack
14571446
feature, endpoints for the alternative IP family will not be created for
@@ -1460,7 +1449,7 @@ This capability will move to stable when the following criteria have been met.
14601449
following steps:
14611450
14621451
1. (preferred) Do not create dual-stack services until the rollout of the
1463-
dual-stack feature across the cluster is complete.
1452+
dual-stack feature (via supported version) across the cluster is complete.
14641453
or
14651454
2. Cordon and drain the node(s) where the feature is not enabled
14661455
@@ -1570,23 +1559,18 @@ resource usage (CPU, RAM, disk, IO, ...) in any components?**
15701559
CNI provider.
15711560
3. Service CIDRs need to be sufficiently large to allow for creation of
15721561
new services.
1573-
4. Dual-stack CLI flags must be configured on the cluster as defined in the [dual-stack docs](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#enable-ipv4-ipv6-dual-stack)
15741562
15751563
* Failure to create dual-stack services. Operator must perform the following steps:
1576-
1. Ensure that the cluster has `IPv6DualStack` feature enabled.
1564+
1. Ensure that the cluster is running a version of Kubernetes with the `IPv6DualStack`
1565+
feature enabled.
15771566
2. Ensure that api-server is correctly configured with multi (dual-stack) service
15781567
CIDRs using `--services-cluster-ip-range` flag.
15791568
15801569
* Failure to route traffic to pod backing a dual-stack service. Operator must perform the following steps:
15811570
1. Ensure that nodes (where the pod is running) are configured for dual-stack
15821571
a. Node is using dual-stack enabled CNI.
1583-
b. kubelet is configured with dual-stack feature flag.
1584-
c. kube-proxy is configured with dual-stack feature flag.
1585-
2. Ensure that api-server is configured for dual-stack
1586-
a. Feature flag is turned on.
15871572
3. Ensure that kube-controller-manager is configured for dual-stack
1588-
a. Feature flag is turned on.
1589-
b. `--cluster-cidr` cli flag is correctly configured with dual-stack
1573+
a. `--cluster-cidr` cli flag is correctly configured with dual-stack
15901574
where applicable.
15911575
4. Operator can ensure that `endpoints` and `endpointSlices` are correctly
15921576
created for the service in question by using kubectl.
@@ -1596,7 +1580,7 @@ resource usage (CPU, RAM, disk, IO, ...) in any components?**
15961580
scaling with dual-stack it may take time to attach all ready endpoints.
15971581
15981582
* CNI changes may affect legacy workloads.
1599-
1. When dual-stack is configured and enabled, DNS queries will start returning
1583+
1. When dual-stack is configured, DNS queries will start returning
16001584
IPv4(A) and IPv6(AAAA).
16011585
2. If a workload doesn't account for being offered both IP families, it
16021586
may fail in unexpected ways. For example, firewall rules may need to be

keps/sig-network/563-dual-stack/kep.yaml

Lines changed: 5 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,7 @@ authors:
77
- "@lachie83"
88
- "@khenidak"
99
- "@feiskyer"
10+
- "@bridgetkromhout"
1011
owning-sig: sig-network
1112
participating-sigs:
1213
- sig-cluster-lifecycle
@@ -18,20 +19,11 @@ prr-approvers:
1819
- "@johnbelamaric"
1920
editor: TBD
2021
creation-date: "2018-05-21"
21-
last-updated: "2021-02-02"
22-
status: implementable
23-
stage: beta
24-
latest-milestone: v1.21
22+
last-updated: "2021-04-23"
23+
status: implemented
24+
stage: stable
25+
latest-milestone: v1.22
2526
milestone:
2627
alpha: "v1.20"
2728
beta: "v1.21"
2829
stable: "v1.22"
29-
feature-gates:
30-
- name: IPv6DualStack
31-
components:
32-
- kube-apiserver
33-
- kube-controller-manager
34-
- kubelet
35-
- kube-proxy
36-
disable-supported: true
37-
metrics: []

0 commit comments

Comments
 (0)