As https://github.com/kubernetes/kubernetes/pull/78478 we can use
ExpectNoError() instead of Expect(err).ToNot(HaveOccurred()) also.
This makes the test code check strict to cover the above case and
replaces the remaining in test/e2e/common/expansion.go
This is part of the transition to using framework/log instead
of the Logf inside the framework package. This will help with
import size/cycles when importing the framework or subpackages.
The container status is not constant, and can change over time in the
following order:
- Running: When kubelet reports the Pod as running. This state is missable if
the container finishes its command faster than kubelet getting to report this
state.
- Terminated: After the Container finished its command, it will enter the Terminated
state, in which will remain for a short period of time, before kubelet will try
to restart it.
- Waiting: When kubelet has to wait for the backoff period to expire before actually
restarting the container.
Treating and handling each of these states when calculating the backoff period between
container restarts will make the tests more reliable.
Kubelet might miss reporting the new Running state when restarting
a pod after its backoff period expired, and thus, the pod will
continue to remain in CrashLoopBackOff state, causing the
"should cap back-off at MaxContainerBackOff" and
"should have their auto-restart back-off timer reset on image update"
tests to fail, since they're waiting the Pods to enter a Running state.
Waiting for the next Terminated state instead of the next Running state
is more reliable.
Note that this adds 5 seconds to the restart delay due to the fact that
the Container runs for 5 seconds (it's command is "sleep 5"), but it is
within the test's expectations.
Automatic merge from submit-queue (batch tested with PRs 67739, 65222). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Tests: Make e2e test platform-agnostic
The test:
[k8s.io] Pods should support remote command execution over websockets [NodeConformance]
uses cat on /etc/resolv.conf and checks if the output from the container is "namespace",
which is incompatible with windows containers as there is no such file.
Since the test just check if remote command execution works, the command is
irrelevant as long as the output checks out. Switched to using echo "remote execution test",
and checking that output as it works for both windows and linux.
The test:
[k8s.io] Pods should support remote command execution over websockets [NodeConformance]
uses cat on /etc/resolv.conf and checks if the output from the container is "namespace",
which is incompatible with windows containers as there is no such file.
Since the test just check if remote command execution works, the command is
irrelevant as long as the output checks out. Switched to using echo "remote execution test",
and checking that output as it works for both windows and linux.
The following tests are not tagged because they are not really run in
node e2e suites:
* A subset of host path tests that required SSH access
- should evaluate whether the tests should be moved to test/e2e_node
* GCP volume tests
- should evaluate whether these tests should be moved out of the
common directly since they are not shared with the node e2e suite.
