Kubernetes控制平面组件：Kubelet 之 Static 静态 Pod

最新推荐文章于 2025-05-13 22:15:54 发布

grahamzhu

最新推荐文章于 2025-05-13 22:15:54 发布

阅读量961

点赞数 16

分类专栏：云原生学习专栏文章标签： kubernetes kubelet k8s static pod 静态pod Mirror Pod 镜像pod

本文链接：https://blog.csdn.net/a1369760658/article/details/147869195

版权

云原生学习专栏专栏收录该内容

97 篇文章

订阅专栏

#王者杯·14天创作挑战营·第1期#

云原生学习路线导航页（持续更新中）

kubernetes学习系列快捷链接

本文是 kubernetes 控制面组件 kubelet 系列文章，本篇主要讲解静态static pod 相关内容，包括static pod概念、特性、只受kubelet管理的实现原理、与普通pod的对比、典型应用场景、注意事项等，最后还演示了如何创建一个static pod

希望大家多多点赞关注评论收藏，作者会更有动力继续编写技术文章

1.静态 Pod 是什么？

静态 Pod 是由 kubelet 直接管理 的 Pod，其定义文件存放在节点本地的特定目录中（如 /etc/kubernetes/manifests）。
kubelet 监控该目录，并根据其中的 YAML 文件自动创建、更新或删除 Pod。
静态 Pod 不经过 Kubernetes API Server 调度，而是由 kubelet 自主管理，通常用于部署集群核心组件（如 kube-apiserver、kube-scheduler 等）。

2.静态 Pod 的核心特性

2.1.独立于控制平面

不依赖 API Server：即使 Kubernetes 控制平面（如 API Server）未运行，kubelet 仍能通过静态 Pod 启动关键组件。
本地配置管理：Pod 的定义文件直接存储在节点上，修改后由 kubelet 自动同步。

2.2.镜像 Pod（Mirror Pod）

API Server 可见性：kubelet 会为每个静态 Pod 在 API Server 中创建一个对应的 镜像 Pod，但其状态是只读的。
static pod为什么只受kubelet的管理？
- kubelet会为每一个static pod，添加如下标识，使其成为一个镜像 mirror Pod
- 镜像pod可以让apiserver只读到pod的状态，但是当apiserver尝试更新 mirror pod时，会被kubelet立刻改回去
```
metadata:
  annotations:
    kubernetes.io/config.source: file  # 标识来源为本地文件
    kubernetes.io/config.hash: <hash>  # 文件内容哈希值
    kubernetes.io/config.mirror: <hash> # 标识为镜像 Pod
```

2.3.高可用性

自举能力：在集群初始化阶段，静态 Pod 用于启动控制平面组件（如 API Server），从而完成集群自举。
故障恢复：若 kubelet 重启，会重新加载静态 Pod 配置并恢复容器。

3.静态 Pod 的配置与管理

3.1.配置目录

默认目录：/etc/kubernetes/manifests（可通过 kubelet 参数 --pod-manifest-path 修改）。

# kubelet -h | grep pod-manifest-path
  --pod-manifest-path string                                 
  Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)

文件格式：标准的 Pod YAML 文件（无需包含 apiVersion 或 kind，但 kubelet 会自动处理）。

3.2.操作流程

创建静态 Pod：

# 将 Pod 定义文件放入配置目录
sudo cp my-static-pod.yaml /etc/kubernetes/manifests/

kubelet 自动检测：
- kubelet 监控目录变动，创建 Pod 并生成镜像 Pod。

查看运行状态：

# 查看本地运行的 Pod（需在节点上执行）
crictl pods

# 查看 API Server 中的镜像 Pod
kubectl get pods -n <namespace>

3.3.更新与删除

更新：直接修改配置文件 → kubelet 自动重启 Pod。
删除：从配置目录中删除文件 → kubelet 终止 Pod 并删除镜像 Pod。

4.静态 Pod vs. 普通 Pod

特性	静态 Pod	普通 Pod
管理方式	kubelet 直接管理本地文件	API Server 调度和管理
依赖项	无需 API Server	依赖 API Server 和控制平面组件
配置变更	修改节点本地文件	通过 `kubectl` 或 API 调用
高可用性	适合关键组件（如控制平面）	适合普通工作负载
可见性	通过镜像 Pod 在 API Server 中可见	直接通过 API Server 管理

5.静态 Pod 的典型应用场景

5.1.自举 Kubernetes 控制平面

场景：在集群初始化时，kubelet 通过静态 Pod 启动 kube-apiserver、kube-controller-manager、kube-scheduler 等组件。
优势：无需依赖已运行的 API Server，实现“鸡生蛋，蛋生鸡”的引导过程。

5.2.运行节点级关键服务

场景：部署日志收集器（如 Fluentd）、监控代理（如 Node Exporter）等需在每台节点运行的组件。
优势：避免依赖集群调度器，确保服务始终运行。

5.3.隔离关键组件

场景：在控制平面节点上，通过静态 Pod 运行 etcd，避免因 API Server 故障导致 etcd 不可用。
优势：组件独立于 Kubernetes 控制平面，提升稳定性。

6.注意事项与常见问题

6.1.配置文件权限

目录权限：确保 kubelet 有权限读取配置目录（通常为 root:root，权限 644）。
文件格式：YAML 文件必须语法正确，否则 kubelet 会忽略或报错。

6.2.镜像 Pod 的管理

禁止直接操作：
不要通过 kubectl delete 或 kubectl edit 操作镜像 Pod，kubelet 会立即重建它们。
状态同步延迟：
若镜像 Pod 状态与实际 Pod 不一致，检查 kubelet 日志：
```
journalctl -u kubelet | grep "SyncLoop"
```

6.3.与 DaemonSet 的区别

DaemonSet：由 API Server 管理，确保每个节点运行一个 Pod 副本。
静态 Pod：由 kubelet 直接管理，无需 API Server 参与，适合更底层的组件。

6.4.常见错误

Pod 无法启动：
- 检查 YAML 文件语法（如缩进错误）。
- 查看容器日志：crictl logs <container-id>。
镜像 Pod 未生成：
- 确认 kubelet 的 --pod-manifest-path 参数配置正确。
- 检查 kubelet 是否正常运行：systemctl status kubelet。

7.示例：创建一个静态 Pod

7.1.定义文件 `nginx-static-pod.yaml`

apiVersion: v1
kind: Pod
metadata:
  name: static-nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

7.2.部署到配置目录

sudo cp nginx-static-pod.yaml /etc/kubernetes/manifests/

7.3.验证运行状态

# 在节点上查看运行的 Pod
crictl pods

# 在集群中查看镜像 Pod（名称格式为 static-nginx-<node-name>）
kubectl get pods --all-namespaces | grep static-nginx

8.总结

静态 Pod 是 kubelet 直接管理的特殊 Pod，适用于运行集群核心组件或节点级服务。
其通过本地配置文件实现独立于 API Server 的管理，结合镜像 Pod 机制在集群中可见。合理使用静态 Pod 可提升关键组件的可靠性和集群自举能力。