搜索结果: "pod"

title: K8s 容量规划、Pod QoS 与成本优化实战指南

sources: [raw/articles/Kubernetes-容量规划-Pod-QoS-与成本优化实战指南.md]

# K8s 容量规划、Pod QoS 与成本优化实战指南

Kubernetes 容量规划不是简单给 Pod 写 requests/limits，而是回答四个问题：

| 故障时谁被牺牲 | QoS、PriorityClass、PDB | 所有 Pod 同优先级 | 核心链路 Guaranteed + 高优先级 |

title: K8s Hairpin 发夹回流故障—Pod 无法访问自身 Service 深度解析

sources: [raw/articles/Kubernetes-隐蔽网络故障-Pod-可通全网-无法访问自身-Service-问题深度解析.md]

# K8s Hairpin 发夹回流故障—Pod 无法访问自身 Service 深度解析

Kubernetes 中一个极度隐蔽的网络问题——**Pod 内部能通 localhost 和自身 PodIP，但访问自身 ServiceIP 却百分百超时**。所有上层组件（kube-proxy、CoreDNS、Endpoint）全部正常。

同一 Pod 内部，三组访问结果完全割裂：

title: Pod Pending 排障指南 — 7 个角度快速定位调度失败根因

tags: [kubernetes, troubleshooting, pod, scheduling, networking, storage, deployment]

sources: [raw/articles/Pod-一直-Pending-无法启动-7-个角度快速定位问题.md]

# Pod Pending 排障指南

> Pod 卡在 Pending 意味着 Scheduler 找不到合适的节点分配，或 Kubelet 在创建容器阶段卡住。核心排查工具：**`kubectl describe pod` 的 Events 段**直接告诉你原因。

title: K8s Pod 调度策略完全指南 — 六大机制全解析

# K8s Pod 调度策略完全指南

Kubernetes 调度器（kube-scheduler）通过预选（Filtering）和优选（Scoring）决定 Pod 落在哪个节点。

5. podAffinity / podAntiAffinity（Pod 间亲和/反亲和）

通过标签键值对匹配节点，**硬约束**，无匹配节点则 Pod 永久 Pending。

title: K8s 服务访问排查 — 从 Pod、Service 到 Ingress 十步工作流

tags: [kubernetes, troubleshooting, service, pod, ingress, networking, cni, dns]

# K8s 服务访问排查 — 从 Pod、Service 到 Ingress 十步工作流

> 排查核心：**分层定位，逐层排除，始终从 Pod 层开始，往上排查。**

> 记住口诀：**先 Pod 再 Svc，EP 不为空则网络通；Ingress 有问题先看日志，DNS 不通查 CoreDNS。**

title: Pod 排障 — CrashLoopBackOff / Exit Code 排查 / OOM / 探针 / 依赖服务 / ConfigMap

tags: [kubernetes, troubleshooting, pod, deployment, production, networking, configmap]

- raw/articles/pod-restart-troubleshooting-guide.md

# Pod 排障

Pod 是 Kubernetes 最基础的调度单元，Pod 启动失败是最常见的问题类型。

- 每个节点分配一个 /24 子网，Pod IP 从该子网分配

- **VXLAN 模式**（默认）：Pod 跨节点流量 → flannel.1 隧道设备 → 封装 VXLAN（UDP 8472）→ 对端解封装

- **BGP 路由分发**：每个节点运行 BGP 客户端（Bird），将 Pod CIDR 路由广播给其他节点或物理网络路由器

- **与物理网络集成**：可配置为将 Pod 路由直接通告到物理路由器，实现 Pod IP 对外直接可达

- [[service-troubleshooting]] — CNI 排查实战（Flannel 接口/Calico Pod 状态/BGP 路由检查）

## Kubernetes Pod 操作速查

| 列出 Pod | `kubectl get pods -n ` |

| Pod 详情（含事件） | `kubectl describe pod -n ` |

| 查看 YAML | `kubectl get pod -n -o yaml` |

| 进入 Pod | `kubectl exec -it -n -- /bin/bash` |

