Static Pods in Kubernetes

?????????????????? ????????????? are a hidden gem in Kubernetes, offering a way to manage specific workloads directly on individual nodes.

???????? ?????? ???????????? ?????????

Unlike regular pods managed by the Kubernetes control plane, static pods are managed directly by the kubelet daemon on a specific node. The kubelet watches for pod definitions and restarts them if they fail. This makes them ideal for critical system services or bootstrapping a cluster where control plane components need deployment directly on the nodes.

?????? ??????????????????????????????:

? Managed directly by the kubelet daemon

? Not observable by the API server

? Always bound to one Kubelet on a specific node

? Mirror pods are created on the API server, but cannot be controlled from there

When you create a static pod on a node, the kubelet on that node automatically creates a mirror pod on the Kubernetes API server. This mirror pod is a virtual representation of the static pod and is used to provide visibility into the pod's status.

However, there's an important distinction: the mirror pod on the API server is read-only. You cannot use the Kubernetes API or tools like kubectl to manage or control the static pod through its mirror pod.

Here are some key implications:

• Cannot be deleted: You cannot delete a static pod by deleting its mirror pod on the API server. The kubelet will simply recreate the mirror pod.
• Cannot be updated: You cannot update a static pod by updating its mirror pod on the API server. Any changes will be ignored.
• Cannot be scaled: You cannot scale a static pod using its mirror pod on the API server.

The only way to manage a static pod is through the kubelet on the node where the pod is running. You can do this by modifying the pod's configuration file or by using the crictl command-line tool.

There are two main ways to configure static pods:

???????? ???????????? ????????????: This approach involves placing pod definition files (YAML or JSON format) in a specific directory on the node. The kubelet periodically scans this directory and automatically creates or removes pods based on the presence or absence of these files.

??????-????????????: Here, the pod definition file resides on a web server. The kubelet is configured with the URL of this file, downloads it periodically, and interprets it as a list of pods to manage.

Let's Get Hands-On (File System Example): Imagine you want to run a simple web server as a static pod on a specific node (say, my-node1). Here's what you'd do:

? Create the Pod Definition: Create a YAML file defining your web server pod (e.g., static-web.yaml) with details like container image and port mapping.

? Choose a Directory: Select a directory on my-node1 for storing pod definitions (e.g., /etc/kubernetes/manifests).

? Place the File: Move your static-web.yaml file to the chosen directory.

? Configure the kubelet: Set the staticPodPath value in the kubelet configuration file to point to the chosen directory. Restart the kubelet for changes to take effect.

Web-Hosted Example: For a web-hosted configuration, follow these steps:

? Create the Pod Definition (Again!): Prepare your static-web.yaml file as before.

? Host the File: Store the file on a web server and obtain the URL.

? Configure the kubelet: Configure the kubelet with the --manifest-url argument pointing to the web server URL. Restart the kubelet.

???????????????? ???? ???????????? ????????:

? Simple Management: Static pods offer a straightforward way to manage critical services on individual nodes.

? Flexibility: You can easily update the pod definition by modifying the respective configuration file.

Keep in Mind:

? Limited Scope: Static pods are not ideal for managing pods across multiple nodes. Consider using DaemonSets for such scenarios.

? Limited Functionality: Static pods cannot reference other Kubernetes resources like ServiceAccounts, ConfigMaps or Secrets.

? Static pods do not support ephemeral containers.

Kubernetes #???????????????????? #k8s