搜索: container

容器网络排障 6 层模型 — K8s/Docker/containerd 统一排查体系

标题匹配

title: 容器网络排障 6 层模型 — K8s/Docker/containerd 统一排查体系

tags: [kubernetes, networking, troubleshooting, docker, debugging, performance, container]

sources: [raw/articles/container-networking-troubleshooting-6-layer.md]

绝大多数容器网络不通并不是网络真的坏了，而是链路上某一层状态与预期不一致。本模型将容器网络拆成 **6 层**，每层只问一个问题，覆盖 K8s/Docker/containerd 三类环境。

无论 Docker 还是 containerd，本质都一样：容器在独立 netns 里，与宿主机通过 veth pair 连接，主机侧接网桥（docker0/cni0），再通过路由/NAT 出去。

Docker 生产环境踩坑指南 — 10 + 5 个常见问题

tags: [docker, container, troubleshooting, security, production, networking, debugging]

ls -lh /var/lib/docker/containers/*/*-json.log

docker inspect <container-id> | grep -E "OOMKilled|ExitCode|State"

docker stats <container-id> --no-stream

| [[container-networking-troubleshooting]] | 容器网络排障 6 层模型（Docker bridge 网络是第 ②~⑤ 层） |

ConfigMap 挂载踩坑指南 — 符号链接 / 只读 / 热更新 / 标准挂载模式

### 标准解决模式：initContainer + emptyDir

2. **initContainer** — 把 ConfigMap 内容复制到 emptyDir

initContainers:

containers:

> 链路：ConfigMap → initContainer（复制）→ emptyDir → 主容器

Jenkins 多 Master 架构部署方案 — K8S + Gateway API

tags: [kubernetes, deployment, architecture, build, networking, storage, monitoring, configmap, security, certificate, docker, container]

containers:

- containerPort: 8080

- containerPort: 50000

containers:

K8s 下 Java 内存调优完整指南 — 预算模型、生产配置与治理体系

Container Limit = Heap + Metaspace + Direct Memory + Thread Stack

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

-XX:+UseContainerSupport # 容器感知（JDK 10+ 默认开启）

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

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

K8s Pod Evicted 驱逐 — 根因排查与运维应对三板斧

tags: [kubernetes, troubleshooting, pod, deployment, production, monitoring, container, disk, storage]

journalctl -u containerd -f --since "10 minutes ago"

du -sh /var/lib/containerd/* 2>/dev/null | sort -hr | head -20

# /etc/containerd/config.toml

K8s 探针机制 — Liveness / Readiness / Startup 配置指南 + 百万级故障复盘

containers:

- containerPort: 8080

containers:

- containerPort: 80

containers:

K8s 资源限制配置指南 — Request / Limit / QoS / CPU Throttling

- type: Container

kubectl top pod -n --containers

CPU_REQ:.spec.containers[0].resources.requests.cpu,\

MEM_REQ:.spec.containers[0].resources.requests.memory

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi

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

PodA → ClusterIP:ServicePort → kube-proxy (iptables/ipvs) → EndpointIP:ContainerPort → PodB

外部客户端 → NodeIP:NodePort → kube-proxy → EndpointIP:ContainerPort → PodB

# - CreateContainerConfigError: 配置错误（ConfigMap/Secret）

kubectl logs -n -c <container-name>

wget -qO- http://127.0.0.1:<container-port>/healthz

K8s 故障排查快速参考 — 从现象到根因

3. **启动依赖优先怀疑**：启动即退出的高频根因是 Redis/MySQL/配置中心未就绪，启动脚本立即失败。止血用 initContainer 等待依赖（`until nc -z redis 6379; do sleep 2; done`）；长期治理用 `startupProbe` 给冷启动时间 + 应用自身重连退避，避免 K8s 把可恢复的短暂故障放大成持续重启

| 容器运行时故障 | `systemctl status containerd` | 看 containerd 日志 |

| 502 但 Pod/Service 均正常 | 端口定义不一致：Ingress 数字端口 vs Service 命名端口 | 统一命名端口：`name: http` + `containerPort: 8080` 全链路一致 |

| 接口延迟高但 CPU 没打满 | `container_cpu_cfs_throttled_periods_total` 持续增长 | 调大 limits.cpu 或去掉 limit |

journalctl -u containerd -n 100

> 定位：面向中高级开发者/架构师/技术负责人的生产排障手册。重点不是命令大全，而是**遇到故障时如何快速缩小范围、判断根因、做出正确修复**。全文案例取自真实事故：电商平台「速卖商城」（日活 2300 万、核心链路峰值 QPS 8.5 万、微服务 200+、3 个集群 260 节点、RocketMQ 日处理 14 亿条，K8s 1.27 + Containerd，Nginx + Spring Cloud Gateway + Nacos + Redis Cluster + MySQL 8.0 分库分表 + Prometheus/Grafana/EFK）。

`用户提交 YAML → API Server → etcd → Scheduler → Controller Manager → Kubelet → Container Runtime → CNI → CSI`

常见真实场景：**日志未轮转，`/var` 分区打满，触发 imagefs/nodefs 驱逐阈值**，节点先进入压力状态，再被控制面标记不可调度。修复顺序：先恢复节点基本可用性（清磁盘、恢复 containerd）→ 确认 kubelet 心跳恢复 → 最后处理被驱逐/重建的业务 Pod。防复发：日志轮转、镜像回收阈值前置、kubelet/containerd/磁盘使用率单独建告警。

详见 [[container-networking-troubleshooting]]、[[k8s-service-access-troubleshooting]]。

containerPort: 8080

Node 排障 — NotReady 九步排查 / Kubelet / 容器运行时 / 资源压力 / 证书 / 预防

3. 检查容器运行时（containerd/docker / crictl）

| 容器运行时连接失败 | `failed to load Kubelet config file` / `context deadline exceeded` | 检查 kubelet 的 `--container-runtime-endpoint` 和 containerd 配置是否一致 |

### containerd 排查

# 查看 containerd 服务状态

sudo systemctl status containerd

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

-o jsonpath='{.spec.containers[*].resources}'

-o jsonpath='{.spec.containers[*].livenessProbe}'

- **OOMKilled:** 增大 memory limits 或优化应用内存（Java 容器注意：`-Xmx` 设置 + 元空间/线程栈/直接内存等额外开销总和 < container limits）

# 或 (containerd)

# 查看 Pod Events 中的 CreateContainerConfigError

幽灵文件排查 — 删了 200GB 日志磁盘却不释放

tags: [linux, troubleshooting, disk, filesystem, storage, command, monitoring, case-study, production, container, debugging, logrotate]

容器场景应**从宿主机**确认容器 PID 和 overlay 挂载。命令因运行时而异，以 containerd/CRI 为例先用 `crictl` 定位，**不要直接进入未知 namespace 删除文件**。

container_id=$(sudo crictl ps --name myapp -q | head -n1)

sudo crictl inspect "$container_id" | jq '.info.pid, .status.metadata.name'

host_pid=$(sudo crictl inspect "$container_id" | jq -r '.info.pid')

Wiki Log

## [2026-05-21] ingest | 容器网络排障 6 层模型：K8s/Docker/containerd 统一排查体系

|- Created raw: raw/articles/container-networking-troubleshooting-6-layer.md（4890 字）

|- Created concept: concepts/kubernetes/container-networking-troubleshooting.md

|- 新增页面: container-networking-troubleshooting（5 条出链 ✓，全部合规）

容器运维核心命令参考手册：Docker + K8s 全场景速查

tags: [kubernetes, docker, container, troubleshooting, command]

### 4. 存储卷挂载异常（ContainerCreating）

kubectl get pod -n -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

- [[container-networking-troubleshooting]] — 容器网络排障

K8s 架构与核心概念深度解析 — 面试通关秘籍（一）

│ │ Kubelet │ │Kube-proxy│ │Container │ │

| **Container Runtime** | 容器运行时（containerd/CRI-O），实际运行容器 |

containers:

K8s 高频问题一站式排查清单 — 10 大故障场景快速参考

> 🔙 **回滚：** 如果是新版镜像导致的，快速 `kubectl set image deployment/ <container>=` 回退版本。

| `manifest unknown` | 镜像 tag 不存在 | `kubectl set image deployment/ <container>=` |

- [[container-networking-troubleshooting]] — 容器网络排障 6 层模型（快速识别网络故障层级）

Wiki Index

- [[configmap-mount-pitfalls]] — ConfigMap 挂载踩坑：符号链接只读/热更新/initContainer+emptyDir 标准模式

- [[container-networking-troubleshooting]] — 容器网络排障 6 层模型：K8s/Docker/containerd 统一排查体系（分层定位 + 30 秒速查 + 案例复盘）

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

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKilled 的排障指南

Docker 镜像优化完全指南：瘦身、构建加速与安全加固

tags: [docker, image, container, build, deployment, security]

--label "org.opencontainers.image.version=${VERSION}" \

--label "org.opencontainers.image.revision=$(git rev-parse HEAD)" \

K8s Java DirectMemory OOM 诊断 — 堆内存充足但 OOMKilled 的根因与复现

containers:

- containerPort: 8080

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存排障全指南（四大暗坑 + NMT 细节）

资源配额 / OOMKilled / RBAC / 调度排障

-o jsonpath='{.spec.containers[*].resources.limits.memory}'

- type: Container

- [[jvm-container-oom-offheap-troubleshooting]] — JVM 堆外内存（DirectByteBuffer/Metaspace/线程栈）导致容器 OOMKi

存储排障 — PVC Pending / 挂载失败

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

**⚠️ Pod 卡在 ContainerCreating 优先怀疑卷挂载链路：** 典型事件 `Warning FailedAttachVolume ... AttachVolume.Attach failed`，集中在 CSI driver 未注册/异常、云盘与节点不同可用区、StorageClass 绑定策略不合理。不要删 Pod 反复试，先确认三件事：PVC 是否已绑定（`kubectl get pvc`）、VolumeAttachment 状态是否正常（`kubectl get volumeattachment`）、目标节点与存储拓扑是否匹配。跨可用区集群用 `volumeBindingMode: WaitForFirstConsumer` 把卷绑定延后到调度之后，避免分配出 Pod 到不了的盘。

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

搜索结果: "container"