| 51 | Pod hostPath 权限问题？ | 宿主机权限 700 vs 非 root Pod → Permission denied；用 securityContext.runAsUser + fsGroup 解决 | [[pod-troubleshooting]] |

| 32 | StatefulSet 和 DaemonSet？ | StatefulSet：有状态应用（稳定网络标识+持久存储）；DaemonSet：每个节点一个 Pod | [[k8s-statefulset-guide]] |

| 34 | K8s 网络模型和 CNI？ | 扁平网络：Pod 唯一 IP，Pod/节点间直接通信。常见：Calico(BGP)/Flannel(VXLAN)/Cilium(eBPF) | [[cni-comparison]] |

| 47 | CNI + netns/veth/bridge 联动？ | Pod 独立 netns → veth pair 跨命名空间 → 网桥节点内通信 → 路由表跨节点转发。Calico BGP 优于 Flannel VXLAN | [[cni-comparison]] |

| 49 | namespace 在 Pod 中的作用？ | net(共享网络栈) + pid(独立进程空间) + mnt(独立挂载点) + user(独立用户ID)。Pod 内共享 net/ipc/uts，隔离 mnt/user/pid | — |

tags: [kubernetes, troubleshooting, configmap, pod, storage, debugging]

当 ConfigMap 挂载到 Pod 的目录后，实际的文件系统结构如下：

3. 整个过程原子完成，无需重启 Pod

ConfigMap 也支持 subPath 方式挂载单个文件，但会导致**不能热更新**（Pod 必须重启才能看到新配置），且无法用于多文件目录：

subPath 挂载后的文件是**普通文件**（不是符号链接），可以写入，但写操作不会更新 ConfigMap，不会影响其他 Pod。

| ⑥ 集群与策略层（K8s） | CNI/kube-proxy/NetworkPolicy/Service/Endpoint 一致？ | `kubectl get pod,svc,ep -A`, `kubectl get netpol -A` |

1. **K8s Pod 状态** — `kubectl get pod -A -o wide` → 看 STATUS / IP / NODE 字段

**K8s + CNI 常见断点：** Pod IP 分配失败、Service → Endpoint 映射不一致、NetworkPolicy 默认拒绝

| Pod 间不通（同节点通，跨节点不通） | 检查路由发布和隧道设备 | 路由发布异常 / 隧道设备异常 / 内核参数重置 |

| Pod 能出公网但回不来 | `sysctl rp_filter` 检查 | rp_filter 严格模式（=1）丢弃回包 |

- **构建全在 Agent Pod 中执行**，按需创建/销毁

Agent Pods (Kubernetes Plugin)

> Headless Service 让 Jenkins Agent 通过 Pod DNS 名称（`jenkins-master-0.jenkins-master-svc.jenkins-team-a.svc.cluster.local`）直连 Master 的 50000 端口，避免经过 kube-proxy 造成不必要的网络跳转。

podRetention: "Never"

# 在 Jenkins Master Pod 内执行

tags: [kubernetes, architecture, deployment, pod, service, statefulset, networking, storage]

│ │ Pods (业务容器) │ │

| **Scheduler** | Pod 调度决策 | 过滤（Filtering）+ 打分（Scoring）两阶段 |

| **Kubelet** | 节点代理，Watch API Server 中分配给本节点的 Pod，调用容器运行时创建容器 |

### Pod — 最小调度单元

> **一句话复盘：** Pod 访问外部域名偶发 `dial tcp: lookup api.example.com: i/o timeout`，超时稳定卡在 5s（glibc resolver 默认 timeout）。根因并非 CoreDNS 繁忙，而是 **DNS UDP 请求经过 kube-proxy iptables 转发时，conntrack 发生竞态丢包，加上 ndots:5 放大了请求量**。组合方案：NodeLocal DNSCache + ndots 调优。

DNS 超时的 5 秒不是玄学 — glibc resolver 默认 timeout 就是 5 秒。Pod 内压测验证：

kubectl -n kube-system top pod -l k8s-app=kube-dns

kubectl -n kube-system describe pod coredns-xxx

