Q : What is the process for running Kubelet in standalone mode?

Running the Kubelet in standalone mode allows you to run containers on a single server without a Kubernetes control plane (API server, etcd, controller manager).

In this mode, the Kubelet acts as a local process supervisor (similar to supervisord or systemd), managing Static Pods defined in local manifest files rather than receiving instructions from an API server.

Here is the process for setting up a standalone Kubelet on a Linux system.

1. Prerequisites and System Prep

Before installing the binary, the underlying Linux OS must be prepared to handle container networking and resource management.

• Disable Swap: By default, the Kubelet fails to start if swap is enabled. You must disable it (swapoff -a) or configure the Kubelet with failSwapOn: false,.
• Enable IPv4 Forwarding: You must enable IP forwarding (net.ipv4.ip_forward = 1) to allow traffic to flow to and from containers.
• Install a Container Runtime (CRI): The Kubelet needs a runtime to execute containers. You must install a CRI-compliant runtime like CRI-O or containerd and ensure the service (e.g., crio.service) is running via systemd,.
• Install CNI Plugins: Unlike Docker, CRI runtimes usually rely on standard CNI plugins (bridge, loopback, host-local) for networking. You must download these binaries to /opt/cni/bin and configure a network bridge configuration file in /etc/cni/net.d/ so the Kubelet can configure the pod network.

2. Kubelet Configuration

The Kubelet behavior is governed by a KubeletConfiguration file (YAML). For standalone mode, specific fields are critical:

1. Define staticPodPath: This tells the Kubelet which local directory to watch for Pod manifests (e.g., /etc/kubernetes/manifests).
2. Configure API Access: Since there is no control plane, you typically disable webhook authentication and set authorization to AlwaysAllow to permit local interaction. You also configure the read-only port (default 10255) to query the Kubelet locally,.
3. CRI Endpoint: Point the Kubelet to your runtime socket (e.g., unix:///var/run/crio/crio.sock).

Example kubelet.yaml:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  webhook:
    enabled: false # No API server to contact
authorization:
  mode: AlwaysAllow
address: 127.0.0.1
staticPodPath: /etc/kubernetes/manifests # <--- The critical setting for standalone
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock

3. Creating the Systemd Unit

You run the Kubelet as a systemd service. The defining characteristic of standalone mode is the omission of the --kubeconfig flag in the startup command,.

Example /etc/systemd/system/kubelet.service:

[Unit]
Description=Kubelet
[Service]
ExecStart=/usr/bin/kubelet \
  --config=/etc/kubernetes/kubelet.yaml \
  --v=2
Restart=always
[Install]
WantedBy=multi-user.target

Note: If the --kubeconfig flag is present, the Kubelet will attempt to contact an API server and fail. Removing it forces the Kubelet into standalone mode.

4. Running Workloads (Static Pods)

Once the Kubelet service is started (systemctl start kubelet), it enters a loop watching the directory configured in staticPodPath.

1. Create a Manifest: Place a standard Pod YAML file into /etc/kubernetes/manifests.
2. Execution: The Kubelet detects the file, parses it, and instructs the CRI (CRI-O/containerd) to pull images and start containers,.
3. Lifecycle Management: If the process crashes, the Kubelet restarts it. If you delete the source file from the directory, the Kubelet terminates the Pod,.

5. Verification and Debugging

Since you cannot use kubectl (which requires an API server), you interact with the node using direct tools:

• Query Kubelet API: You can query the Kubelet's local API to see running pods: curl http://localhost:10255/pods.
• CRI Tools (crictl): Use crictl ps to inspect the running containers at the runtime level. This allows you to verify that the Kubelet successfully instructed the runtime to launch the containers,.

Limitations of Standalone Mode

It is important to note what you cannot do in this mode:

• No ConfigMaps/Secrets: You cannot reference these API objects; configurations must be hardcoded or mounted via host files.
• No Service Discovery: Standard Kubernetes Services and DNS resolution relying on the control plane will not function.
• No DaemonSets/Deployments: The Kubelet only understands Pods. Higher-level abstractions are not available.