fef0aca1d4
Extend the Windows CPU manager node e2e suite with coverage that was present on Linux but missing on Windows: - strict-cpu-reservation: with the policy option enabled the reserved CPU is excluded from the burstable shared pool; without it (default) the reserved CPU stays in the shared pool. - dynamic shared-pool resizing: a running burstable container's affinity shrinks and grows via the CPU manager reconcile loop as a guaranteed pod takes and releases an exclusive CPU. Toggling strict-cpu-reservation invalidates the persisted CPU manager checkpoint (the reserved CPU moves in/out of the default pool), so the kubelet refuses to start until the state file is removed. Implement the previously no-op deleteStateFile on Windows and clear the CPU/memory manager state files when toggling the option, mirroring the Linux updateKubeletConfig(..., deleteStateFiles=true) behavior. |
||
|---|---|---|
| .. | ||
| builder | ||
| criproxy | ||
| kubeletconfig | ||
| services | ||
| cpu_manager_test.go | ||
| e2e_node_suite_test.go | ||
| framework.go | ||
| image_list.go | ||
| lint_windows.md | ||
| OWNERS | ||
| README.md | ||
| standalone_test.go | ||
| util.go | ||
| util_affinity_windows.go | ||
| util_jobobject_windows.go | ||
| util_kubeletconfig.go | ||
| util_system_windows.go | ||
Windows Node End-To-End (e2e) tests
Node e2e tests are component tests meant for testing the Kubelet code on a custom single-host environment with the fake api server running on the same host. This directory include tests on the Windows platform and can be executed locally. The test framework and set of tests are replicating the non-Windows tests under e2e_node, however, Windows support is still in the early stage, and not all tests are supported yet. Remote execution is planned as the next step.
For general background on node e2e tests, see the SIG Node Node End-to-End Tests guide.
*Note: There is no scheduler running. The e2e tests have to do manual nodeName assignment.
Running tests
Locally
Why run tests locally? It is much faster than running tests remotely.
Prerequisites:
- containerd, containerd will need to be ran with admin privilege
- Working CNI
- Ensure that you have a valid CNI configuration. For testing purposes, a nat configuration should work.
From the Kubernetes base directory, run with admin privilege:
go build -o ./test/e2e_node_windows/_output/kubelet.exe .\cmd\kubelet\
go build -o ./test/e2e_node_windows/_output/kube-log-runner.exe .\staging\src\k8s.io\component-base\logs\kube-log-runner
go test ./test/e2e_node_windows -c
.\e2e_node_windows.test.exe --bearer-token=vQIYfdCt7wIFOZtO --test.v --test.paniconexit0 --container-runtime-endpoint "npipe://./pipe/containerd-containerd" --prepull-images=false --ginkgo.focus "when creating a windows static pod" --k8s-bin-dir ./test/e2e_node_windows/_output/
It will run the specified windows e2e node tests, which will in turn:
- Build the Kuberlet source code
- Start a local instance of etcd
- Start a local instance of kube-apiserver
- Start a local instance of kubelet
- Run the test using the locally started processes
- Output the test results to STDOUT
- Stop kubelet, kube-apiserver, and etcd
Log files
Test execution produces several log streams:
- Ginkgo /
go testoutput (pass/fail, test logs): written to STDOUT when--test.vis used. Redirect with shell pipes if you need a file copy (e.g.... > run.log 2>&1). services.log(etcd + kube-apiserver wrapper output): written to<report-dir>/services.log.kubelet.log(kubelet output): written to<report-dir>/kubelet.log.
<report-dir> is controlled by the --report-dir=<path> flag. If not set, the wrapper log files are created in the test binary's current working directory.
Cross-building from Linux
The Kubernetes dockerized build handles cross-compilation automatically. To build the kubelet and the Windows node e2e test binary from a Linux host:
# Build kubelet.exe, kube-log-runner.exe and the e2e test binary for Windows
KUBE_BUILD_PLATFORMS=windows/amd64 make WHAT="cmd/kubelet staging/src/k8s.io/component-base/logs/kube-log-runner test/e2e_node_windows/e2e_node_windows.test"
Or build them separately:
# Build only kubelet.exe
KUBE_BUILD_PLATFORMS=windows/amd64 make WHAT="cmd/kubelet"
# Build only the e2e test binary
KUBE_BUILD_PLATFORMS=windows/amd64 make WHAT="test/e2e_node_windows/e2e_node_windows.test"
The output binaries will be placed under _output/dockerized/bin/windows/amd64/.
Once built, copy the binaries to the Windows test machine and run as described in the Locally section above.