As a quick fix for a flake, bceec5a3ff
introduced polling with wait.Poll in all callers of CheckDaemonStatus.
This commit reverts all callers to what they were before (CheckDaemonStatus +
ExpectNoError) and implements polling according to E2E best practices
(https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/writing-good-e2e-tests.md#polling-and-timeouts):
- no logging while polling
- support for progress reporting while polling
- last but not least, produce an informative failure message in case of a
timeout, including a dump of the daemon set as YAML
The util for checking on daemonstatus was checking once if the Status of
the daemonset was reporting that all the desired Pods are scheduled and
ready.
However, the pattern used in the e2e test for this function was not
taking into consideration that the controller needs to propagate the Pod
status to the DeamonSet status, and was asserting on the condition only
once after waiting for all the Pods to be ready.
In order to avoid more churn code, change the CheckDaemonStatus
signature to the wait.Condition type and use it in a async poll loop on
the tests.
The LoadBalancer test "should handle updates to ExternalTrafficPolicy
field" had a bunch of problems, but the biggest is that (without doing
[Disruptive] things to the cluster or making unwarranted assumptions
about source IPs) it's very hard to *prove* that the cloud load
balancer is doing Cluster traffic policy semantics (distributing
connections to all nodes) rather than Local (distributing only to
nodes with endpoints).
So split the test into 2 new tests with more focused semantics:
- "should implement NodePort and HealthCheckNodePort correctly when
ExternalTrafficPolicy changes" (in service.go) tests that the
service proxy is correctly implementing the proxy side of
Cluster-vs-Local traffic policy for LoadBalancer Services, without
testing the cloud load balancer itself at all.
- "should target all nodes with endpoints" (in loadbalancer.go)
complements the existing "should only target nodes with
endpoints", to ensure that when a service has
`externalTrafficPolicy: Local`, and there are endpoints on
multiple nodes, that the cloud is correctly configured to target
all of those endpoints, not just one.
* KEP-4427 : AllowRelaxedDNSSearchValidation
* Add e2e test with feature gate to test KEP-4427 RelaxedDNSSearchValidation
* Add more validatePodDNSConfig test cases
Also update Regex to match the case we want.
Thanks Tim and Antonio!
validating that one endpoint is reachable from one part of the cluster
is not enough condition to consider it will be reachable from any node,
as different Services proxies on different nodes will have different
propagation delays for the EndpointSlices and Services information.
Fix `[sig-network] Services [It] should complete a service status
lifecycle [Conformance]` not iterating through all `Conditions` in
status, causing failure when a `Condition` already exists.
Log Conditions instead of Loadbalanacer.
It previously assumed that pod-to-other-node-nodeIP would be
unmasqueraded, but this is not the case for most network plugins. Use
a HostNetwork exec pod to avoid problems.
This also requires putting the client and endpoint on different nodes,
because with most network plugins, a node-to-same-node-pod connection
will end up using the internal "docker0" (or whatever) IP as the
source address rather than the node's public IP, and we don't know
what that IP is.
Also make it work with IPv6.
The existing test had two problems:
- It only made connections from within the cluster, so for VIP-type
LBs, the connections would always be short-circuited and so this
only tested kube-proxy's LBSR implementation, not the cloud's.
- For non-VIP-type LBs, it would only work if pod-to-LB connections
were not masqueraded, which is not the case for most network
plugins.
Fix this by (a) testing connectivity from the test binary, so as to
test filtering external IPs, and ensure we're testing the cloud's
behavior; and (b) using both pod and node IPs when testing the
in-cluster case.
Also some general cleanup of the test case.
The original assumption is wrong, as the node name may not match the
hostname of the host in some circumstances.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