找到异常 Pod 所在节点，抓 DNS 流量：

| 4 | 什么是 Pod？ | K8s 最小部署单元，包含一个或多个容器，共享网络和存储 | [[pod-troubleshooting]] |

| 11 | StatefulSet vs Deployment？ | StatefulSet 管理有状态应用，Pod 有固定身份；Deployment 管理无状态应用 | [[k8s-statefulset-guide]] |

| 12 | 什么是 DaemonSet？ | 确保每个节点运行一个 Pod 副本（日志收集、监控代理） | — |

| 15 | K8s 网络模型？ | 扁平网络，所有 Pod 可直接通信无需 NAT | [[cni-comparison]] |

| 18 | 什么是 ServiceAccount？ | 为 Pod 提供访问 API 的身份，与 RBAC 配合控制权限 | — |

集群里 Service 数量一多，Pod 访问其他 Service 的延迟开始飘，P99 响应时间从 75ms 飙到 550ms，超时失败率冲到 18%。节点 CPU、内存、数据库连接池一切正常——问题可能出在 kube-proxy 的转发模式上。

# 方法1：看 kube-proxy Pod 启动日志

### 坑 1：短连接 + 滚动更新 → 请求发到已不存在的 Pod

内核 `net.ipv4.vs.conn_reuse_mode` 参数相关。当客户端在两分钟内发大量五元组相同的短连接请求，IPVS 会复用之前连接的信息，将新请求转发到已被销毁的 Pod。

- **内核 < 5.9**：conn_reuse_mode 被默认置为 0 规避 SYN 丢包，但又引入请求到旧 Pod 的问题——旧内核上两种模式"两难"

> GC 平稳、堆内存只用了一半、Pod 却突然 OOMKilled（退出码 137）？问题不在堆，而是被长期忽略的**堆外内存（DirectMemory）**悄悄拖垮。本文从错误认知、根因、故障复现代码到生产配置，完整拆解这类隐性 OOM。

K8s `limits.memory` 会把以上所有内存累加计算。一旦总和超出限额，系统直接 `kill -9`，Pod 显示 OOMKilled。

**场景举例：** 容器限制 3Gi，`-Xmx2.5G`。JDK8 默认 `MaxDirectMemorySize ≈ -Xmx` 即 2.5G，叠加元空间、线程栈等，总内存轻松达 5.5G，远超容器限制。堆内存只用了 40% 时 Pod 仍被杀死。

| `java.lang.OutOfMemoryError: Java heap space` | JVM | 应用抛出 OOM 异常，Pod 不会被强杀 |

**关键区别：** JVM 层面 OOM 有日志可查；Kubernetes OOMKilled 是操作系统发现内存超限直接强杀。这正是最迷惑的现象：GC 正常、堆正常、日志无报错，Pod 却莫名挂掉。

### 4Gi Pod 预算示例

| Container Limit | 4096Mi | Pod resources.limits.memory |

| Container OOMKill | Pod 状态 OOMKilled | RSS 超 cgroup 上限 |

kubectl describe pod <pod-name>

kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'

很多团队对 Kubernetes 负载均衡的理解停留在"创建一个 Service，流量就会自动打到后端 Pod"。但这个认知掩盖了生产环境中最关键的问题：

- 为什么 Pod 明明是 Ready 的，用户仍然会出现 502、超时、长尾延迟飙升？

客户端 -> DNS -> 外部负载均衡 -> Ingress/Gateway API -> NodePort/ClusterIP -> kube-proxy -> Endpoints -> Pod

| **iptables** | 随机选择后端 Pod | 成熟稳定，Linux 内核原生 | 规则量大时性能下降，更新需 iptables-save 全量刷新 | 小集群（<100 个 Service） |

Service Mesh（如 Istio、Linkerd）在 Pod 级别注入 sidecar 代理，接管 Pod 的入站和出站流量。这会改变负载均衡链路：

tags: [kubernetes, pod, troubleshooting, production, monitoring]

| 1 | **存活探针依赖外部服务** | 下游抖动导致 Pod 被重启，级联故障 | 存活探针只检查自身进程/本地状态 |

