726 lines
25 KiB
Markdown
726 lines
25 KiB
Markdown
---
|
||
tags: [k8s, pod, devops]
|
||
create time: 2026-07-07 15:48
|
||
---
|
||
|
||
# Pod — Kubernetes 最小调度单元
|
||
|
||
## 概述
|
||
|
||
Pod 是 Kubernetes 中**最小的可部署和调度单元**。它不是一个容器，而是一组（一个或多个）共享网络和存储资源的容器的逻辑封装。为什么 Kubernetes 不直接调度容器，而是引入了 Pod 这一抽象层？因为在实际业务中，多个紧密协作的进程往往需要共享同一个 IP 地址、端口空间和卷挂载——比如一个 Web 应用容器和一个负责收集日志的 sidecar 容器。Pod 正是为了解决这种「亲密耦合进程协同运行」的需求而设计的。理解 Pod，是掌握 Kubernetes 一切上层抽象（Deployment、StatefulSet、DaemonSet 等）的基础。
|
||
|
||
## Pod 的本质
|
||
|
||
### 共享网络命名空间
|
||
|
||
同一个 Pod 内的所有容器共享**同一个网络命名空间（Network Namespace）**，这意味着：
|
||
|
||
- 它们拥有**相同的 IP 地址**
|
||
- 它们可以**通过 localhost 互相通信**
|
||
- 端口空间是共享的，因此同一 Pod 内的容器**不能绑定相同的端口**
|
||
|
||
> [!question] 为什么不直接调度容器？
|
||
> 因为单个容器通常只运行一个进程（这是容器设计的最佳实践）。但在很多场景下，多个进程需要紧密协作——比如 Nginx + 日志收集器、主应用 + 配置热加载 sidecar。如果让调度器去理解「哪些容器应该放在一起」，复杂度会急剧上升。Pod 将这个决策交给了用户：你来决定哪些容器属于同一个 Pod。
|
||
|
||
### Pause 容器 — Pod 的「灵魂」
|
||
|
||
每个 Kubernetes Pod 启动时，都会先创建一个特殊的**Pause 容器**（也叫 infra 容器），它是 Pod 的第一个容器，也是整个 Pod 的「根进程」。其他业务容器通过加入 Pause 容器的 Network Namespace 和 PID Namespace 来实现共享。
|
||
|
||
```mermaid
|
||
graph TB
|
||
subgraph Pod
|
||
P["Pause 容器<br/>(infra container)"]
|
||
C1["业务容器 A"]
|
||
C2["业务容器 B<br/>(sidecar)"]
|
||
C3["业务容器 C"]
|
||
end
|
||
|
||
P -->|"提供 Network NS"| C1
|
||
P -->|"提供 Network NS"| C2
|
||
P -->|"提供 Network NS"| C3
|
||
P -->|"提供 PID NS (可选)"| C1
|
||
P -->|"提供 PID NS (可选)"| C2
|
||
P -->|"提供 PID NS (可选)"| C3
|
||
```
|
||
|
||
Pause 容器的职责非常简单：
|
||
|
||
1. **持有 Network Namespace** — 确保 Pod 的 IP 地址在所有容器生命周期内保持不变
|
||
2. **充当 PID 1** — 回收僵尸进程（zombie reaping）
|
||
3. **极轻量** — 通常只有几百 KB，使用 `registry.k8s.io/pause` 镜像
|
||
|
||
> [!info] Pause 容器的代码只有几百行
|
||
> 它的核心逻辑就是一个无限循环的 `pause()` 系统调用。正因为足够简单，它几乎不会出问题，可以稳定地为 Pod 内所有容器提供基础运行环境。
|
||
|
||
### 容器与 Pod 的关系（1:N）
|
||
|
||
一个 Pod 可以包含多个容器，典型模式如下：
|
||
|
||
| 模式 | 说明 | 示例 |
|
||
|------|------|------|
|
||
| 单容器 Pod | 最常见的场景，一个 Pod 运行一个应用容器 | 一个 Go Web 服务 |
|
||
| 多容器 Pod (sidecar) | 主容器 + 辅助容器，辅助容器扩展主容器功能 | Nginx + Filebeat 日志收集 |
|
||
| 多容器 Pod (adapter) | 辅助容器将主容器的输出转换为标准格式 | 应用日志 → Fluentd 标准格式 |
|
||
| 多容器 Pod (ambassador) | 辅助容器代理网络请求 | 应用 → Envoy Proxy → 外部服务 |
|
||
|
||
```yaml
|
||
# 一个多容器 Pod 的简单示例：Web 服务 + 日志收集 sidecar
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: web-with-logging
|
||
spec:
|
||
containers:
|
||
- name: web
|
||
image: nginx:1.25
|
||
ports:
|
||
- containerPort: 80
|
||
volumeMounts:
|
||
- name: log-volume
|
||
mountPath: /var/log/nginx
|
||
- name: log-collector
|
||
image: fluent/fluent-bit:latest
|
||
volumeMounts:
|
||
- name: log-volume
|
||
mountPath: /var/log/nginx
|
||
readOnly: true
|
||
volumes:
|
||
- name: log-volume
|
||
emptyDir: {}
|
||
```
|
||
|
||
两个容器共享 `log-volume` 卷，Web 容器写入日志，Fluent Bit 容器读取并转发——这是经典的日志收集 sidecar 模式。
|
||
|
||
## Pod 生命周期
|
||
|
||
Pod 的生命周期由**阶段（Phase）**和**条件（Condition）**共同描述。从创建到销毁，Pod 经历以下主要阶段：
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> Pending: kubectl apply / API 创建
|
||
Pending --> Running: 至少一个容器启动成功
|
||
Pending --> Failed: 拉取镜像失败 / 调度失败
|
||
Running --> Succeeded: 所有容器正常退出(exit 0)
|
||
Running --> Failed: 容器异常退出 / OOMKilled
|
||
Running --> Unknown: Node 失联, 无法获取状态
|
||
Succeeded --> [*]
|
||
Failed --> [*]
|
||
Unknown --> Running: Node 恢复通信
|
||
Unknown --> Failed: 确认 Pod 已丢失
|
||
```
|
||
|
||
### Init Containers
|
||
|
||
Init Containers 是在**主容器启动之前**按顺序运行的容器。它们主要用于完成一些前置条件的检查和准备工作。
|
||
|
||
**与主容器的区别：**
|
||
|
||
| 特性 | Init Container | 主容器 (App Container) |
|
||
|------|---------------|----------------------|
|
||
| 执行顺序 | 严格按顺序依次执行 | 并行启动 |
|
||
| 失败行为 | 失败后 Pod 重启（遵循 restartPolicy） | 失败后根据探针配置重启 |
|
||
| 探针支持 | 不支持 liveness/readiness probe | 支持 |
|
||
| 用途 | 前置条件检查、等待依赖、初始化配置 | 运行业务逻辑 |
|
||
| 资源计算 | 独立于主容器的资源请求 | 作为整体调度依据 |
|
||
|
||
> [!tip] 何时使用 Init Container？
|
||
> 当你需要在主容器启动前完成某些「只执行一次」的任务时——比如等待数据库就绪、下载配置文件、执行数据库迁移等——Init Container 是最佳选择。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: app-with-init
|
||
spec:
|
||
initContainers:
|
||
# 第一个 Init Container：等待数据库就绪
|
||
- name: wait-for-db
|
||
image: busybox:1.36
|
||
command:
|
||
- sh
|
||
- -c
|
||
- |
|
||
until nc -z mysql-service 3306; do
|
||
echo "Waiting for MySQL..."
|
||
sleep 2
|
||
done
|
||
echo "MySQL is ready!"
|
||
# 第二个 Init Container：执行数据库迁移
|
||
- name: db-migration
|
||
image: myapp/migration:v1.2
|
||
env:
|
||
- name: DB_HOST
|
||
value: "mysql-service"
|
||
containers:
|
||
- name: app
|
||
image: myapp/api:v1.2
|
||
ports:
|
||
- containerPort: 8080
|
||
```
|
||
|
||
上述示例中，两个 Init Container **严格按顺序**执行：先等 MySQL 可达，再执行数据库迁移。只有两者都成功（exit 0）后，主容器 `app` 才会启动。
|
||
|
||
### 容器探针
|
||
|
||
Kubernetes 提供三种探针来监控容器的健康状态：
|
||
|
||
| 探针类型 | 作用 | 失败后果 | 典型场景 |
|
||
|---------|------|---------|---------|
|
||
| `livenessProbe` | 检测容器是否**存活** | 杀死容器并重启 | 进程死锁、无限循环 |
|
||
| `readinessProbe` | 检测容器是否**就绪**接收流量 | 从 Service 的 Endpoints 中移除 | 启动预热、临时过载 |
|
||
| `startupProbe` | 检测容器是否**启动完成** | 杀死容器并重启 | 启动耗时长的应用（如 Java） |
|
||
|
||
> [!warning] startupProbe 与 livenessProbe 的关系
|
||
> 当配置了 `startupProbe` 时，在它成功之前，`livenessProbe` 和 `readinessProbe` 都不会执行。这是为了防止启动时间较长的应用被误判为不健康。`startupProbe` 的 `failureThreshold * periodSeconds` 应该大于应用的最大启动时间。
|
||
|
||
**探针支持的检测方式：**
|
||
|
||
- **httpGet** — 发送 HTTP GET 请求，2xx/3xx 视为成功
|
||
- **tcpSocket** — 尝试 TCP 连接，端口可达视为成功
|
||
- **exec** — 执行命令，exit code 0 视为成功
|
||
- **grpc** — gRPC 健康检查协议（Kubernetes 1.24+）
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: probes-demo
|
||
spec:
|
||
containers:
|
||
- name: app
|
||
image: myapp:v1
|
||
ports:
|
||
- containerPort: 8080
|
||
|
||
# 启动探针：最多给 60 秒启动时间 (10 次 x 6 秒)
|
||
startupProbe:
|
||
httpGet:
|
||
path: /healthz
|
||
port: 8080
|
||
failureThreshold: 10
|
||
periodSeconds: 6
|
||
|
||
# 存活探针：每 15 秒检测一次，连续 3 次失败则重启
|
||
livenessProbe:
|
||
httpGet:
|
||
path: /healthz
|
||
port: 8080
|
||
initialDelaySeconds: 0 # startupProbe 成功后才开始
|
||
periodSeconds: 15
|
||
failureThreshold: 3
|
||
timeoutSeconds: 5
|
||
|
||
# 就绪探针：每 5 秒检测一次，失败则从 Endpoints 移除
|
||
readinessProbe:
|
||
httpGet:
|
||
path: /ready
|
||
port: 8080
|
||
periodSeconds: 5
|
||
failureThreshold: 3
|
||
timeoutSeconds: 3
|
||
```
|
||
|
||
> [!tip] 最佳实践
|
||
> 生产环境中建议同时配置三种探针：`startupProbe` 保护慢启动应用、`livenessProbe` 检测死锁、`readinessProbe` 控制流量切换。`readinessProbe` 的检测频率可以比 `livenessProbe` 更高，因为它的失败不会触发重启。
|
||
|
||
### Pod 阶段（Phase）与条件（Condition）
|
||
|
||
**Pod Phase** 是对 Pod 在其生命周期中所处位置的高层概括：
|
||
|
||
| Phase | 说明 |
|
||
|-------|------|
|
||
| `Pending` | Pod 已被 API Server 接受，但尚未调度或容器镜像未拉取完成 |
|
||
| `Running` | Pod 已绑定到节点，且至少有一个容器处于运行状态 |
|
||
| `Succeeded` | 所有容器正常退出（exit 0），不会再重启 |
|
||
| `Failed` | 所有容器已终止，且至少有一个容器是非正常退出 |
|
||
| `Unknown` | 无法获取 Pod 状态，通常是与 Node 的通信中断 |
|
||
|
||
**Pod Conditions** 提供了更细粒度的状态信息，是一个数组，每个 Condition 包含以下字段：
|
||
|
||
```yaml
|
||
conditions:
|
||
- type: PodScheduled # 条件类型
|
||
status: "True" # True / False / Unknown
|
||
lastProbeTime: null # 上次探测时间
|
||
lastTransitionTime: "2026-07-07T07:00:00Z" # 上次状态转换时间
|
||
reason: "SchedulerCompletedSchedulingReason"
|
||
message: "Successfully assigned default/my-pod to node-1"
|
||
```
|
||
|
||
常见的 Condition Type：
|
||
|
||
| Type | 说明 |
|
||
|------|------|
|
||
| `PodScheduled` | Pod 已被调度到某个节点 |
|
||
| `Initialized` | 所有 Init Container 已成功完成 |
|
||
| `ContainersReady` | 所有容器都已就绪 |
|
||
| `Ready` | Pod 可以对外提供服务，被纳入 Service Endpoints |
|
||
|
||
```mermaid
|
||
graph LR
|
||
A["PodScheduled<br/>status: True"] --> B["Initialized<br/>status: True"]
|
||
B --> C["ContainersReady<br/>status: True"]
|
||
C --> D["Ready<br/>status: True"]
|
||
```
|
||
|
||
> [!info] Condition vs Phase
|
||
> Phase 是一个全局性的、互斥的状态值（一个 Pod 在同一时刻只有一个 Phase）。而 Conditions 是一组独立的布尔标志，一个 Pod 可以同时有多个 Condition 为 True。Conditions 通常用于精确排查 Pod 启动过程中的具体卡点。
|
||
|
||
## 资源管理
|
||
|
||
### Requests 与 Limits
|
||
|
||
Kubernetes 通过 `requests` 和 `limits` 两个维度来管理容器的资源：
|
||
|
||
- **requests（请求量）** — 调度器依据此值决定 Pod 放到哪个节点。是容器运行所需的**最小**资源量
|
||
- **limits（限制量）** — 容器可使用的**最大**资源量。超出限制时的行为取决于资源类型
|
||
|
||
```yaml
|
||
resources:
|
||
requests:
|
||
cpu: "250m" # 0.25 核
|
||
memory: "128Mi" # 128 MiB
|
||
limits:
|
||
cpu: "500m" # 0.5 核
|
||
memory: "256Mi" # 256 MiB
|
||
```
|
||
|
||
> [!question] CPU 超限和 Memory 超限的处理方式为什么不同？
|
||
> CPU 是**可压缩资源（compressible）**——超出 limit 时会被节流（throttle），进程不会被杀死。而内存是**不可压缩资源（incompressible）**——超出 limit 时进程会被 OOMKilled。这是因为 CPU 可以通过时间片轮转来降级服务，但内存一旦不足，系统无法「回收」已分配的内存页面。
|
||
|
||
### QoS（Quality of Service）三级分类
|
||
|
||
Kubernetes 根据 requests 和 limits 的配置将 Pod 分为三个 QoS 等级：
|
||
|
||
| QoS 等级 | 条件 | OOM 优先级 | 调度优先级 |
|
||
|----------|------|-----------|-----------|
|
||
| **Guaranteed** | 每个容器的 requests == limits | 最低（最后被杀） | 最高 |
|
||
| **Burstable** | 至少一个容器设置了 requests，且 requests < limits | 中等 | 中等 |
|
||
| **BestEffort** | 所有容器均未设置 requests 和 limits | 最高（最先被杀） | 最低 |
|
||
|
||
```yaml
|
||
# Guaranteed — requests 等于 limits
|
||
containers:
|
||
- name: critical-app
|
||
resources:
|
||
requests:
|
||
cpu: "1"
|
||
memory: "1Gi"
|
||
limits:
|
||
cpu: "1"
|
||
memory: "1Gi"
|
||
|
||
---
|
||
# Burstable — requests 小于 limits
|
||
containers:
|
||
- name: normal-app
|
||
resources:
|
||
requests:
|
||
cpu: "250m"
|
||
memory: "128Mi"
|
||
limits:
|
||
cpu: "1"
|
||
memory: "512Mi"
|
||
|
||
---
|
||
# BestEffort — 未设置任何 requests / limits
|
||
containers:
|
||
- name: batch-job
|
||
image: busybox
|
||
# 未配置 resources 字段
|
||
```
|
||
|
||
> [!warning] 生产环境严禁 BestEffort
|
||
> BestEffort Pod 在节点资源紧张时会被**最先驱逐**。在生产环境中，至少应为所有容器设置合理的 `requests`。
|
||
|
||
### OOM（Out of Memory）行为
|
||
|
||
当节点内存不足时，kubelet 会按照以下顺序选择 Pod 进行驱逐：
|
||
|
||
1. **BestEffort** Pod（OOM Score 最高）
|
||
2. **Burstable** Pod 中，实际内存使用量超过 requests 最多的
|
||
3. **Guaranteed** Pod（OOM Score 最低，最后被杀）
|
||
|
||
同时，Linux 内核的 OOM Killer 也会根据进程的 `oom_score_adj` 值来决定杀哪个进程。Kubernetes 为不同 QoS 等级的容器设置了不同的 `oom_score_adj`：
|
||
|
||
| QoS 等级 | oom_score_adj |
|
||
|----------|--------------|
|
||
| Guaranteed | -998 |
|
||
| Burstable | 2 ~ 1000（按比例） |
|
||
| BestEffort | 1000 |
|
||
|
||
### CPU 节流机制
|
||
|
||
当容器的 CPU 使用超过 limit 时，Linux 内核的 CFS（Completely Fair Scheduler）会通过 **CFS Bandwidth Throttling** 机制限制容器的 CPU 时间片分配。
|
||
|
||
表现症状：
|
||
- 容器进程运行变慢，响应延迟升高
|
||
- `container_cpu_cfs_throttled_periods_total` 指标持续增长
|
||
- 应用程序的 P99 延迟出现周期性毛刺
|
||
|
||
> [!tip] 避免 CPU 节流
|
||
> 如果发现应用延迟升高且 CPU throttling 严重，考虑：① 提高 CPU limit；② 将 limit 设置为与 request 相同（Guaranteed QoS，不会被节流但调度更严格）；③ 使用 `CPU Manager Policy: static` 获得独占 CPU 核心。
|
||
|
||
## Sidecar 模式
|
||
|
||
Sidecar 模式是 Pod 多容器设计中最常用的架构模式。通过在 Pod 中添加辅助容器（sidecar），可以在不修改主应用代码的前提下扩展其功能。
|
||
|
||
### 日志收集
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: app-logging-sidecar
|
||
spec:
|
||
containers:
|
||
- name: app
|
||
image: myapp:v2
|
||
volumeMounts:
|
||
- name: shared-logs
|
||
mountPath: /var/log/app
|
||
- name: log-shipper
|
||
image: fluent/fluent-bit:2.2
|
||
volumeMounts:
|
||
- name: shared-logs
|
||
mountPath: /var/log/app
|
||
readOnly: true
|
||
- name: fluentbit-config
|
||
mountPath: /fluent-bit/etc/
|
||
resources:
|
||
requests:
|
||
cpu: "50m"
|
||
memory: "64Mi"
|
||
limits:
|
||
cpu: "200m"
|
||
memory: "128Mi"
|
||
volumes:
|
||
- name: shared-logs
|
||
emptyDir: {}
|
||
- name: fluentbit-config
|
||
configMap:
|
||
name: fluentbit-config
|
||
```
|
||
|
||
### 服务网格代理（Service Mesh Proxy）
|
||
|
||
这是 Istio、Linkerd 等服务网格的典型数据面模式——每个应用 Pod 旁注入一个 Envoy sidecar 代理：
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: app-with-proxy
|
||
annotations:
|
||
sidecar.istio.io/inject: "true"
|
||
spec:
|
||
containers:
|
||
- name: app
|
||
image: myapp:v3
|
||
ports:
|
||
- containerPort: 8080
|
||
# 以下通常由 Istio 自动注入，这里手动展示
|
||
- name: istio-proxy
|
||
image: envoyproxy/envoy:v1.28
|
||
args:
|
||
- proxy
|
||
- sidecar
|
||
- --domain
|
||
- $(POD_NAMESPACE).svc.cluster.local
|
||
ports:
|
||
- containerPort: 15001 # Envoy 入口
|
||
- containerPort: 15006 # Envoy 出口
|
||
env:
|
||
- name: POD_NAME
|
||
valueFrom:
|
||
fieldRef:
|
||
fieldPath: metadata.name
|
||
- name: POD_NAMESPACE
|
||
valueFrom:
|
||
fieldRef:
|
||
fieldPath: metadata.namespace
|
||
```
|
||
|
||
### 配置热更新（Reloader Sidecar）
|
||
|
||
某些应用不支持热加载配置文件，此时可以用一个 sidecar 监听 ConfigMap 变化并通知主容器：
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: app-config-reload
|
||
spec:
|
||
containers:
|
||
- name: app
|
||
image: nginx:1.25
|
||
volumeMounts:
|
||
- name: config-volume
|
||
mountPath: /etc/nginx/conf.d
|
||
- name: config-reloader
|
||
image: jimmidyson/configmap-reload:v0.13
|
||
args:
|
||
- --volume-dir=/config
|
||
- --webhook-url=http://localhost:8080/-/reload
|
||
volumeMounts:
|
||
- name: config-volume
|
||
mountPath: /config
|
||
readOnly: true
|
||
volumes:
|
||
- name: config-volume
|
||
configMap:
|
||
name: nginx-config
|
||
```
|
||
|
||
## Pod 调度基础
|
||
|
||
Kubernetes 调度器（kube-scheduler）负责将 Pod 分配到合适的节点上。Pod 本身可以通过以下字段影响调度决策：
|
||
|
||
### nodeSelector
|
||
|
||
最简单的调度约束，通过标签匹配将 Pod 调度到特定节点：
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: gpu-task
|
||
spec:
|
||
nodeSelector:
|
||
gpu: "true" # 必须调度到带有 gpu=true 标签的节点
|
||
disktype: "ssd"
|
||
containers:
|
||
- name: ml-trainer
|
||
image: pytorch:v2
|
||
```
|
||
|
||
### nodeName
|
||
|
||
直接指定节点名称，**跳过调度器**：
|
||
|
||
```yaml
|
||
spec:
|
||
nodeName: node-3 # 直接绑定到 node-3，不经过调度器
|
||
```
|
||
|
||
> [!warning] 慎用 nodeName
|
||
> 使用 `nodeName` 会绕过调度器的资源检查、亲和性计算和污点容忍判断。如果目标节点资源不足，Pod 会一直处于 Pending 状态。一般仅用于测试或特殊运维场景。
|
||
|
||
### 亲和性（Affinity）简介
|
||
|
||
亲和性提供了比 `nodeSelector` 更丰富的调度规则：
|
||
|
||
- **nodeAffinity** — 节点亲和性，支持硬性（required）和软性（preferred）规则
|
||
- **podAffinity** — Pod 亲和性，将 Pod 调度到与其他 Pod 相近的位置
|
||
- **podAntiAffinity** — Pod 反亲和性，将 Pod 调度到与其他 Pod 远离的位置
|
||
|
||
```yaml
|
||
affinity:
|
||
nodeAffinity:
|
||
requiredDuringSchedulingIgnoredDuringExecution: # 硬性要求
|
||
nodeSelectorTerms:
|
||
- matchExpressions:
|
||
- key: kubernetes.io/arch
|
||
operator: In
|
||
values:
|
||
- amd64
|
||
preferredDuringSchedulingIgnoredDuringExecution: # 软性偏好
|
||
- weight: 80
|
||
preference:
|
||
matchExpressions:
|
||
- key: zone
|
||
operator: In
|
||
values:
|
||
- cn-east-1a
|
||
```
|
||
|
||
> [!info] 深入阅读
|
||
> 调度器的完整机制（包括 Taint/Toleration、PriorityClass、拓扑分布约束等）将在 [[k8s-scheduler]] 中详细展开。
|
||
|
||
## 静态 Pod（Static Pod）
|
||
|
||
静态 Pod 是由 **kubelet 直接管理**的 Pod，不通过 API Server 创建。kubelet 会监视指定目录（默认为 `/etc/kubernetes/manifests/`）中的 YAML 文件，并自动创建和维护对应的 Pod。
|
||
|
||
### 特点
|
||
|
||
| 特性 | 静态 Pod | 普通 Pod |
|
||
|------|---------|---------|
|
||
| 管理者 | kubelet | API Server / Controller Manager |
|
||
| 存储位置 | 节点本地文件系统 | etcd |
|
||
| 是否出现在 API Server 中 | 是（kubelet 创建 mirror pod） | 是 |
|
||
| 是否受控制器管理 | 否 | 是（Deployment、StatefulSet 等） |
|
||
| 是否可被 kubectl 删除 | 否（需删除文件） | 是 |
|
||
|
||
### 用途
|
||
|
||
静态 Pod 最重要的用途是**部署控制平面组件**：
|
||
|
||
```bash
|
||
# kubeadm 部署的集群中，控制平面组件都是静态 Pod
|
||
/etc/kubernetes/manifests/
|
||
├── kube-apiserver.yaml
|
||
├── kube-controller-manager.yaml
|
||
├── kube-scheduler.yaml
|
||
└── etcd.yaml
|
||
```
|
||
|
||
```yaml
|
||
# /etc/kubernetes/manifests/kube-apiserver.yaml（简化示例）
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: kube-apiserver
|
||
namespace: kube-system
|
||
labels:
|
||
component: kube-apiserver
|
||
spec:
|
||
containers:
|
||
- name: kube-apiserver
|
||
image: registry.k8s.io/kube-apiserver:v1.30.0
|
||
command:
|
||
- kube-apiserver
|
||
- --advertise-address=192.168.1.10
|
||
- --etcd-servers=https://127.0.0.1:2379
|
||
- --service-cluster-ip-range=10.96.0.0/12
|
||
ports:
|
||
- containerPort: 6443
|
||
hostNetwork: true
|
||
```
|
||
|
||
> [!info] 为什么控制平面用静态 Pod？
|
||
> 这是一个「鸡生蛋」的问题：kube-apiserver 是 Kubernetes 集群的核心，如果 kube-apiserver 本身也依赖 API Server 来创建，那集群就无法启动。静态 Pod 由 kubelet 独立管理，不依赖 API Server，因此可以用来部署 API Server 本身。
|
||
|
||
## 常见陷阱与最佳实践
|
||
|
||
### 镜像拉取策略（imagePullPolicy）
|
||
|
||
| 策略 | 行为 | 适用场景 |
|
||
|------|------|---------|
|
||
| `Always` | 每次创建 Pod 都拉取镜像 | 使用 `:latest` 标签时（默认策略） |
|
||
| `IfNotPresent` | 本地不存在时才拉取 | 使用固定版本标签（如 `:v1.2.3`） |
|
||
| `Never` | 从不拉取，仅使用本地镜像 | 离线环境或测试场景 |
|
||
|
||
```yaml
|
||
containers:
|
||
- name: app
|
||
image: myapp:v1.2.3 # 使用固定标签
|
||
imagePullPolicy: IfNotPresent # 推荐：避免不必要的拉取
|
||
```
|
||
|
||
> [!warning] :latest 标签陷阱
|
||
> 当镜像标签为 `:latest` 或不指定标签时，`imagePullPolicy` 默认为 `Always`。这意味着每次 Pod 重建都会重新拉取镜像，带来不确定性。**生产环境必须使用固定版本标签**（如 `:v1.2.3` 或 SHA256 digest）。
|
||
|
||
### 优雅终止（Graceful Shutdown）
|
||
|
||
当 Kubernetes 删除一个 Pod 时，会经历以下流程：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant User as 用户/API
|
||
participant API as API Server
|
||
participant Kubelet as kubelet
|
||
participant App as 应用进程
|
||
|
||
User->>API: 删除 Pod
|
||
API->>Kubelet: 标记 Pod 为 Terminating
|
||
Note over API: 从 Service Endpoints 移除
|
||
|
||
Kubelet->>App: 执行 preStop hook
|
||
App-->>App: 执行清理逻辑
|
||
App-->>Kubelet: preStop 完成
|
||
|
||
Kubelet->>App: 发送 SIGTERM 信号
|
||
App-->>App: 开始优雅关闭
|
||
|
||
alt 在 terminationGracePeriodSeconds 内退出
|
||
App-->>Kubelet: 进程正常退出
|
||
else 超时未退出
|
||
Kubelet->>App: 发送 SIGKILL 强制杀死
|
||
end
|
||
```
|
||
|
||
**关键配置项：**
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: graceful-demo
|
||
spec:
|
||
terminationGracePeriodSeconds: 60 # 默认 30s，给足够时间清理
|
||
containers:
|
||
- name: app
|
||
image: myapp:v1
|
||
lifecycle:
|
||
preStop:
|
||
exec:
|
||
command:
|
||
- /bin/sh
|
||
- -c
|
||
- |
|
||
# 1. 通知应用停止接收新请求
|
||
curl -s http://localhost:8080/admin/drain
|
||
# 2. 等待正在进行的请求处理完成
|
||
sleep 15
|
||
# 3. 关闭数据库连接池
|
||
echo "Shutting down gracefully..."
|
||
```
|
||
|
||
> [!tip] preStop 的妙用
|
||
> preStop hook 在 SIGTERM 之前执行，可以用来做「通知式关闭」——比如先从注册中心注销、停止接收新连接、等待进行中的请求完成。配合 `terminationGracePeriodSeconds` 调大值，可以实现零请求丢失的优雅关闭。
|
||
|
||
### PID 1 信号问题
|
||
|
||
在 Linux 中，PID 1 进程有特殊行为：**默认不响应 SIGTERM 信号**（为了兼容 init 系统）。如果容器的入口进程是 shell 脚本，shell 不会将 SIGTERM 转发给子进程，导致容器无法优雅退出。
|
||
|
||
**问题示例：**
|
||
|
||
```dockerfile
|
||
# 有问题的 Dockerfile
|
||
FROM node:20
|
||
COPY server.js .
|
||
CMD node server.js # node 进程成为 PID 1，但不一定正确处理信号
|
||
```
|
||
|
||
**解决方案：**
|
||
|
||
```dockerfile
|
||
# 方案 1：使用 exec 形式（推荐）
|
||
CMD ["node", "server.js"] # node 直接成为 PID 1
|
||
|
||
# 方案 2：使用 tini 作为 init 进程
|
||
RUN apt-get update && apt-get install -y tini
|
||
ENTRYPOINT ["tini", "--"]
|
||
CMD ["node", "server.js"]
|
||
|
||
# 方案 3：在 Pod Spec 中设置（Kubernetes 1.28+）
|
||
# 通过 feature gate: SidecarContainers
|
||
```
|
||
|
||
```yaml
|
||
# 方案 3：Pod 级别的 init 进程设置
|
||
apiVersion: v1
|
||
kind: Pod
|
||
metadata:
|
||
name: signal-demo
|
||
spec:
|
||
# Kubernetes 1.28+ 支持设置 Pod 的 PID namespace
|
||
# 确保 PID 1 被正确处理
|
||
containers:
|
||
- name: app
|
||
image: myapp:v1
|
||
```
|
||
|
||
### 其他注意事项
|
||
|
||
- **不要在同一 Pod 内运行多个不相关的服务** — 这违反了 Pod 的设计初衷，应该拆分为多个 Pod
|
||
- **使用 Liveness Probe 要谨慎** — 错误的 liveness 探针配置会导致容器反复重启（restart loop），建议先用 readiness 验证探针逻辑
|
||
- **设置资源 requests** — 不设 requests 的 Pod 会变成 BestEffort QoS，在节点压力下最先被驱逐
|
||
- **避免使用 hostNetwork** — 除非必要（如 CNI 插件、Ingress Controller），否则不要使用 hostNetwork，它会占用宿主机端口并绕过 Kubernetes 网络策略
|
||
|
||
## 延伸阅读
|
||
|
||
- [[k8s-02-architecture]] — Kubernetes 整体架构，理解 Pod 在集群中的位置
|
||
- [[k8s-04-deployment-and-replicaset]] — Deployment 如何管理 Pod 的副本与滚动更新
|
||
- [[k8s-scheduler]] — 调度器完整机制，包括亲和性、污点容忍、拓扑分布等
|