We are installing a Replicated application using kURL on a single-node Azure VM running Ubuntu 24.04.
Environment:
- Cloud: Microsoft Azure
- OS: Ubuntu 24.04
- Hostname: azure-ops-poc-1
- Node IP: 10.0.0.11
- Kubernetes: 1.29.5
- containerd add-on: 1.6.32
- Flannel: 0.25.3
- EKCO: 0.28.14
- OpenEBS: 4.0.0
- kURL installer utilities: v2026.07.30-0
- Installation log: /var/log/kurl/install-2026-08-04T10-44-50.log
The installation is currently paused at:
“Host preflights have warnings”
“Kubernetes API Health: Error connecting to Kubernetes API at https://localhost:6443/healthz”
“Would you like to continue?”
All other listed preflights pass, including Kubernetes certificates, etcd certificates, CPU, memory, disk space, NTP, OS support, and connectivity to replicated.app.
Observed behavior:
- etcd starts successfully:
- Database opens successfully.
- Initial corruption check passes.
- The single member is elected leader.
- The etcd health endpoint on http://127.0.0.1:2381 returns HTTP 200 with health=true.
- While etcd is healthy, containerd receives an explicit StopContainer request:
- containerd logs: StopContainer with timeout 30
- containerd sends SIGTERM
- etcd logs: “received signal; shutting down”, signal “terminated”
- etcd exits with exitCode 0 and reason Completed
- kube-apiserver also starts successfully:
- Informer caches synchronize.
- API controllers start.
- The process begins listening on port 6443.
- A few seconds later, containerd receives an explicit StopContainer request for kube-apiserver:
- kube-apiserver shuts down normally.
- It stops listening on port 6443.
- It exits with exitCode 0 and reason Completed.
- After etcd is unavailable, subsequent kube-apiserver attempts fail with:
- dial tcp 127.0.0.1:2379: connect: connection refused
- Error creating leases: error creating storage factory: context deadline exceeded
- The cycle repeats with increasing container attempt numbers and CrashLoopBackOff delays.
Additional findings:
- etcd’s health endpoint returns HTTP 200 while the process is running.
- kube-apiserver is sometimes terminated approximately four seconds after starting.
- Its startup and liveness probes both have an initial delay of 10 seconds, so those probes cannot explain the four-second termination.
- No etcd or kube-apiserver liveness failure is present in the kubelet journal.
- containerd and kubelet are the only relevant systemd services running.
- The kURL installer is paused waiting for user confirmation.
- The static pod manifests have not been rewritten during the failures.
- /etc/kubernetes/manifests contains exactly:
- etcd.yaml
- kube-apiserver.yaml
- kube-controller-manager.yaml
- kube-scheduler.yaml
- .kubelet-keep
Questions:
- Is this a known kURL issue on Ubuntu 24.04, Azure, or this combination of Kubernetes and containerd versions?
- What component could be requesting the CRI StopContainer operations for healthy static control-plane pods?
- Should we abort/reset this installation, or is it safe to continue past the Kubernetes API Health warning?
- Is there a newer recommended Kubernetes, containerd, or kURL installer specification for Ubuntu 24.04?
- Are there additional logs, support bundles, or debugging options you would like us to collect before changing the host?
Additional containerd finding:
Ubuntu reports the installed host package as:
containerd 2.2.1-0ubuntu1~24.04.3
The kURL installer specification is using the containerd 1.6.32 add-on.
We understand from the Replicated documentation that the Ubuntu 24.04 host package version does not need to match the containerd add-on version. However, please confirm whether installing the containerd 1.6.32 add-on over an Ubuntu 24.04 host package at version 2.2.1 is a tested and supported combination.
Please also confirm whether this combination could cause kubelet to repeatedly issue CRI StopContainer requests for healthy static control-plane containers.