Kubeadm部署的Kubernetes 1.21.3裸金属集群能否为单个工作节点配置不同容器运行时或版本？

Absolutely! You can run a distinct container runtime (or even a different version of the same runtime) on an individual worker node in your kubeadm-deployed Kubernetes 1.21.3 cluster. This is precisely what the Container Runtime Interface (CRI) was built to enable—Kubernetes’ modular design intentionally decouples the control plane from the underlying container runtime layer, allowing per-node runtime flexibility.

Here’s a step-by-step guide to make this work: #

1. Drain the target node to safely evict running pods (avoid disrupting workloads):

   kubectl drain <your-worker-node-name> --ignore-daemonsets
   

   The --ignore-daemonsets flag skips evicting daemonset pods, which are expected to run on every node.

2. Stop existing runtime and kubelet services on the node:
   For example, if you’re replacing Docker:

   sudo systemctl stop kubelet docker containerd
   sudo systemctl disable docker containerd # Optional, if you don't want it to start on boot
   

3. Install your new container runtime
   Ensure the runtime is compatible with Kubernetes 1.21.3:

   • Containerd: Minimum version 1.4.0
   • CRI-O: Minimum version 1.21.x
   • Docker: Supported via the built-in dockershim (Kubernetes 1.21 still includes this; you’ll need Docker 19.03.x or newer)
     Follow standard installation steps for your chosen runtime, making sure to enable its CRI socket (most runtimes expose this at a Unix socket like unix:///run/containerd/containerd.sock for containerd).

4. Configure kubelet to use the new runtime
   Edit the kubelet config file (typically at /var/lib/kubelet/config.yaml) to update the runtime endpoints:

   runtimeEndpoint: "unix:///run/containerd/containerd.sock"
   imageEndpoint: "unix:///run/containerd/containerd.sock"
   

   Alternatively, update the kubelet’s systemd service file (usually at /etc/systemd/system/kubelet.service.d/10-kubeadm.conf) to add/modify the --container-runtime-endpoint flag:

   Environment="KUBELET_EXTRA_ARGS=--container-runtime-endpoint=unix:///run/containerd/containerd.sock"
   

5. Restart kubelet and uncordon the node

   sudo systemctl daemon-reload
   sudo systemctl start kubelet
   kubectl uncordon <your-worker-node-name>
   

Key considerations to keep in mind: #

• Compatibility checks: Always verify that your chosen runtime version aligns with Kubernetes 1.21.3’s supported versions—mismatches can cause unexpected pod failures or node registration issues.
• Workload scheduling: If your application requires the new runtime, use node affinity or taints/tolerations to ensure only relevant pods are scheduled to this node. For example:

  kubectl label nodes <your-worker-node-name> container-runtime=containerd
  

  Then add affinity rules to your pod specs to target this label.
• Maintenance differences: Different runtimes use different tools for debugging (e.g., crictl for containerd/CRI-O vs. docker for Docker). You’ll need to use the appropriate tooling when troubleshooting pods on this node.
• Dockershim note: Since you’re on Kubernetes 1.21.3, the dockershim is still included, so switching between Docker and other runtimes won’t require extra work. If you plan to upgrade to Kubernetes 1.24+ later, keep in mind that dockershim was removed in that version—you’ll need to migrate to a CRI-compliant runtime like containerd for Docker-based nodes.

内容的提问来源于stack exchange，提问作者letthefireflieslive