容器化

概述 把 120 多个微服务从传统虚拟机部署迁移到 Kubernetes，听起来是个标准项目：写 Dockerfile、建集群、迁移服务、切流量。规划会议上人人都觉得三个月够了。实际干起来你会发现，真正的难点不在"怎么把服务跑起来"——那只是 helm install 的事——而在于那些迁移过程中没人提前告诉你的坑：服务依赖的循环引用、有状态服务的内存态丢失、CNI 插件在大规模下的性能拐点、灰度切流时的 DNS 缓存陷阱、配置管理的环境变量膨胀、监控指标在迁移后的断层。 这篇文章是我主导某新能源物流平台 120+ 微服务 K8s 全量迁移的复盘。3 个月，零故障（这里的"零故障"指迁移过程未引发 P0/P1 级业务中断，不是零报错），扩缩容从 25 分钟降到 1 分钟，发布效率提升 50%。但过程远没有结果看起来那么顺利——光服务依赖梳理就花了三周，CNI 性能问题排查折腾了一周，灰度切流时 DNS 缓存导致的间歇性 502 让团队熬了两个通宵。 我写这篇文章的目的不是教你 K8s 基础概念，而是把迁移过程中真正卡住我们的 6 个坑拆开讲清楚，每个坑都附上架构决策过程和替代方案对比。如果你正在做或准备做大规模微服务 K8s 迁移，这些经验能帮你少走弯路。 坑一：服务依赖梳理——你以为的线性依赖其实是张循环图 问题：依赖检测做了一半就发现了死循环 迁移第一步是梳理服务依赖关系，确定迁移顺序。我们的标准做法很简单：找出没有下游依赖的服务先迁，然后逐层往上推。用 grep 扫了一遍配置文件里的数据库连接和 API 调用地址，画出了依赖拓扑图。 第一周很顺利。第二周开始出问题了——配置文件里写的依赖只是冰山一角。运行时的动态依赖、通过服务发现（Eureka/Nacos）路由的调用、消息队列触发的异步链路，这些都不在静态配置里。等我们把所有依赖补完，发现依赖图里有三个循环引用：A 调 B，B 调 C，C 又调 A。 这不算什么新鲜事。微服务架构演进两三年后，循环依赖几乎是必然产物。但迁移时它是个致命问题：你不能分批迁移了。A、B、C 必须同时迁，否则跨平台调用（K8s 内服务调 K8s 外服务）的网络延迟和 DNS 解析会成为性能瓶颈。 解法：运行时调用链分析 + 分批策略调整 光看配置文件不够。我们最终用了两套工具配合： 第一套：Jaeger 分布式链路追踪 在迁移前一个月，给所有服务接入了 OpenTelemetry SDK，通过 Jaeger 采集全量调用链路。跑了一周，拿到了真实运行时的服务调用关系图。静态配置里没出现的依赖关系，在链路数据里暴露无遗——光是消息队列触发的异步调用链就有 14 条，其中 3 条是循环依赖。...

为什么需要 Helm 裸用 kubectl apply -f 管理 K8s 应用，在规模小时够用，但随着环境增多（dev/staging/prod）和服务增长，问题立刻暴露： 配置硬编码：每个环境一份 YAML，镜像 tag、副本数、资源限制全写死，改一个值要改十个文件 无版本管理：升级回滚靠手动记录，不知道上次部署了什么版本 无法复用：部署 Redis 和部署 MySQL 写两套完全不同的 YAML，无法模板化 Helm 是 K8s 的包管理器，把一组 K8s 资源打包成 Chart，通过 values.yaml 参数化配置，实现一份模板、多环境部署、版本化升级和一键回滚。 本文参考 Helm 官方文档 Helm Chart 目录结构 my-web-app/ ├── Chart.yaml # Chart 元信息（名称、版本、描述） ├── values.yaml # 默认配置值 ├── values-prod.yaml # 生产环境覆盖配置 ├── charts/ # 依赖的子 Chart ├── templates/ # K8s 资源模板 │ ├── _helpers.tpl # 命名模板（可复用的模板片段） │ ├── deployment.yaml # Deployment │ ├── service....