| 6 | **不监控探针状态** | 探针异常无法察觉 | Prometheus 监控 `kube_pod_container_status_restarts_total` |

外部请求失败 → 探针判定超时 → Pod 被重启

新 Pod 同样未完成启动即被判定存活 → 再次重启

**故障链：** 周五下午监控突然告警 API Server 超时、节点 Unknown、Pod 无法调度 → 登录发现 etcd 磁盘 100% → etcd 无法写入 Raft 日志 → 整个集群只读。

**故障链：** 集群突然不可用 → `kubectl` 全部 timeout → 发现 API Server Pod 被 OOMKilled 循环重启。

**根因：** 某应用频繁 LIST 全量 Pod（每 10 秒），导致 API Server 内存中对象缓存暴涨。

grep "list pods" /var/log/kubernetes/audit.log | awk '{print $NF}' | sort | uniq -c | sort -rn

**故障链：** 凌晨 3 点，5 个节点同时变为 NotReady → 大量 Pod 被驱逐。

tags: [kubernetes, troubleshooting, pod, deployment, production, debugging]

> K8s 资源限制（Resource Limits）是 Pod 调度的核心依据，也是保障集群稳定性的关键配置。

- 调度器检查：Node 已分配 Request 总量 + 新 Pod 的 Request ≤ Node 实际容量

当 Request < Limit 时，Pod 处于 **Burstable** QoS。此时 OOM Killer 会综合考虑

> 实际使用内存很少、但 Request 设置得很高的 Pod，反而更容易被 OOMKill。

> RollingUpdate 解决的是"Pod 替换问题"，从来不是"业务无感知问题"。

> K8s 只保证"容器层可用"——Pod 启动、健康探针返回正常，它就认为没问题。

1. 创建一部分新 Pod（`maxSurge` 控制最多多创建多少）

2. 删除一部分旧 Pod（`maxUnavailable` 控制最多能宕机多少）

- 不会一次性把所有 Pod 都删掉

**经典场景：** 某时刻 Node-A 缓存显示剩余 8 核 CPU。集群同时涌入 Pod1、Pod2、Pod3 三个待调度 Pod。三个 Pod 并发调度，读取同一份过期缓存数据，全部判定 Node-A 最空闲。调度器一次性把三个 Pod 全部分配到 Node-A。等到 kubelet 真正拉取镜像启动容器时，资源瞬间耗尽，节点 OOM。

**粗算：** 5000 节点、20 万 Pod 的集群，如果追求真正全局最优——核算实时资源余量 + 亲和反亲和 + 拓扑约束 + NUMA/GPU/网络 + 未来负载趋势——单次调度可能耗时数十秒，导致大量 Pod Pending，集群瘫痪。

- HPA 自动扩容新增大量 Pod

## 高频坑点：Pod 总调度到最忙节点的三大原因

| **Requests 配置失真** | 调度器只认 requests 不认 usage。很多 Pod requests 写得极小（100m CPU），实际运行占 4 核 → 调度器以为很轻，疯狂往节点堆 |

| Pod 名称 | 随机哈希（`nginx-abc123`） | 有序编号（`web-0, web-1, web-2`） |

| Pod 重建名称 | 新随机名 | **不变** |

| 存储 | 共享 PVC 或无 | 每个 Pod **独立 PVC**（volumeClaimTemplates） |

| 网络标识 | 通过 Service 负载均衡访问 | 每个 Pod 有固定 DNS 名称 |

Pod 命名格式：`{statefulset-name}-{ordinal-index}`，如 `mysql-0`、`mysql-1`。

# Pod 使用

kind: Pod

name: test-pod

volumeBindingMode: WaitForFirstConsumer # 重要：按 Pod 调度可用区创建 PV

> **WaitForFirstConsumer：** PV 创建和绑定延迟到真正有 Pod 使用该 PVC 时才执行。确保 PV 在与 Pod 相同的可用区创建，避免跨区挂载失败。EBS 等 zone 级存储必须设此模式。

