容器与 K8s 核心知识从 Docker 镜像分层到 Pod 调度问题场景本地跑得好好的上测试环境就报错——“我这儿能跑啊”。手动扩容 5 个实例半夜一台挂了没人知道服务少了 20% 容量。Docker 解决环境一致K8s 解决自动运维——两个工具合起来就是后端部署的完整答案。30秒速览Docker 镜像分层——每行指令一个只读层写时复制。镜像瘦身真实对比——多阶段构建alpineJava 镜像 1.2GB→200MB差 6 倍。K8s 核心对象——Pod最小调度共享网络→ Deployment副本数滚动更新→ Service固定 Cluster IP。生产排错必知——OOMKilled (exit code 137)不是代码的锅是 memory limits 设太小。滚动更新翻车——新 Pod 一直起不来、旧 Pod 已被干掉→maxUnavailable 设 1 保底。系列第 14 篇共 172 篇。。一、Docker 基础容器不是轻量级虚拟机1.1 容器 vs 虚拟机维度容器虚拟机隔离级别进程级共享宿主机内核OS 级Hypervisor 虚拟硬件启动速度秒级分钟级资源占用MB 级GB 级单机密度几十上百个几个容器的本质是进程隔离 资源限制——Linux 的 namespace看不见别人和 cgroup不能占别人资源组合而成。它不是轻量级虚拟机因为没有自己的内核。1.2 镜像分层——为什么 Docker 镜像能共享镜像由多个只读层叠加每层是上一层的增量。Dockerfile 每条指令产生一层FROM openjdk:17-slim ← 基础层200MB RUN apt-get update ← 系统层 COPY target/app.jar ← 应用层你的代码 ↑ 这三层叠加形成最终镜像分层的核心收益共享复用10 个 Java 应用共享同一个openjdk:17-slim基础层磁盘只存一份构建缓存Dockerfile 中未变的层直接复用缓存只重建变化的层——COPY app.jar之前的层全部 hit cache增量传输镜像仓库 push/pull 只传缺失的层1.3 Dockerfile 关键指令速查指令作用注意FROM基础镜像优先 alpine/slim 小体积COPY vs ADD复制文件COPY 只复制ADD 多了自动解压 tar少用RUN构建时执行多条合并用 \减少层数CMD vs ENTRYPOINT容器启动命令ENTRYPOINT主程序CMD默认参数1.4 Docker 实操要点# 常用管理命令dockerps# 运行中的容器dockerlogs容器ID# 查看日志dockerexec-it容器IDbash# 进入容器终端dockerstop/start容器ID# 停止/启动Docker Compose本地开发一键启动依赖version:3.8services:web:image:nginx:latestports:[80:80]db:image:mysql:8.0environment:-MYSQL_ROOT_PASSWORDsecretvolumes:-./mysql_data:/var/lib/mysqldocker-composeup-d# 后台启动所有服务docker-composedown# 停止并清理网络与安全# 自定义网络容器间通过服务名通信dockernetwork create my-netdockerrun-d--networkmy-net--nameapp1 myapp# 资源限制防止单容器吃光宿主机dockerrun-d--memory512m--cpus1myapp:latest# 只读文件系统安全加固dockerrun-d--read-only--namesecure-app myapp:latest二、K8s 核心资源一张图讲清关系2.0 K8s 集群架构K8s 采用控制平面-工作节点架构Master 节点控制平面kube-apiserver集群统一入口所有操作都经过它etcd高可用 KV 存储集群的大脑——所有状态数据存在这里kube-scheduler决定 Pod 放在哪个 Node详见 §三kube-controller-manager运行各类控制器不断调谐实际状态→期望状态Node 节点工作负载kubelet每个 Node 的工头接收 PodSpec 并确保容器健康运行kube-proxy维护网络规则实现 Service 的流量转发Container Runtime真正运行容器的组件containerd / CRI-O关键认知Master 挂了已有 Pod 不受影响kubelet 独立运行但无法创建新 Pod、无法调度、无法滚动更新。这就是为什么生产集群 Master 必须高可用至少 3 节点。2.1 一句话理解K8s 容器编排平台——你告诉它我要 3 个 nginx 实例每个 512MB 内存它自动调度、自动重启、自动扩缩。2.2 核心资源关系Deployment声明期望副本数滚动更新策略 │ └── 管理 ReplicaSet维护指定数量的 Pod 副本 │ └── 管理 Pod最小调度单元 │ ├── Container业务容器 Sidecar │ ├── ConfigMap / Secret配置与代码分离 │ └── Service给 Pod 挂固定 VIPDNS │ └── Ingress七层 HTTP 路由入口资源一句话技术要点Pod最小调度单元1 容器共享网络/存储命名空间“一组紧密协作容器的逻辑主机”ServicePod 的稳定访问入口Pod IP 会变Service IP 不变“给一组 Pod 挂个固定 VIP DNS”Deployment声明式管理副本数 滚动更新 回滚“你写期望状态K8s 把实际状态调到期望”ConfigMap/Secret配置与代码分离“ConfigMap 存配置Secret 存密码/token”Ingress七层 HTTP 路由入口“K8s 世界的 Nginx”2.3 关键机制声明式 API写 YAML 定义期望状态 → Controller 不断调谐使之匹配。你不需要写怎么启动只需要写应该是 3 个 Pod 运行着滚动更新先启新 Pod → 健康检查通过 → 逐步停旧 Pod失败自动回滚kubectl rollout undo1 秒完成健康检查livenessProbe活没活死了重启vsreadinessProbe准备好没未就绪不切流量——前者是存活兜底后者是流量门神三、Pod 调度K8s 怎么决定 Pod 放哪个 Node调度器kube-scheduler分两步第一步过滤——排除不合格的 Node资源不够→ 排除Pod 申请的 CPU/Memory 超过 Node 剩余量 Node 有污点且 Pod 没容忍→ 排除 不满足亲和性/反亲和性规则→ 排除 端口被占用或存储卷不匹配→ 排除 Node 状态 NotReady→ 排除第二步打分——给剩余 Node 排名打分策略含义LeastRequestedPriority资源剩余越多分越高默认权重最高BalancedResourceAllocationCPU 和内存比例越均衡分越高NodeAffinityPriority越匹配亲和性规则分越高ImageLocality本地已有镜像的 Node 加分省拉取时间打分计算示例假设集群中有 Node A 和 Node B 通过过滤阶段调度器对两者计算加权总分Node A剩余 CPU 60%剩余内存 40%本地有镜像 LeastRequestedPriority: 85 分 × 权重 0.5 42.5 BalancedResourceAllocation: 70 分 × 权重 0.3 21.0 ImageLocality: 100 分 × 权重 0.2 20.0 总分 83.5 Node B剩余 CPU 30%剩余内存 70%无本地镜像 LeastRequestedPriority: 50 分 × 权重 0.5 25.0 BalancedResourceAllocation: 40 分 × 权重 0.3 12.0 CPU 和内存比例失衡 ImageLocality: 0 分 × 权重 0.2 0.0 总分 37.0Node A 总分 83.5 Node B 37.0 → Pod 调度到 Node A。分数加权求和 → 最高分当选 → 绑定写入 etcd。核心原理“调度器 海选过滤不合格的→ 排位赛按资源/亲和性/本地镜像打分→ 决赛最高分绑定。整个过程是声明式的——你写期望状态调度器找最优落点。”四、HPA 自动扩缩容HPAHorizontal Pod Autoscaler核心公式期望副本数 ceil(当前副本数 × 当前指标值 / 目标指标值)例如3 个 PodCPU 使用率 80%目标 50% →ceil(3 × 80/50) 5→ 扩到 5 个。关键机制指标来源metrics-serverCPU/内存或 Prometheus Adapter自定义指标如 QPS/延迟冷却时间扩容后等 3 分钟再扩、缩容后等 5 分钟再缩防止抖动KEDA事件驱动扩缩Kafka 积压、Redis 队列长度比原生 HPA 更灵活HPA vs VPA水平还是垂直策略方式适用场景HPA水平增减 Pod 副本数无状态服务Web/API靠多副本分摊流量VPA垂直调整 Pod 资源 request/limit有状态服务DB/Cache不能简单加副本联动HPA 处理突发流量VPA 优化资源配置大规模集群降本——VPA 发现 request 设太高了就下调生产踩坑扩容不是实时的metrics-server 采集间隔 15-30s HPA 检查间隔 15s → 扩容延迟约 1-2 分钟 → 瞬间流量尖峰需配合提前预热 业务层限流五、滚动更新先启新再停旧核心参数参数含义默认值maxSurge超出期望副本数的最大 Pod 数25%maxUnavailable允许不可用的最大 Pod 数25%minReadySeconds新 Pod 启动后需等待多少秒才视为就绪0更新过程① 创建新 ReplicaSet ② 逐步增加新 Pod、减少旧 Pod按 maxSurge/maxUnavailable 控制速度 ③ 新 Pod 通过 readinessProbe minReadySeconds 后加入 Service ④ 旧 Pod 等待 terminationGracePeriodSeconds 优雅退出 ⑤ 旧 ReplicaSet 保留用于回滚回滚kubectl rollout undo deployment/xxx→ 1 秒切回上一个 ReplicaSet。六、kubectl 排错三板斧1.kubectl describe— 看发生了什么kubectl describe podpod-name关键看Events 字段调度失败原因资源不足/污点、镜像拉取耗时、容器启动/退出时间、OOMKilled 标记。2.kubectl logs— 看应用说了什么kubectl logspod-name-ccontainer-name--tail100-f# --previous 看上一次崩溃容器的日志找 CrashLoopBackOff 根因kubectl logspod-name--previous3.kubectl exec— 看里面长什么样kubectlexec-itpod-name-- /bin/bash# 进去后curl localhost:8080/health | env | cat /etc/hosts | df -h | free -m | ps aux补充三板斧kubectl get events --sort-by.lastTimestamp→ 全集群异常全局视图kubectl top pod/node→ 实际 CPU/内存使用量需 metrics-serverkubectl port-forward pod/xxx 8080:8080→ 本地直连 Pod 调试kubectl 常用命令速查# 资源查看kubectl get pods-owide# Pod 列表 Node/IP 信息kubectl get pods-A|grep-vRunning# 找出所有异常 Podkubectl describe podname-nns# Pod 详情 Eventskubectl logspod-f--tail100# 日志跟踪# 操作kubectl scale deployment/xxx--replicas5# 手动扩缩容kubectl rollout undo deployment/xxx# 回滚到上一版本kubectl rollouthistorydeployment/xxx# 查看历史版本kubectl edit deployment/xxx# 在线编辑 YAML# 调试kubectlexecpod--env# 查看环境变量kubectlcppod:/path/file ./file.txt# 从 Pod 复制文件七、容器排错案例OOMKilled症状kubectl describe pod的 State 显示Last State: Terminated Reason: OOMKilled Exit Code: 137137 128 9SIGKILL——是内核 OOM Killer 杀的。排查思路① kubectl top pod → 看实际内存用量是否接近 limit 且持续增长内存泄漏 ② kubectl logs pod --previous → 看上一次崩溃前日志 ③ Java 应用 → jmap -histo pid 看对象分布在容器崩之前 exec 进去采样 ④ 检查 spec.containers[].resources.limits.memory → limit 是否设太低根因分类根因特征解决内存泄漏最常见内存持续增长静态集合/ThreadLocal/连接池排查Limit 设太小正常业务峰值就超了压测确定 peak × 1.2JVM 不知道容器限制heap container limitJDK 10 启用-XX:UseContainerSupport大对象突发某次请求加载巨量数据业务代码改流式处理 JDK 版本与容器内存的关键认知JDK 8 的 JVM 默认以宿主机内存为基准计算堆大小不知道 cgroup 的 memory limit。在 512MB limit 的容器中JVM 可能试图分配 1GB 堆 → 超过 cgroup limit → OOMKilled。JDK 10 的-XX:UseContainerSupport默认开启让 JVM 感知 cgroup 的内存限制以 limit 而非宿主机内存为基准。JDK 8 需手动加-XX:UnlockExperimentalVMOptions -XX:UseCGroupMemoryLimitForHeap。八、补充概念速览NetworkPolicy网络策略K8s 的防火墙规则——控制 Pod 之间及 Pod 与外部之间的流量。默认所有 Pod 互通创建 NetworkPolicy 后变默认拒绝白名单放行。需 CNI 插件支持Calico/Cilium 支持Flannel 不支持。PV/PVC/StorageClassPV 物理存储NFS/云盘/Ceph管理员创建PVC 存储申请声明“我要 5GB 读写一次”用户创建StorageClass 动态创建 PV 的模板用户创建 PVC → SC 自动创建 PVStatefulSet 依赖 PVC 保证 Pod 重建后绑到同一个 PV有状态服务的持久标识。RBACServiceAccountPod 的身份标识Role在 Namespace 内什么能做RoleBinding把两者绑在一起。Deployment vs StatefulSetDeploymentStatefulSet状态无状态Pod 可互换有状态持久标识持久存储有序启停Pod 命名随机后缀nginx-7d8f-abc有序编号mysql-0, mysql-1, mysql-2扩缩容任意顺序逆序缩容、顺序扩容典型场景Web 应用、API 服务数据库、消息队列、ZK九、K8s 集群搭建实战概要以下以 kubeadm 为例展示核心流程帮助理解集群组件如何协作环境准备所有节点# 关闭 Swapkubelet 强制要求swapoff-ased-i/swap/d/etc/fstab# 配置内核参数bridge 网络所需modprobe br_netfiltercat/etc/sysctl.d/k8s.confEOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 EOFsysctl-p/etc/sysctl.d/k8s.conf# 安装组件yuminstall-ykubelet kubeadm kubectl systemctlenablekubeletMaster 初始化kubeadm init\--apiserver-advertise-addressMaster IP\--image-repository registry.cn-hangzhou.aliyuncs.com/google_containers\--pod-network-cidr172.20.0.0/16# 配置 kubectlmkdir-p$HOME/.kubecp-i/etc/kubernetes/admin.conf$HOME/.kube/configNode 加入 网络插件# Node 节点执行kubeadmjoinMaster IP:6443--tokentoken--discovery-token-ca-cert-hash sha256:hash# 安装 Calico 网络插件kubectl apply-fhttps://docs.tigera.io/calico/latest/manifests/calico.yaml验证kubectl create deployment nginx--imagenginx kubectl expose deployment nginx--port80--typeNodePort# 浏览器访问 http://任意Node IP:NodePort⚠️ K8s 1.24 已移除 Docker 内置支持需使用 containerd 作为容器运行时。十、HelmK8s 的包管理器# 安装 Helmcurlhttps://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3|bash# 一键部署 MySQL含 PVC/Service/Secrethelm repoaddbitnami https://charts.bitnami.com/bitnami helminstallmy-mysql bitnami/mysql--setauth.rootPasswordroot123# 自定义 values 部署helminstallmy-app ./my-chart-fvalues-prod.yaml# 回滚helm rollback my-app1价值避免每次部署手写 DeploymentServiceConfigMapSecretIngressPVC 六七个 YAML。Helm Chart 把它们打包为一个应用一键安装/升级/回滚。十一、K8s 版本升级注意事项K8s 版本演进快以下关键变化影响升级决策版本变化影响1.24移除 Docker 内置支持必须迁移到 containerd/CRI-O1.25移除 PodSecurityPolicy改用 Pod Security Admission1.29移除 in-tree CephFS/RBD 卷插件迁移到 CSI 驱动升级铁律逐版本升级1.24→1.25→1.26→…不可跨多个大版本。升级前用kubectl convert检查 API 废弃情况。核心要点回顾容器 vs 虚拟机——容器是 Linux namespace进程隔离和 cgroup资源限制的组合共享宿主机内核启动秒级、占用 MB 级。镜像分层每条 Dockerfile 指令产生一个只读层核心收益为共享复用、构建缓存、增量传输。K8s 集群采用 Master/Node 架构——apiserver 统一入口、etcd 存储状态、scheduler 调度 Pod、controller-manager 持续调谐每个 Node 上的 kubelet 管理容器健康、kube-proxy 维护网络规则。Pod 调度分两步过滤排除资源不足/污点/端口冲突的 Node→ 打分LeastRequestedPriority/BalancedResourceAllocation/ImageLocality 加权求和。HPA公式ceil(当前副本 × 当前指标/目标指标)冷却时间防止抖动生产延迟约 1-2 分钟。滚动更新通过 maxSurge 和 maxUnavailable 控制新旧 Pod 替换速度。排错三板斧describe pod 看 Events → logs --previous 看崩溃前日志 → exec 进容器检查。OOMKilledExit Code 137 128 9 SIGKILL根因四类内存泄漏、Limit 设太小、JVM 不知道容器限制JDK 10 UseContainerSupport 解决、大对象突发。集群搭建以 kubeadm init kubeadm join 为核心流程Calico 提供 Pod 网络。Helm将 DeploymentServiceConfigMap 等打包为 Chart一键安装/升级/回滚。版本升级必须逐版本进行关键变化包括 1.24 移除 Docker 支持、1.25 移除 PodSecurityPolicy。上一篇《负载均衡与高可用》 |下一篇《设计模式》系列专栏《Java 后端核心知识图谱》Java专栏聊聊你的经历Docker 镜像你们一般多大我们来投个票A. 200MB B. 200-500MB C. 500MB-1GB D. 1GB。我先说优化前 1.2GBD 区多阶段构建alpine 后 200MBA 区。K8s 滚动更新翻过车吗——新 Pod 一直 CrashLoopBackOff、旧 Pod 已被干掉如果这篇文章帮你的镜像从 1.2G 瘦到 200MB或者帮你搞懂了 OOMKilled 137 怎么排查欢迎收藏点赞