K8s 系列 | 第 3 天（重访）：Pod 进阶：设计模式、安全策略与高级调度约束

title: “K8s 系列 | 第 3 天（重访）：Pod 进阶：设计模式、安全策略与高级调度约束”
tags:
– Kubernetes
– K8s系列
– DevOps
– Pod
– 容器编排
– 云原生

第 3/30 天 | 本文是”30 天 K8s 系列”的第 3 天重访篇，从进阶视角深入剖析 Pod 的设计模式、安全策略与高级调度约束。

引言

在系列第 3 天的基础篇中，我们介绍了 Pod 作为 K8s 最小调度单元的核心概念与生命周期管理。然而，Pod 的潜力远不止于运行一个简单的容器。在生产环境中，Pod 是承载复杂架构设计的基石——Sidecar 模式、Init 容器、临时容器（Ephemeral Container）、Pod 安全标准（PSS）、Pod 干扰预算（PDB）以及拓扑分布约束（Topology Spread Constraints），这些才是让 Pod 真正发挥威力的进阶武器。

本文将脱离基础概念，聚焦于 Pod 在生产环境中的高阶设计模式与安全策略，帮助你从”会用 Pod”进阶到”精通 Pod”。

一、Pod 设计模式：不止于单容器

1.1 Sidecar 模式：日志采集与网络代理

Sidecar 是 K8s 中最经典的 Pod 设计模式——在主容器旁边运行一个辅助容器，为主容器提供增强功能而无需修改主容器代码。

典型场景：日志采集 Sidecar

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
  - name: app
    image: nginx:1.25
    volumeMounts:
    - name: logs
      mountPath: /var/log/nginx
  - name: log-collector
    image: fluent-bit:2.1
    volumeMounts:
    - name: logs
      mountPath: /var/log/nginx
    - name: config
      mountPath: /fluent-bit/etc/
  volumes:
  - name: logs
    emptyDir: {}
  - name: config
    configMap:
      name: fluent-bit-config

关键要点：
– 两个容器通过共享的 emptyDir 卷交换数据
– Sidecar 容器独立于主容器运行，互不干扰
– 重启策略独立：Sidecar 崩溃不会影响主容器

1.2 Init 容器：初始化前置任务

Init 容器在 Pod 中的应用容器启动之前运行，用于完成数据库迁移、权限检查、数据预热等一次性初始化任务。Init 容器必须全部成功完成后，主容器才会启动。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
  - name: db-migration
    image: migration-tool:1.0
    env:
    - name: DB_URL
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: url
    command: ["/bin/sh", "-c", "migrate --up"]
  - name: data-warmup
    image: busybox:1.36
    command: ["wget", "-O", "/dev/null", "http://cache-service/warmup"]
  containers:
  - name: app
    image: my-app:latest

Init 容器特性：
– 按顺序执行，前一个成功后才启动下一个
– 如果失败，Pod 会根据 restartPolicy 重试所有 Init 容器
– 可以拥有独立的资源请求、卷挂载和安全上下文
– Init 容器不支持 readinessProbe、livenessProbe 和 lifecycle 钩子

1.3 临时容器（Ephemeral Container）：生产环境排障利器

临时容器是 K8s v1.23+ 的 Alpha 特性，在 v1.25+ 正式 GA。它允许在运行中的 Pod 内动态注入调试容器，而无需重启 Pod——这对于生产环境问题排查至关重要。

# 在运行中的 Pod 中注入临时容器进行调试
kubectl debug -n production my-pod-7f8b9c --image=nicolaka/netshoot:latest --target=app

# 拷贝调试工具到临时容器中
kubectl debug -n production my-pod-7f8b9c -it 
  --image=ubuntu:22.04 
  --container=debug-shell 
  -- /bin/bash

临时容器的限制：
– 不支持端口映射（ports）
– 不支持资源请求/限制（resources）
– 不支持存活/就绪探针
– 一旦 Pod 重启，临时容器将被清除

二、Pod 安全策略：从 PSP 到 PSS 的演进

2.1 Pod 安全标准（PSS）

K8s v1.21 弃用了 PodSecurityPolicy（PSP），v1.25 完全移除，取而代之的是Pod 安全标准（Pod Security Standards, PSS）和Pod 安全准入（Pod Security Admission, PSA）。

PSS 定义了三个等级：

