K8s -探针 - 技术栈

🧱 什么是Pod？

Pod 是 Kubernetes 中最小的可部署计算单元 ，你可以把它看作一组一个或多个关系紧密的：

容器：它们是 Pod 的主要执行单元。
存储卷（Volume）：Pod 中的容器可以共享的存储空间。
网络资源：Pod 拥有一个唯一的集群 IP 地址。
配置信息：定义了如何运行这些容器。

每个 Pod 都有一个独立的 IP, Pod 内的所有容器都通过 localhost 互相通信，并且都能访问 Pod 内挂载的共享存储卷。

Pod 主要包含以下类型的容器：

主业务容器：这是你应用的主要运行容器（例如 Nginx、Java 应用）。
Init 容器 ：在业务容器启动之前运行，用来完成一些前置准备工作，比如等待数据库就绪、初始化数据等。它必须成功执行完后，主容器才会启动。
临时容器 ：主要用于调试问题。它不会保证重启，主要用于在运行中的 Pod 内进行诊断。

最佳实践 ：Pod 是"逻辑主机"，内部容器协同工作。但 Kubernetes 推荐通过 Deployment、StatefulSet 等工作负载资源来管理 Pod，而不是直接创建。

⏳ Pod的生命周期

Pod 的生命周期是一个核心概念，主要围绕五种阶段（Pod Phase） 和三种探针（Probes）。

五种Pod阶段

Pending：Pod 已被 K8s 接受，但还在等待调度，或者正在 拉取镜像。
Running：Pod 已绑定到某个节点，所有容器已创建，且至少一个容器正在运行。
Succeeded：Pod 中所有容器都正常终止（例如一个一次性任务完成），并且不会重启。
Failed：Pod 中所有容器都已终止，但至少有一个容器是异常终止（失败）的。
Unknown：无法获取 Pod 的状态，通常是因为 Pod 所在节点与控制平面通信失败。

三种探针(Probe) 及三个字段

存活探针 (Liveness Probe) ：判断容器是否还活着 。如果探测失败，kubelet 会杀死该容器，并遵循 Pod 的重启策略（Restart Policy）。
- failureThreshold：连续探测多少次失败才认定为失败。例如，如果存活探针失败3次，kubelet 就会重启容器。
- periodSeconds：每隔多少秒探测一次，例如默认是10秒。
就绪探针 (Readiness Probe) ：判断容器是否准备好接收服务流量。如果探测失败，K8s 会将该 Pod 的 IP 从所有匹配的 Service 中移除，确保不会有流量打入。只有当它成功之后，才会恢复。
- initialDelaySeconds：容器启动后，延迟多少秒才开始探测。
启动探针 (Startup Probe) ：解决容器启动过慢的问题。如果配置了启动探针，在它成功之前，存活和就绪探针不会被激活，防止应用还没启动好就被杀掉。

探针可以通过三种方式执行： ExecAction （在容器内执行命令）、 TCPSocketAction （尝试 TCP 端口连接）或 HTTPGetAction（执行 HTTP GET 请求）。

重启策略 (Restart Policy)

Pod 的重启行为由 restartPolicy 控制，默认是 Always：

Always：无论容器以何种原因终止，都会自动重启。
OnFailure：仅当容器以非零状态码退出（即异常失败）时才重启。
Never：不管容器如何退出，都不重启。

📝 Pod配置清单(YAML)

Pod 的配置通过 YAML 文件声明，其顶层字段主要有四个：

apiVersion ：K8s API 的版本号，例如 v1。
kind ：资源类型，这里固定为 Pod。
metadata ：提供 Pod 的元数据，如 name、namespace、labels。
spec：Pod 的核心规约，详细定义了 Pod 内部容器的行为。

🌐 网络规则

Pod 的网络访问遵循以下关键规则：

Pod 内通信：Pod 内容器通过 localhost 互相访问。
跨 Pod 通信 ：不同 Pod 间通过各自的 Pod IP 直接通信。这通常由一个CNI（ Container Network Interface ）（如 Calico、Flannel、Cilium）插件在集群中实现。
对外通信：
- 出站流量：Pod 访问集群外，由 CNI 处理（通常经过节点网络接口）。
- 入站流量 ：集群外访问 Pod 内服务，需要通过 Service 对象（分配稳定虚拟 IP）或 Ingress 控制器（管理 HTTP/HTTPS 路由）。
网络策略 ：通过定义 NetworkPolicy 来精细控制 Pod 间的入口和出口流量。