tags: [kubernetes, troubleshooting, production, debugging, pod, node, service, storage, networking, security]

## 问题一：Pod Pending

**诊断入口：** `kubectl describe pod` → Events 段看最后几行

| **资源不足** | `kubectl top nodes` → 检查 Allocatable | 扩容节点 / 降低资源请求 / 清理低优 Pod |

> ⚠️ **风险提醒：** 修改污点会影响其他 Pod 调度——确认节点属专用节点前别乱删污点。

先看 **Node 状态**，再看 **Pod 状态**，最后看 **应用日志**。跳过底层基础设施直接看 Pod 内部容易误判。

`kubectl get pod` 的 STATUS 列已能给出初步方向。CrashLoopBackOff 和 ImagePullBackOff 的处理路径完全不同。

重启 Pod 会丢失现场，日志和事件信息会部分丢失。必须重启前先保存关键信息。

| 1 | `kubectl get pods -n ` | 确认 STATUS（CrashLoopBackOff / ImagePullBackOff / Pending / Terminating） |

| 2 | `kubectl describe pod -n ` | 查看 Events 和 Conditions，判断方向 |

> Node 是 Pod 运行的基础底层，Node 不可用会直接影响其上所有 Pod。

- 节点处于 Unknown 超过 5 分钟（`pod-eviction-timeout`）后，触发 Pod 驱逐

重启 kubelet 会导致该节点上的 Pod 被驱逐和重新调度。生产环境执行前必须确认副本数足够。

kubectl get pods -o wide --all-namespaces | grep

**Pod 驱逐顺序：** BestEffort → Burstable → Guaranteed。

**现象:** Pod 退出码 137（SIGKILL），Reason 为 OOMKilled。

kubectl describe pod -n | grep -E "Last State|Reason|Exit Code"

kubectl get pod -n \

当内存 Request < Limit 时，Pod 处于 Burstable QoS。OOM Killer 用 **Request 值**（而非 Limit 值）

- **Pod A** (Burstable)：requests: 2Gi, limits: 4Gi，实际只用 512Mi

- **Selector 标签与 Pod 标签不匹配**

- 后端 Pod 不处于 Running

- Pod 与 Service 不在同一 Namespace

kubectl get pods -n --show-labels | grep

kubectl get pods -n -l "="

**现象:** PVC 处于 Pending 状态，Pod 无法启动。

kubectl get pods -n kube-system | grep -E "csi|storage"

- **WaitForFirstConsumer:** 需要调度 Pod 触发绑定

**现象:** Pod 处于 ContainerCreating，describe 显示卷挂载失败。

kubectl logs -n kube-system pod-name> --tail=100

- **治标：** 重启业务或 kill 异常 D 状态进程（K8s 重启 Pod）

**K8s Pod 的 cgroup 路径：**

/sys/fs/cgroup/kubepods.slice/kubepods-pod.slice/

/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod.slice/

/sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod.slice/

- [[container-ops-command-reference]] — 容器运维核心命令速查手册：Docker 容器/镜像/存储卷/网络管理命令、K8s Pod/调度/排障命令、五大高频故障排障流程、Probe 配置、QoS、回滚操作

- [[k8s-hairpin-troubleshooting]] — K8s Hairpin 发夹回流故障—Pod 可通全网但无法访问自身 Service 的原因、排查与修复

- [[k8s-pod-pending-troubleshooting-guide]] — Pod Pending 排障指南 — 7 个排查方向（资源不足/污点/亲和性/存储/配额/选择器/端口冲突），含 Events 关键字匹配

- [[k8s-scheduling-strategy-guide]] — K8s Pod 调度策略完全指南：nodeSelector/Affinity/Taint/Topology/PriorityClass 六大机制

- [[k8s-service-access-troubleshooting]] — K8s 服务访问排查十步工作流：Pod→Service→kube-proxy→CNI→Ingress→DNS→NetworkPolicy

- Created concepts: k8s-troubleshooting-principles, pod-troubleshooting, node-troubleshooting, service-troubleshooting, storage-troubleshooting, resource-rbac-scheduling-troubleshooting

