It's been a long time since Kubernetes stopped to use Docker
as a runtime. Modified script to stop Docker as Kubelet is using
containerd directly. Removed Docker-specific logic and variables,
adjusted comments and configuration.
Store logs in a temporary subdirectory under the artifacts directory
when running in CI. This ensures logs are available in the prow
web UI for easier access and debugging.
Configure and start containerd before starting Docker, ensuring that
Docker detects and uses the running containerd instance instead of
launching its own. This allows us to customize containerd’s
configuration, such as enabling CDI support, which is not possible when
Docker manages containerd itself.
Set root and state paths for containerd to make it working the same way
as when Docker runs it.
- Don't reinstall docker, containerd and runc as kubekins image
already has their recent versions.
- Avoid breaking dependencies when installing nfttables and kmod.
- Install only packages that don't exist in the image.
This may be useful during manual invocations to see what commands would be
executed and with which parameters, without actually running them.
But the main purpose is to use this mode in automated upgrade/downgrade testing
where the caller parses the output to execute those commands under its own
control. Such a caller can then replaced individual component binaries with
those from other releases.
Some ports (apiserver, one kubelet port) were already configurable.
Several others were not.
Primarily this is done to document the ports which are in used by the different
components.
This started to show up now as linter hints at the start of the 1.34 cycle in
all PRs which modify the API. We don't want to enforce that convention in that
generated code, so suppressing it.
If the command failed in the <( ... ) expression, the return code was ignored
and the script continued with potentially no output. Not likely, but it's still
better to invoke the command where pipefail will catch a non-zero exit
code. For example, broken test registration could cause this.
There should be no log output, but if there is, failing explicitly is better
than ignoring it (on stderr) or treating it like an image (on stdout). Found
when experimenting with the logging configuration of e2e.test, currently there
is no such unwanted log output.
Before:
Diffing e2e image list ...
--- /dev/fd/63 2025-06-24 09:32:43.736397729 +0200
+++ /dev/fd/62 2025-06-24 09:32:43.736397729 +0200
@@ -5,7 +5,7 @@ invalid.registry.k8s.io/invalid/alpine
registry.k8s.io/build-image/distroless-iptables
registry.k8s.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver
registry.k8s.io/e2e-test-images/agnhost
-registry.k8s.io/e2e-test-images/apparmor-loader
+registry.k8s.io/e2e-test-images/apparmor-no-such-image
registry.k8s.io/e2e-test-images/busybox
registry.k8s.io/e2e-test-images/httpd
registry.k8s.io/e2e-test-images/ipc-utils
FAIL: e2e images do not match the approved list!
For this test, apparmor-loader was commented out in .permitted-images (making
it a forbidden unknown image) and apparmor-no-such-image was added (making it
an obsolete image).
Problems with the output:
- The position of old and new image lists was reversed.
- It's not clear what is being diffed. Not referencing .permitted-images
directly probably was meant to discourage using some image other than
agnhost, but developers can easily find the file anyway and are shown
some other images in the diff context.
After:
Diffing e2e image list ...
obsolete image: registry.k8s.io/e2e-test-images/apparmor-no-such-image
forbidden image: registry.k8s.io/e2e-test-images/apparmor-loader
FAIL: current e2e images do not match the approved list in test/images/.permitted-images!
This mentions test/images/.permitted-images because developers might have to
edit it if some image really becomes obsolete.
This comes up periodically; bumping to v5 introduces issues with
replace operations in JSON patches. k/k relies on non-RFC-compliant
operations which v5 no longer allows.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
