You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: keps/sig-network/563-dual-stack/README.md
+18-3Lines changed: 18 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1377,7 +1377,7 @@ This capability will move to beta when the following criteria have been met.
1377
1377
* Service resource supports pods with multi-IP
1378
1378
* Kubenet to support multi-IPs
1379
1379
1380
-
This capability will move to stable when the following criteria have been met.
1380
+
This capability will move to stable when the following criteria have been met:
1381
1381
1382
1382
* Support of at least one CNI plugin to provide multi-IP ([Cilium](https://cilium.io/blog/2021/05/20/cilium-110) and [Calico](https://www.tigera.io/blog/dual-stack-operation-with-calico-on-kubernetes/))
1383
1383
* e2e test successfully running on two platforms (Azure and kind)
@@ -1404,6 +1404,11 @@ This capability will move to stable when the following criteria have been met.
1404
1404
to only one address block.
1405
1405
1406
1406
* **Does enabling the feature change any default behavior?**
1407
+
When this feature moves to stable, the dual-stack feature is available in
1408
+
all clusters. However, Pods and Services will default to single-stack unless
1409
+
ipFamilyPolicy field is modified in a Service to be either PreferDualStack
1410
+
or RequireDualStack.
1411
+
1407
1412
Pods and Services will remain single-stack until cli flags have been modified
1408
1413
as described in this KEP. Existing and new Services will remain single-stack
1409
1414
until the ipFamilyPolicy field is modified in a Service to be either
@@ -1413,7 +1418,11 @@ This capability will move to stable when the following criteria have been met.
1413
1418
* **Can the feature be disabled once it has been enabled (i.e. can we roll back
1414
1419
the enablement)?**
1415
1420
1416
-
Yes. If you decide to turn off dual-stack after turning on:
1421
+
The feature gate will be removed for the stable release, so this feature is
1422
+
always available. However, single-stack is the default until dual-stack is
1423
+
configured.
1424
+
1425
+
In beta, if you decide to turn off dual-stack after turning on:
1417
1426
1. Ensure all services are converted to single-stack first (downgraded to
1418
1427
single-stack as described in this KEP)
1419
1428
2. Remove the CLI parameters.
@@ -1433,6 +1442,8 @@ This capability will move to stable when the following criteria have been met.
1433
1442
1434
1443
* **What happens if we reenable the feature if it was previously rolled back?**
1435
1444
1445
+
When the feature is stable, it will always be available.
1446
+
1436
1447
If the system has no existing dual-stack services, then it will be treated
1437
1448
as a new enablement. However, if dual-stack services exist in the cluster,
1438
1449
the controller manager will automatically update endpoints and endpointSlices
@@ -1464,7 +1475,7 @@ This capability will move to stable when the following criteria have been met.
1464
1475
cluster networking was configured.
1465
1476
1466
1477
Existing workloads are not expected to be impacted during rollout. When you
1467
-
disable dual-stack, existing services aren't deleted, but routes for
1478
+
set a cluster to single-stack, existing services aren't deleted, but routes for
1468
1479
alternative families are disabled. A component restart during rollout might
1469
1480
delay generating endpoints and endpointSlices for alternative IP families.
1470
1481
If there are *new* workloads that depend on the endpointSlices, these
@@ -1573,6 +1584,10 @@ resource usage (CPU, RAM, disk, IO, ...) in any components?**
1573
1584
1574
1585
### Troubleshooting
1575
1586
1587
+
When the feature is stable, the feature gate is no longer present, so no
1588
+
disabling of the feature gate is applicable, and the feature is always
1589
+
enabled; it may be used or not used as desired.
1590
+
1576
1591
* **How does this feature react if the API server and/or etcd is unavailable?**
1577
1592
This feature will not be operable if either kube-apiserver or etcd is unavailable.
0 commit comments