## [2026-05-08] ingest | Pod 明明 Running 却挂了？K8s 探针一篇讲透

## [2026-05-11] ingest | K8s 服务访问不通？从 Pod 到 Ingress

- Updated: service-troubleshooting, pod-troubleshooting, k8s-troubleshooting-principles

- Updated: pod-troubleshooting

- File names: lowercase, hyphens, no spaces (e.g., `pod-troubleshooting.md`)

├── kubernetes/ # K8s 集群、Pod、Service、存储、调度

- scheduling: Pod 调度策略与机制

- pod: Pod 相关

# CoreDNS Pod 全部 CrashLoopBackOff

kubectl get pods -n kube-system | grep coredns

# 等待两个 Pod 变为 Running

3. **CoreDNS 健康检查告警** — 监控 CoreDNS Pod 状态 + API 健康端点

> ⚠️ 坑：用了不支持 RWX 的存储系统，Pod 会一直 Pending。详见 [[storage-troubleshooting]]。

### 案例 2：多 Pod 共享存储（NFS）

| Pod 挂载失败 | 节点是否支持该存储类型 / 权限 / 存储系统状态 |

| [[node-troubleshooting]] | Node 排障与 k8s-statefulset-guide 的 Pod 行为交叉 |

| **东西流量** | 村里人互相串门 | 数据中心内部、微服务之间、Pod 之间的通信 | 前端正常但下单超时，多半是内部服务节点卡住了 |

**混沌工程：** 在生产环境故意注入故障（随机杀 Pod、掐网线），验证高可用架构。Netflix 的"混乱猴子"是鼻祖。

**Sidecar：** Pod 内配辅助容器，负责日志收集、流量代理、监控上报——不改业务代码。

> ❌ 不要在 Pod 里手工改 hosts — 短期快长期是雷。

- ⚠️ rewrite 只改查询名，**不保证网络可达** — Service 端口、NetworkPolicy、后端 Pod 健康需单独确认

- 上游 DNS 有 ACL 限制时，提前确认 CoreDNS Pod 网段被放行

| [[container-ops-command-reference]] | 容器运维核心命令速查手册：Docker 容器/镜像/存储卷/网络管理命令、K8s Pod/调度/排障 |

| [[pod-troubleshooting]] | Pod CrashLoopBackOff 排障（含 Java OOM/Exit Code 分析） |

kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'

kubectl exec pod_name -- ip addr

| 调度 | 自动迁移 / 驱逐 / 重建 Pod | 固定节点拓扑 | Pod 漂移 → 主从异常 / 脑裂 |

**调度层风险最隐蔽：** K8s 自动调度、Pod 驱逐对无状态应用友好，但数据库的主从复制、集群分片依赖固定节点，频繁漂移摧毁高可用。

kubectl top pod -A --containers | head -30

sum by(pod, namespace) (rate(container_cpu_cfs_throttled_periods_total[5m])) > 20

| ❌ 品牌词 | "apple airpods case" | 侵权风险，用户搜品牌词奔着正品去 |

某微服务 3 月 15 日发生 OOM Kill，Pod 重启 12 次，业务中断 25 分钟。复盘结论是"内存配置不合理"，改进项"将内存限制从 2Gi 调整到 4Gi"，责任人研发组长，截止日期 3 月 22 日。

| K8s 内 Pod 间不通 | K8s Service / NetworkPolicy 排查 | [[service-troubleshooting]] |

kubectl describe pod <pod> | grep -E "State|Exit|OOM"

| Jenkins / GitLab CI | CI 构建与镜像打包 | 独立 Pod 部署 |

kubectl get pods -o wide | grep -v Running

→ 检查内网 DNS 服务状态 → 检查 CoreDNS Pod → 检查 Service 的 Endpoints

- [[container-ops-command-reference]] — 容器运维核心命令速查手册：Docker 容器/镜像/存储卷/网络管理命令、K8s Pod/调度/排障

### Pod sysctl 调整

- **Pod 反亲和** — 保证 WebSocket 节点分散，降低故障影响面