1. Pod基础概念解析

在Kubernetes生态中，Pod是最小的可部署计算单元，这个设计理念与传统的虚拟机或物理机部署有本质区别。一个Pod实际上是一组共享存储/网络资源的容器集合，它们总是被调度到同一个节点上运行。这里有个常见的误解：很多人以为Pod就是容器，其实Pod更像是一个"逻辑主机"，可以包含一个或多个紧密耦合的容器。

我刚开始接触k8s时，花了很长时间才理解为什么需要Pod这个抽象层。后来在实际部署微服务时才发现，有些服务确实需要多个容器协同工作。比如一个Web应用容器可能需要搭配日志收集sidecar容器，或者需要文件同步助手容器。这些容器需要共享网络命名空间（localhost互通）、共享存储卷（文件交换），这正是Pod的设计初衷。

2. Pod核心特性详解

2.1 共享网络空间

每个Pod会被分配唯一的IP地址，这个IP在其生命周期内保持不变（除非重建）。Pod内所有容器共享这个IP和端口空间，这意味着：

• 容器间可以通过localhost直接通信
• 端口不能冲突（比如两个容器不能同时监听8080）
• 外部访问需要通过Service抽象

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: web
    image: nginx
    ports:
    - containerPort: 80
  - name: log-agent
    image: fluentd

2.2 共享存储卷

Pod级别的Volume可以让多个容器访问相同的持久化数据：

spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: app
    image: my-app
    volumeMounts:
    - name: shared-data
      mountPath: /data
  - name: processor
    image: data-processor
    volumeMounts:
    - name: shared-data
      mountPath: /input

emptyDir是最基础的卷类型，生命周期与Pod一致。生产环境更常用的是PersistentVolumeClaim，这里有个坑要注意：多个容器同时写同一个文件需要处理好文件锁，否则可能导致数据损坏。

3. Pod生命周期管理

3.1 状态流转

Pod会经历以下几个主要状态：

• Pending：已创建但未调度
• Running：已绑定节点且至少一个容器运行中
• Succeeded：所有容器正常退出（批处理任务常见）
• Failed：至少一个容器非正常退出
• Unknown：无法获取状态（通常节点通信故障）

3.2 重启策略

通过 restartPolicy 字段控制：

• Always（默认）：容器退出就重启
• OnFailure：非0退出码时重启
• Never：不重启

注意：这里的重启是指容器级别的重启，不是Pod重建。Pod本身没有重启机制，需要配合Controller使用。

4. Pod资源配置

4.1 资源限制

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

requests影响调度决策（节点必须有足够资源），limits是硬限制（超过会被OOMKill）。内存限制特别重要，因为Linux内核对待内存超用比CPU更严格。

4.2 服务质量(QoS)等级

根据资源设置自动划分：

• Guaranteed：requests == limits（所有容器都设置）
• Burstable：至少一个容器设置requests
• BestEffort：完全未设置

当节点资源不足时，kubelet会按BestEffort → Burstable → Guaranteed顺序终止Pod。

5. Pod调度控制

5.1 节点选择器

spec:
  nodeSelector:
    disktype: ssd
    gpu: "true"

需要提前给节点打标签：

kubectl label nodes <node-name> disktype=ssd

5.2 亲和性/反亲和性

比nodeSelector更灵活的规则：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - zone-a

6. 健康检查机制

6.1 存活探针(Liveness)

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

失败后会重启容器。initialDelaySeconds很关键，要给应用足够的启动时间。

6.2 就绪探针(Readiness)

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  failureThreshold: 3
  periodSeconds: 10

失败后会将Pod从Service端点移除。对于慢启动应用，建议配置比liveness更宽松的阈值。

7. 调试技巧

查看Pod详细信息：

kubectl describe pod <pod-name>

查看容器日志：

kubectl logs <pod-name> -c <container-name> --tail=100 -f

进入容器调试：

kubectl exec -it <pod-name> -c <container-name> -- /bin/sh

8. 常见问题排查

8.1 ImagePullBackOff

• 检查镜像名称拼写
• 确认镜像仓库权限
• 尝试手动docker pull测试

8.2 CrashLoopBackOff

• 查看容器日志找崩溃原因
• 检查资源限制是否过小
• 确认应用启动参数是否正确

8.3 Pending状态

• 检查资源请求是否合理
• 查看事件信息： kubectl get events
• 确认节点选择器/亲和性规则是否太严格

9. 最佳实践建议

1. 单容器Pod是常见模式，除非有明确的共享需求
2. 一定要设置资源requests/limits
3. 为生产环境配置合适的探针
4. 使用ConfigMap/Secret管理配置，不要写死在镜像里
5. 通过Deployment等Controller管理Pod，避免直接创建裸Pod

Pod作为k8s的基础构建块，理解其设计理念和实现细节对集群稳定性至关重要。我在生产环境中见过太多因Pod配置不当导致的问题，合理的资源限制、完善的健康检查往往能避免大部分运行时故障。