* Rename const for topology.../zone
* Rename const for topology.../region
* Rename const for failure-domain.../zone
* Rename const for failure-domain.../region
* Restore old names for compat
* api: structure change
* api: defaulting, conversion, and validation
* [FIX] validation: auto remove second ip/family when service changes to SingleStack
* [FIX] api: defaulting, conversion, and validation
* api-server: clusterIPs alloc, printers, storage and strategy
* [FIX] clusterIPs default on read
* alloc: auto remove second ip/family when service changes to SingleStack
* api-server: repair loop handling for clusterIPs
* api-server: force kubernetes default service into single stack
* api-server: tie dualstack feature flag with endpoint feature flag
* controller-manager: feature flag, endpoint, and endpointSlice controllers handling multi family service
* [FIX] controller-manager: feature flag, endpoint, and endpointSlicecontrollers handling multi family service
* kube-proxy: feature-flag, utils, proxier, and meta proxier
* [FIX] kubeproxy: call both proxier at the same time
* kubenet: remove forced pod IP sorting
* kubectl: modify describe to include ClusterIPs, IPFamilies, and IPFamilyPolicy
* e2e: fix tests that depends on IPFamily field AND add dual stack tests
* e2e: fix expected error message for ClusterIP immutability
* add integration tests for dualstack
the third phase of dual stack is a very complex change in the API,
basically it introduces Dual Stack services. Main changes are:
- It pluralizes the Service IPFamily field to IPFamilies,
and removes the singular field.
- It introduces a new field IPFamilyPolicyType that can take
3 values to express the "dual-stack(mad)ness" of the cluster:
SingleStack, PreferDualStack and RequireDualStack
- It pluralizes ClusterIP to ClusterIPs.
The goal is to add coverage to the services API operations,
taking into account the 6 different modes a cluster can have:
- single stack: IP4 or IPv6 (as of today)
- dual stack: IPv4 only, IPv6 only, IPv4 - IPv6, IPv6 - IPv4
* [FIX] add integration tests for dualstack
* generated data
* generated files
Co-authored-by: Antonio Ojea <aojea@redhat.com>
When trying to fix a dockershim issue, there were not any unit tests
for dockershim/exec.go and it was difficult to add the corresponding
unit test for the bug.
This adds the unit tests for avoiding such situation in the future.
Fix stupid golang loop variable closure thing.
Also, if we fail to initially set up the rules for one family, don't
try to set up a canary. eg, on the CI hosts, the kernel ip6tables
modules are not loaded, so any attempt to call ip6tables will fail.
Just log those errors once at startup rather than once a minute.
Discussion is ongoing about how to best handle dual-stack with clouds
and autodetected IPs, but there is at least agreement that people on
bare metal ought to be able to specify two explicit IPs on dual-stack
hosts, so allow that.
Several of the tests in TestNodeAddress() were no-ops because the test
code was only testing that NodeAddresses() returned all of the
expected addresses, but not testing that it was returning them in the
correct order.
The order that NodeAddresses() returns addresses in is very important,
so fix the tests to actually test it.
One existing test ("NodeIP is external") had its expectedAddresses in
the wrong order, but it seems clear from the name of the test that
this isn't actually what it expected.
Also, previously testKubeletHostname was "127.0.0.1" which ended up
interacting weirdly with the IPv4-vs-IPv6 sorting code in a way that
made some of the test results confusing if you didn't realize that
testKubeletHostname was an IPv4 address. Fix that by making it an
actual hostname instead, which then preserves the expected sorting.