GitOps 核心原则 GitOps 是一种现代化的持续交付方法论，由 Weaveworks 在 2017 年提出。它将 Git 作为基础设施和应用配置的唯一可信源（Single Source of Truth），通过声明式方式实现持续部署。 根据 ArgoCD 官方文档，GitOps 遵循四大核心原则： 1. 声明式系统 基础设施和应用配置以声明式描述（YAML/Helm/Kustomize）存储在 Git 中： # Git 仓库结构示例 infra-repo/ ├── apps/ │ ├── frontend/ │ │ ├── deployment.yaml │ │ ├── service.yaml │ │ └── configmap.yaml │ └── backend/ │ ├── deployment.yaml │ └── service.yaml ├── helm/ │ └── values-production.yaml └── kustomize/ ├── base/ └── overlays/ ├── staging/ └── production/ 声明式描述的核心价值：配置即文档，Git 历史即审计日志。任何环境变更都可追溯、可回滚。 2. 版本控制 所有变更通过 Git 提交记录，天然具备：...

概述 Kubernetes v1.24 正式移除了 dockershim，这意味着 Docker Engine 不再作为 K8s 的容器运行时。取而代之的是符合 CRI（Container Runtime Interface）规范的运行时，其中 containerd 是事实上的标准选择。 很多运维人员对 containerd 的认知停留在"Docker 的替代品"，但实际上 containerd 的架构、镜像管理、命令行工具都与 Docker 有显著差异。本文深入理解 CRI 规范、containerd 架构、日常运维和从 Docker 迁移的实践。 本文基于 containerd v2.0 和 Kubernetes v1.30。参考 containerd 官方文档 CRI 规范 什么是 CRI CRI（Container Runtime Interface）是 K8s 定义的容器运行时接口规范。K8s 不再直接调用容器运行时，而是通过 gRPC 调用符合 CRI 规范的运行时： kubelet → CRI gRPC → 容器运行时（containerd/CRI-O）→ 容器 CRI 接口定义 CRI 定义了两个核心服务： 服务 功能 关键方法 RuntimeService 容器和 Pod 生命周期 RunPodSandbox, CreateContainer, StartContainer, StopContainer ImageService 镜像管理 ListImages, PullImage, RemoveImage, ImageStatus // CRI 接口简化定义 service RuntimeService { rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse); rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse); rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse); rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse); rpc StartContainer(StartContainerRequest) returns (StartContainerResponse); rpc StopContainer(StopContainerRequest) returns (StopContainerResponse); rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse); rpc ListContainers(ListContainersRequest) returns (ListContainersResponse); rpc ContainerStats(ContainerStatsRequest) returns (ContainerStatsResponse); rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse); } service ImageService { rpc ListImages(ListImagesRequest) returns (ListImagesResponse); rpc PullImage(PullImageRequest) returns (PullImageResponse); rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse); rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse); } 为什么移除 dockershim Docker Engine 不原生支持 CRI，K8s 通过 dockershim 适配层调用 Docker。这带来几个问题：...

排查路径 kubectl get pods → 看状态 kubectl describe pod → 看 Events kubectl logs → 看日志 常见 Pod 状态 状态 含义 常见原因 Pending 未调度 资源不足、调度约束 CrashLoopBackOff 崩溃重启 应用异常、配置错误 ImagePullBackOff 镜像拉取失败 镜像不存在、认证失败 OOMKilled 内存溢出 内存限制过低 CrashLoopBackOff 排查 最常见故障，排查步骤： # 查看上次崩溃日志 kubectl logs <pod> --previous # 查看退出码 kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}' 退出码含义： 137：OOMKilled → 增加 resources.limits.memory 1：应用错误 → 查应用日志 126/127：命令不存在或权限问题 ImagePullBackOff 排查 kubectl describe pod <pod> | grep -A5 Events 常见原因：镜像名拼写错误、仓库需认证、网络不通。...

Kubernetes 网络模型四大要求 Kubernetes 网络模型的设计基于四个核心要求，理解它们是掌握 K8s 网络的基础。根据 Kubernetes 官方网络模型文档，这四个要求构成了集群网络通信的基石。 1. Pod 间通信（Pod-to-Pod） K8s 要求所有 Pod 之间可以直接通过 IP 通信，无需 NAT（网络地址转换）。这意味着： 每个 Pod 拥有独立的 IP 地址 Pod 之间通信使用真实 Pod IP，不经过 NAT 转换 无论 Pod 调度到哪个 Node，Pod 间网络始终扁平可达 这是 K8s 网络模型最核心的设计决策。传统数据中心网络中，跨主机容器通信通常依赖端口映射或 NAT，而 K8s 选择了扁平网络模型，让每个 Pod 成为网络中平等的一等公民。 2. Node 与 Pod 通信（Node-to-Pod） Node 上的进程（包括 kubelet、kube-proxy）必须能直接与该 Node 上任何 Pod 通信，同样不经过 NAT。这个要求保证了： kubelet 可以执行健康检查（liveness/readiness probe） 节点上的监控 agent 能直接采集 Pod 指标 主机网络进程与 Pod 网络互通 3. Service 网络 Service 提供了一个稳定的虚拟 IP（ClusterIP），将流量负载均衡到后端 Pod。Service 网络是独立于 Pod 网络的虚拟地址段（默认 10....

