This changes the conformance test to measure the latency of the
EndpointSlice controller rather than the Endpoints controller. This
should not have any real effect since the two controllers run in the
same process and do mostly the same thing (especially in tests like
this one which don't test multi-slice services).
Use Pod Readiness Gates and Services to implement blue green deployment
strategies by setting the corresponding readines gate to influence the
service traffic.
Change-Id: I23e3b9a0440014f48a4612685055565fd8dff5ec
The existing TrafficDistribution test didn't really distinguish "same
zone" from "same node". Add another test that makes sure there are at
least 2 nodes in each zone so it can do that.
(Keep the original test as well to avoid losing coverage in CI systems
with single-schedulable-node-per-zone clusters.)
Split the logic of creating the clients and the servers apart from the
logic of checking which clients connect to which servers. Add some
extra complexity to support additional use cases (like multiple
endpoints on the same node).
Remove endpointSlicesHaveSameZoneHints check. We are testing that
connections end up at the right endpoints. We don't need to validate
_why_ they go to the right endpoints, which is already tested by other
tests anyway. (Also, validating the hints becomes more complicated in
the same-node case, where there may or may not also be same-zone hints
depending on cluster configuration.)
Remove DeferCleanup calls; we don't need to delete anything manually
because namespaced resources will automatically be deleted when the
test case's namespace is deleted.
Remove a setting of pod.NodeName that was redundant with
e2epod.SetNodeSelection().
It was writing out IPBlock CIDRs like "192.168.0.5/4" rather than
"192.0.0.0/4".
Also, simplify a bit by basing the `cidr` and the `except` both on
podB, rather than one on podA and one on podB. (This is even
theoretically a bugfix, since it's not _required_ that podA and podB
be in the same /4.) Also reorganize the code to make the two test
cases more consistent with each other.
The test is super hacky and we'll not be needed once the corresponding
KEP is implemented, better to remove it that trying to fix it
perpetuating the hacky solution.
kube-proxy does not look at Endpoints ever, so it is incorrect for a
test to assume that there is any correlation between whether Endpoints
exist and whether a Service is working. Tests should only be using the
v1.Endpoints API if they are explicitly testing the behavior of
v1.Endpoints, the Endpoints controller, or the EndpointSlice mirroring
controller. There is no reason for any non SIG Network tests to be
testing any of those things, so there should be no references to
v1.Endpoints in test/e2e outside of test/e2e/network.
Also, simplify some pointlessly complicated e2eservice code.
The test was reusing the same variable for the service on each
iteration, the problem is that when the service creation fails, it
clears out the variable and in the next iteration it panics because is
trying to use a field on that same variable.
