搜索结果: "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: 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 路由检查） |

| 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 — 最小调度单元

| 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 配合控制权限 | — |

### 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 都删掉

| 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`。

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/

- [[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

- [[k8s-top10-troubleshooting-checklist]] — K8s 高频问题一站式排查清单：10 大故障场景快速参考（Pod Pending/CrashLoopBackOff/Node NotReady/etcd/DNS 等）

- [[pod-troubleshooting]] — Pod 排障：CrashLoopBackOff / Exit Code / OOM / 探针 / 8 步排查法 / 依赖服务 / ConfigMap

- 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 相关

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

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

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

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

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

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

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

| 调度 | 自动迁移 / 驱逐 / 重建 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" | 侵权风险，用户搜品牌词奔着正品去 |

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

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

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

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

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

### Pod sysctl 调整

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