💾 存储规则

Pod 中的存储主要分为以下三类：

临时存储 ：Pod 自身的本地存储（例如 emptyDir 卷），数据随 Pod 销毁而删除。
节点本地存储 ：使用 hostPath 卷将宿主机目录挂载到 Pod，但数据不随 Pod 迁移，节点故障会丢失。
持久化存储：
- PersistentVolume (PV)：集群级别的存储资源，独立于 Pod，由管理员预先配置。
- PersistentVolumeClaim (PVC)：用户对存储的"需求申请"，声明需要的容量和访问模式。
- Pod 在使用存储时，需要申请一个 PVC。K8s 会将 PVC 与符合条件的 PV 进行"绑定"，供 Pod 使用。这种方式将存储的管理和使用解耦，Pod 无需关心底层实现细节。

🔐 安全规则

Pod 的安全主要通过 Security Context 和 Pod Security Standards (PSS) 来保证。

Security Context：
- Pod 级别 ：设置的安全规则影响 Pod 内的所有容器。
- Container 级别 ：设置的安全规则仅作用于指定的容器。
- 可以控制的内容包括：
  - 用户和组 ：指定运行容器的用户 ID (runAsUser)、组 ID 和文件系统组。
  - 权限控制 ：是否以特权模式 运行 (privileged: true)，或者添加/移除 Linux Capabilities 来精细控制进程权限。
  - 只读根文件系统 ：设置 readOnlyRootFilesystem: true 强制容器根文件系统只读。
  - SELinux/AppArmor：配置强制访问控制。
Pod Security Standards (PSS)：
- Kubernetes 官方定义的三级安全策略，为 Pod 提供了一个安全基线。
- Privileged：开放的、无限制的策略，允许特权升级。
- Baseline：限制性较弱的策略，禁止已知的特权升级。
- Restricted：限制性非常强的策略，遵循当前保护 Pod 的最佳实践。

🧭 调度控制

K8s 调度器负责将 Pending 的 Pod 分配到最优节点，并根据 资源需求、节点资源、节点亲缘性、污点与容忍 做出决定。

Node Selector ：最简单的方法。通过 spec.nodeSelector 字段指定一组键值对，Pod 将只被调度到拥有这些标签的节点上。
亲和性与反亲和性：
- 节点亲和性 (Node Affinity) ：吸引 Pod 到特定节点。分为 硬亲和 （required，必须满足）和 软亲和（preferred，优先但不强制）。
- Pod 亲和性 (Pod Affinity) ：将一组 Pod 调度在一起，让它们位于同一个节点或拓扑域中，以降低通信延迟。
- Pod 反亲和性 (Pod Anti-Affinity) ：将一组 Pod 分散部署，避免它们共处一个节点或拓扑域，以提高故障隔离。
污点与容忍：
- 污点 (Taint) ：在节点上设置的"排斥"标签，默认阻止 Pod 调度到该节点。
- 容忍 (Toleration) ：在 Pod 上声明的"适应"标签，允许调度器将 Pod 分配到有匹配污点的节点上。

🔧 故障排查

当 Pod 出现问题时，可以遵循以下步骤，并结合 kubectl describe、kubectl logs 等命令进行诊断。

常见 Pod 故障排查思路与关键命令

Pod 卡在 Pending / ContainerCreating
- 症状：Pod 未被调度，资源不足，或镜像拉取失败。
- 排查与解决方案
  1. 查看事件 ：kubectl describe pod <pod-name>，检查 Events 部分，查找类似 "0/2 nodes are available" 或 "Failed to pull image" 的错误。
  2. 检查节点资源 ：kubectl top nodes 查看节点 CPU/内存是否充足。
  3. 检查镜像：确认镜像名称、地址、拉取凭证（imagePullSecrets）是否正确。
  4. 检查 PVC：确保 PVC 已成功绑定。