2.2 基于命名空间的 PSA 配置

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: baseline
---
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: nginx:1.25
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true
      runAsUser: 1000
      runAsGroup: 3000

关键安全配置解读：
– runAsNonRoot: true — 禁止以 root 用户运行
– seccompProfile: RuntimeDefault — 使用运行时默认的 seccomp 配置
– allowPrivilegeEscalation: false — 禁止提权
– capabilities.drop: ["ALL"] — 丢弃所有 Linux 能力
– readOnlyRootFilesystem: true — 只读根文件系统

2.3 Pod 安全上下文最佳实践

# 检查命名空间的 PSA 策略是否生效
kubectl label --dry-run=server --overwrite ns production 
  pod-security.kubernetes.io/enforce=restricted

三、Pod 的高级调度约束

3.1 拓扑分布约束（Topology Spread Constraints）

拓扑分布约束允许你控制 Pod 在集群内的分布方式，确保高可用性和资源利用均衡。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 9
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web
      - maxSkew: 2
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: web
      containers:
      - name: nginx
        image: nginx:1.25

配置解读：
– maxSkew: 1 — 任意两个节点上的 Pod 数量差不超过 1
– topologyKey: kubernetes.io/hostname — 按节点分布
– whenUnsatisfiable: DoNotSchedule — 无法满足约束时不调度（硬约束）
– 第二个约束按可用区（zone）分布，ScheduleAnyway 表示软约束，尽量满足

3.2 Pod 干扰预算（Pod Disruption Budget, PDB）

PDB 限制了在节点维护、集群升级等自愿干扰（Voluntary Disruption）期间，同一时间最多可中断的 Pod 数量。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: web

或者使用百分比：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb-percent
spec:
  maxUnavailable: 30%
  selector:
    matchLabels:
      app: web

PDB 实战要点：
– minAvailable: 3 — 集群升级时，至少保留 3 个 Pod 可用
– maxUnavailable: 30% — 最多允许 30% 的 Pod 同时不可用
– PDB 只影响自愿干扰（节点 drain、滚动更新），不影响非自愿干扰（节点宕机）
– 结合 topologySpreadConstraints 使用，可实现真正的多可用区高可用

四、常见问题与排障

4.1 Init 容器卡住排查

# 查看 Init 容器状态
kubectl get pod my-pod -o jsonpath='{.status.initContainerStatuses}'

# 查看 Init 容器日志
kubectl logs my-pod -c <init-container-name>

4.2 Pod 安全准入拒绝

# 查看 PSA 拒绝原因
kubectl describe pod my-pod

# 使用 dry-run 验证 Pod 是否符合安全策略
kubectl apply -f pod.yaml --dry-run=server

4.3 PDB 阻止节点维护

# 尝试 drain 节点，PDB 会阻止
kubectl drain node-1 --ignore-daemonsets

# 强制 drain（跳过 PDB 检查）
kubectl drain node-1 --ignore-daemonsets --disable-eviction=true

五、总结

本文从三个进阶维度重新审视了 Pod：

1. 设计模式：Sidecar 实现了功能解耦与增强，Init 容器确保了依赖前置就绪，临时容器提供了生产环境应急调试能力
2. 安全策略：PSS/PSA 取代了旧有的 PSP，三大安全等级（Privileged/Baseline/Restricted）配合精细化的 securityContext 配置，为 Pod 提供纵深防御
3. 高级调度：拓扑分布约束确保了跨节点/跨可用区的高可用分布，PDB 在集群维护时保障了应用服务的连续性

掌握这些进阶技能，意味着你不再只是”创建 Pod”，而是能在生产环境中设计、保护和优化 Pod 的运行——这是从初级运维走向高级架构师的必经之路。

下期预告

下一篇我们将深入 Deployment 与 ReplicaSet，从滚动更新策略、金丝雀发布、蓝绿部署到版本回滚机制，全面解析声明式应用管理的生产实践。

📚 系列目录
– K8s 系列 | 第 1 天：Kubernetes 是什么？核心概念与架构全景解析
– K8s 系列 | 第 2 天：手把手搭建你的第一个 K8s 集群（kubeadm 实战）
– K8s 系列 | 第 3 天（重访）：Pod 进阶：设计模式、安全策略与高级调度约束
– K8s 系列 | 第 4 天：Deployment 与 ReplicaSet：声明式应用管理
– … 更多内容请查看博客 K8s 系列标签