@@ -1392,9 +1392,10 @@ This capability will move to stable when the following criteria have been met.
1392
1392
1393
1393
* **Does enabling the feature change any default behavior?**
1394
1394
Pods and Services will remain single-stack until cli flags have been modified
1395
- as described in this KEP. Existing and new services will remain single-stack
1396
- until user requests otherwise. Pods will become dual-stack once CNI is
1397
- configured for dual-stack.
1395
+ as described in this KEP. Existing and new Services will remain single-stack
1396
+ until the ipFamilyPolicy field is modified in a Service to be either
1397
+ PreferDualStack or RequireDualStack. Once CNI is configured for dual-stack,
1398
+ new Pod runtime environments will be provisioned with dual-stack.
1398
1399
1399
1400
* **Can the feature be disabled once it has been enabled (i.e. can we roll back
1400
1401
the enablement)?**
@@ -1422,6 +1423,12 @@ This capability will move to stable when the following criteria have been met.
1422
1423
will automatically start updating iptables/ipvs rules for the alternative
1423
1424
ipfamily, for existing and new dual-stack services.
1424
1425
1426
+ DNS will immediately begin returning the secondary IP family, while
1427
+ endpoints, endpointSlices, and iptables programming may take some time. This
1428
+ can lead to large or very busy services receiving excessive traffic on
1429
+ the secondary family address, until the endpoints, endpointSlices, and
1430
+ iptables rules are fully propagated.
1431
+
1425
1432
* **Are there any tests for feature enablement/disablement?**
1426
1433
The feature is being tested using integration tests with gate on/off. The
1427
1434
tests can be found here: https://github.com/kubernetes/kubernetes/tree/master/test/integration/dualstack
0 commit comments