镜像过大的危害 很多团队在容器化初期不太关注镜像体积，一个 Spring Boot 应用镜像动辄 800MB-1.2GB，一个 Go 应用也常有 700MB+。镜像过大带来的问题远不止"占点磁盘"： 拉取慢，部署延迟高：在 CI/CD 流水线或弹性扩容场景下，节点需要先拉取镜像再启动容器。1GB 的镜像在百兆内网下载需要 80 秒以上，而 50MB 的镜像仅需 4 秒。对于 HPA 自动扩容场景，这意味着故障恢复窗口被拉长。 安全攻击面大：基础镜像里包含了大量你根本用不到的系统工具（curl、wget、gcc、bash 等）。攻击者一旦拿到容器 shell，这些工具就是横向移动的跳板。镜像越小，攻击面越窄。 存储成本累积：一个镜像 1GB，每天构建 5 次、保留 30 天就是 150GB。10 个微服务就是 1.5TB。 Harbor / Registry 的存储成本和备份成本随之飙升。 构建缓存效率低：大镜像的每一层都更大，构建缓存命中后的加载也更慢，拖慢整体 CI 流水线。 本文参考 Docker 官方多阶段构建文档 多阶段构建（Multi-stage Build） 为什么需要多阶段构建 传统 Dockerfile 的关键问题是：构建工具和运行时环境混在同一个镜像里。 以 Go 应用为例，编译需要 go 工具链和 gcc，但运行时只需要一个二进制文件。如果用 golang:1.22 做基础镜像，最终镜像里会带上整个 Go SDK（约 800MB+），而你的应用二进制可能只有 15MB。 多阶段构建允许在一个 Dockerfile 中定义多个 FROM，每个 FROM 开始一个新阶段，最终镜像只保留最后一个阶段的内容。 多阶段构建语法 # ===== 阶段1：构建阶段 ===== FROM golang:1....

K8s 存储体系：三层抽象 Kubernetes 存储体系通过三层抽象解耦了存储使用方与提供方，这是理解容器持久化存储的核心。根据 K8s 存储文档，三层结构如下： ┌──────────────────────────────────────────────────────┐ │ Pod (使用方) │ │ volumeMounts → volumes │ ├──────────────────────────────────────────────────────┤ │ PVC (声明) — 用户申请存储 │ │ "我需要 10Gi RWO 的存储" │ ├──────────────────────────────────────────────────────┤ │ StorageClass (动态供给) — 存储模板 │ │ "使用 ceph-rbd 驱动，reclaim: Retain" │ ├──────────────────────────────────────────────────────┤ │ PV (物理资源) — 实际存储 │ │ "10.0.0.5:/data/pvc-xxx (NFS)" │ └──────────────────────────────────────────────────────┘ PV（PersistentVolume） PV 是集群级资源，代表物理存储的抽象。PV 可以由管理员手动创建，也可通过 StorageClass 自动供给： apiVersion: v1 kind: PersistentVolume metadata: name: pv-nfs-data spec: capacity: storage: 50Gi accessModes: - ReadWriteMany # 多节点读写 persistentVolumeReclaimPolicy: Retain nfs: server: 10....

Requests 与 Limits 的语义 Kubernetes 中每个容器可以配置 CPU 和 Memory 的 requests 与 limits。很多开发者分不清二者的区别，导致 Pod 频繁被驱逐或 OOMKilled。 apiVersion: v1 kind: Pod metadata: name: api-server spec: containers: - name: app image: myapp:latest resources: requests: cpu: "250m" # 0.25 核 memory: "256Mi" limits: cpu: "500m" # 0.5 核 memory: "512Mi" 核心区别 维度 Requests Limits 作用阶段 调度时 运行时 含义 Pod 需要的最小资源保证 Pod 能使用的最大资源上限 调度器行为 调度器根据 requests 判断节点是否有足够资源 调度器不关心 limits 运行时行为 cgroups 中的保障份额 CPU 被节流（throttle），Memory 触发 OOMKilled 是否可超卖 可以（节点上所有 Pod 的 limits 之和可超过节点容量） 不建议超卖 Memory 简单理解：...