6675eba3ef
* 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>
Kubernetes Command-Line Integration Test Suite
This document describes how you can use the Kubernetes command-line integration test-suite.
Running Tests
All Tests
To run this entire suite, execute make test-cmd from the top level. This will import each file containing tests functions
Specific Tests
To run a subset of tests (e.g. run_deployment_test and run_impersonation_test), execute make test-cmd WHAT="deployment impersonation". Running specific
tests will not try and validate any required resources are available on the server.
Adding Tests
Test functions need to have the format run_*_test so they can executed individually. Once a test has been added, insert a section in legacy-script.sh like
######################
# Replica Sets #
######################
if kube::test::if_supports_resource "${replicasets}" ; then
record_command run_rs_tests
fi
Be sure to validate any supported resources required for the test by using the kube::test::if_supports_resource function.
New File
If the test resides in a new file, source the file in the top of the legacy-script.sh file by adding a new line in
source "${KUBE_ROOT}/test/cmd/apply.sh"
source "${KUBE_ROOT}/test/cmd/apps.sh"
source "${KUBE_ROOT}/test/cmd/authorization.sh"
source "${KUBE_ROOT}/test/cmd/batch.sh"
...
Please keep the order of the source list alphabetical.