Pod 卡在 Waiting / CrashLoopBackOff
- 症状：容器启动后立即退出，反复重启。
- 排查与解决方案
  1. 查看日志 ：kubectl logs <pod-name>，直接看启动时打印的错误。
  2. 查看先前日志 ：kubectl logs -p <pod-name> 查看上一次容器退出前的日志。
  3. 检查事件 ：kubectl describe pod <pod-name> 查找 "Back-off restarting failed container" 等信息。
  4. 检查配置：确认启动命令（command/args）、环境变量、探针配置是否正确。
  5. 检查配置映射/密钥：确保 ConfigMap/Secret 存在且内容正确。
Pod 状态正常但服务异常
- 症状：Pod 处于 Running，但请求超时或返回 5xx 错误。
- 排查与解决方案
  1. 进入容器调试 ：kubectl exec -it <pod-name> -- /bin/bash。
  2. 测试内部连通 ：curl localhost:8080，确认 Pod 内服务本身能响应。
  3. 检查 Service ：kubectl describe svc <service-name>，检查 Endpoints 字段是否包含 Pod IP。
  4. 检查 NetworkPolicy：是否存在限制访问的网络策略。
Pod 突然 Terminating 或 Evicted
- 症状：Pod 无缘无故被删除或被驱逐。
- 排查与解决方案
  1. 查看 Pod 事件 ：kubectl describe pod <pod-name>，寻找 "Evicted" 原因。
  2. 检查节点压力 ：kubectl describe node <node-name>，查看 Node 状态是否为 "DiskPressure" 或 "MemoryPressure"。
  3. 检查 Pod Disruption Budget：确保删除操作允许。
  4. 检查优先级/抢占：是否存在更高优先级的 Pod 触发了抢占。

kubectl get events 命令能帮助你查看集群中发生的所有事件；kubectl delete pod <pod-name> 可以强制删除一个 Pod。

国内用户可通过 Kubernetes 中文指南查阅更详细的官方文档，但多数命令文档仍以英文为主，建议配合翻译工具使用。

🏗️ 最佳实践

设置资源限制 ：始终为 Pod 设置 requests 和 limits，确保调度合理并防止资源争抢。
配置健康探针：为服务配置合适的存活、就绪和启动探针，提高应用可用性。
使用临时容器调试 ：遇到问题时，使用 kubectl debug 创建临时容器进行调试，避免直接在业务容器内操作。
遵循安全准则 ：应用 Pod 安全标准，禁止特权容器，以非 root 用户运行应用。
利用命名空间隔离资源 ：使用 namespace 隔离不同环境或团队的 Pod，简化管理。
使用声明式管理 ：通过 YAML 文件定义 Pod，配合 kubectl apply -f 进行管理，而非直接运行 kubectl run。

📚 高级主题

当基础不再满足你时，可以探索以下高级主题：

Pod 优先级和抢占：设置 Pod 优先级，确保高优先级 Pod 在资源紧张时能抢占低优先级 Pod。
拓扑分布约束：精细控制 Pod 在不同节点、机架等拓扑域的分布，提高容灾能力。
临时容器调试 ：通过创建临时容器解决无法直接 exec 到业务容器的问题。
Pod 中断预算 ：为 Deployment 或 StatefulSet 设置 PodDisruptionBudget，保证在节点维护或升级时，仍有足够数量的 Pod 可用。
准入控制器 ：在 Pod 创建/更新时自动注入或校验配置（例如添加 sidecar 容器）。

⚡ 核心速查表

最小部署单元：Pod 是 Kubernetes 中的最小可部署计算单元。
Pod IP 详解 ：每个 Pod 都有一个唯一的 IP，Pod 内通信通过 localhost 进行，跨 Pod 通信需通过 Pod IP。
Volumes 关键点：Pod 内容器共享存储卷，持久化存储通过 PV 和 PVC 进行管理。
健康检查三大件 ：存活探针 （决定是否重启）、就绪探针 （决定是否接收流量）、启动探针（保护慢启动容器）。
调度控制四要素 ：节点亲和性 （吸引到特定节点）、Pod 亲和性/反亲和性 （集中/分散部署）、污点/容忍 （排斥/容忍节点）、资源请求（调度依据）。
故障排查三板斧 ：kubectl get 查看状态、kubectl describe 查看事件详情、kubectl logs 查看容器日志。