1. 从单机容器到企业级编排中间到底隔了什么1.1 Docker解决了“单机”问题却留下了“集群”的烂摊子先说个很现实的场景。很多团队从 Docker 入门docker run、docker compose 用得飞起单个应用容器化改造做完后所有的镜像、数据卷、网络配置都堆在一台物理机上。一开始人少、流量小感觉一切都很顺。但等业务量上来或者要上多套环境、多套应用互相调用的时候问题就藏不住了机器宕机了怎么办资源不够了怎么办多个副本怎么调度配置怎么统一管理版本怎么平滑升级这些问题的本质是Docker 解决的是“在一台机器上把应用跑起来”的问题但企业级应用集群需要的是“在多台机器上把一组应用管起来”的能力。容器只是打包和运行的基本单元编排才是让几十上百个容器协同工作的关键。1.2 Kubernetes 就是为解决多机编排而生的Kubernetes 的核心价值可以用四个字概括声明式编排。你告诉它“我要跑 3 个副本每个副本需要 1 核 2G 内存暴露 8080 端口”剩下的副本有多少、运行在哪台机器、网络怎么通、挂了怎么拉起、流量怎么分发全部由控制平面来保证。这与传统运维的“命令式”操作有本质区别。以前我们用脚本批量启动进程、检查存活、手工摘流量每台机器都是一个孤岛K8s 把整个集群抽象成一台“巨型机器”所有节点只是资源池。这对企业应用的意义非常直接应用不需要关心自己跑在哪台机器上只要声明需求集群负责兜底。1.3 从Docker到K8s不是替换而是分层协作有同学经常问有了 Kubernetes 是不是就不需要 Docker 了答案是不对。Kubernetes 本身不运行容器它依赖容器运行时来干活。业界最常见的方式仍然是通过 containerd或者早期版本的 dockerd拉起容器。K8s 做的是生命周期管理、网络打通、存储挂载、滚动发布Docker 负责的是镜像构建、格式标准、底层运行时隔离。两者是上下层关系不是替代关系。所以章节标题才会叫“Docker容器化部署企业级应用集群”而不是叫“用K8s抛弃Docker”。正确理解是先有 Docker 做镜像标准化再通过 K8s 把镜像变成真正可靠的分布式服务。2. 集群规划与基础环境准备这一步省不了2.1 硬件资源怎么评估别拍脑袋很多第一次搭 K8s 集群的同学上来就按“三台机器 每台 8 核 16G”的标准抄作业结果资源大量浪费或者反过来单台机器配置不够导致部署失败。做企业级集群规划第一步不是安装而是算账。先从工作负载反推。假设你的业务应用有 A、B、C 三个服务A 需要 2 副本、每副本 2C4GB 需要 3 副本、每副本 1C2GC 无状态但需要 3 副本、每副本 4C8G。加上管理组件本身的消耗etcd、API Server、Scheduler、Controller Manager、kubelet、网络插件以及 20% 左右的余量才能得出节点规格。这里有一个我实践下来比较稳的分配逻辑控制平面节点建议至少 2 台小规模集群 4C8G 起步etcd 尽量放在独立的磁盘上SSD 是硬性要求I/O 瓶颈是 etcd 最常见的故障来源工作节点按“可用内存 总内存 - 系统预留 - K8s 组件占用”来估不要把节点打满要留出 Pod 调度和系统进程的缓冲如果应用里有 Elasticsearch、ClickHouse 这类重存储的服务节点必须挂独立数据盘系统盘和数据盘分开是底线提示很多初学者以为 Kubernetes 集群节点越多越好其实小规模3-10台核数高一点反而更稳。节点太多会导致 etcd 的 watch 请求和 API Server 的列表压力变大管理面开销反而吃掉业务资源。2.2 操作系统与内核参数这些坑跳过一个是一个生产环境我建议统一使用较新的 Linux 发行版版本不要太激进选稳定维护期内的即可。为什么Kubernetes 对内核版本有要求太老的内核会导致 ipvs 模式、overlay 存储驱动、cgroup v2 支持不完整踩起来很难受。初始化时一定要检查几个关键内核参数推荐直接写成配置cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 vm.swappiness 0 vm.overcommit_memory 1 fs.inotify.max_user_instances 8192 fs.inotify.max_user_watches 524288 EOF sysctl -p /etc/sysctl.d/k8s.conf解释两个容易忽略的fs.inotify.max_user_watches这个参数如果你跑的应用里有大量文件监听比如 Java 应用、Node 应用的 watch 模式默认值很容易被打爆导致容器内报“too many open files”之类的问题很多人误以为是文件描述符限制其实是 inotify 不够net.netfilter.nf_conntrack_max也要调大一点否则你在高并发场景下出网或入网会莫名丢包尤其是大量短连接的企业应用特别明显还有记得关闭交换分区。K8s 从 1.24 之后可以支持 swap但我个人不推荐生产环境开。原因很简单内存回收策略和 Pod 的 QoS 等级会发生冲突你没法准确判断容器何时被杀死。机房里的机器内存不够就加内存比开 swap 拿系统稳定性换性能要明智得多。2.3 版本选择与服务发现组件确定性比追新重要版本选择这块我强烈建议不要踩最新版本而是选择当前社区维护的稳定版本。原因很实际Kubernetes 迭代速度很快大版本的小版本更新频繁最新的次版本往往存在一些回归问题而企业环境追求的是可预测性。举个我自己踩过的教训某次部署用了某个较新的 K8s 小版本结果集群运行一段时间后 kube-proxy 出现异常conntrack 表刷新逻辑跟内核版本有兼容性问题排查了整整两天最后回退一个补丁版本就好了。所以选版本别选最潮的选最多人用的。容器运行时如果是从 Docker 时代过来的人天然会用 dockerd 作为运行时。现在情况变了K8s 已经废弃了 dockershim推荐直接用 containerd 作为运行时。这个切换本身对上面的应用影响很小因为你构建镜像时打出来的还是 OCI 镜像底层运行方式一致。镜像仓库也需要提前规划。生产集群拉取镜像经常遇到网络不稳定的问题建议提前把用到的系统组件镜像pause、coredns、metrics-server、flannel/calico 等推到私有的镜像仓库里面这样集群初始化的时候速度会快非常多也避免部署过程中因为镜像拉取失败导致初始化中断。3. 从零搭建高可用Kubernetes集群完整实操记录3.1 控制平面初始化流程拆解我以 kubeadm 工具为例它也是当前最主流的搭建方式三步走安装组件 - 初始化控制平面 - 配置 kubeconfig。先装好 kubeadm、kubelet 和 kubectl。注意安装时需要指定版本三条命令必须用同一个版本号否则版本不一致会出现 API 版本兼容问题sudo apt-get install -y kubelet1.28.2-1.1 kubeadm1.28.2-1.1 kubectl1.28.2-1.1然后写一个 init 配置文件比直接命令行传参清楚得多。这里我给出一个精力验证过的配置cat EOF /etc/kubernetes/kubeadm-init.yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 10.0.0.11 bindPort: 6443 --- apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.28.2 controlPlaneEndpoint: 10.0.0.100:6443 networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 dnsDomain: cluster.local --- apiVersion: kubeadm.k8s.io/v1beta3 kind: KubeletConfiguration cgroupDriver: systemd EOF kubeadm init --config/etc/kubernetes/kubeadm-init.yaml这里有个非常关键的概念要拆开讲controlPlaneEndpoint。单机测试集群可以不用它但企业级多控制节点集群必须配。它本质上是给整个控制平面做了一个虚拟入口所有 kubelet、kubectl 组件都通过这个地址访问 API Server而不是直连某一个 Master IP。有了它后续控制节点挂了才能飘走才能真正实现高可用。pods 网段和服务网段的选择也有讲究。Pod 网段决定了集群里每个 Pod 拿到的 IP 范围服务网段是给 Service 分配 ClusterIP 用的。这两个网段不能和宿主机网段重叠否则会出现路由冲突。我踩过的坑就是 podSubnet 选得跟公司办公网段后段重合结果 Pod 访问外部服务时经常无响应。初始化完成后把 kubeconfig 拷贝出来mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config然后查看节点状态你会发现控制节点状态是 NotReady这是正常的因为还没有装网络插件。3.2 工作节点加入集群没那么神秘生成加入令牌kubeadm token create --print-join-command输出类似这样的一条命令在工作节点上直接执行即可kubeadm join 10.0.0.100:6443 --token 你的token --discovery-token-ca-cert-hash sha256:你的hash这条命令背后做的事情值得理解一下工作节点通过 controlPlaneEndpoint 访问 API Server用 token 完成临时身份认证通过 CA 证书 hash 验证控制平面的真实性防止中间人攻击节点启动 kubelet向控制平面注册自己并保持心跳注意token 默认有效期只有 24 小时如果加入节点时提示 token 过期用kubeadm token create重新生成即可。另外如果你的控制节点是 HA 模式join 命令里的地址必须是 load balancer 的地址不能是某一个 Master 的地址否则某台 Master 挂了这个节点也连不上了。加入后查看节点状态kubectl get nodes如果节点一直显示 NotReady大概率是网络插件没装好或者 kubelet 日志里有证据。现在立刻干活看 kubelet 日志。journalctl -u kubelet -f日志指向哪里就排查哪里最常见的是容器运行时 cgroup driver 不一致。前面 init 配置文件里已经写了cgroupDriver: systemd节点上的容器运行时也需要是 systemd两者一致才行。3.3 网络插件与存储插件怎么选这次一次说清网络这块我只推荐两个路线双栈环境或严格性能场景用 Calico通用场景用 Flannel。别在这上面反复横跳网络插件的选择和迁移成本比表面看到的要大得多。Flannel 的部署很简单kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml但我更建议在生产环境走 Calico。理由不是 Flannel 不行而是企业级应用经常需要 NetworkPolicy比如只允许某个服务访问另一个服务Flannel 本身不提供网络策略能力要再加一层插件复杂度就上去了。Calico 原生支持 BGP 路由模式性能好策略能力强。Calico 部署后注意检查它的 Pod 是否能正常运行kubectl get pods -n calico-system如果 Calico Pod 反复重启最常见的两个原因一是IP_AUTODETECTION_METHOD没有指定Calico 自动选择了错误的网卡导致路由宣告失败二是主机的net.ipv4.ip_forward没有开启。第二个问题在你执行前面 sysctl 配置时已经解决第一个问题解决办法是在 Calico 的 DaemonSet 环境变量里手动指定网卡env: - name: IP_AUTODETECTION_METHOD value: interfaceeth.*存储插件方面如果跑的是有状态应用数据库、消息队列等建议在集群初始化阶段就把本地存储或网络存储接入。最省事的方案是使用local-path-provisioner这类本地存储方案注意这是本地方案不支持跨节点漂移只适合测试环境。生产环境要么走企业级存储后端需要看具体存储设备要么走开源分布式存储方案。这里只提醒一件事创建 StorageClass 时reclaimPolicy一定要设置为Retain不要用默认的Delete。否则你删除 PVC 的时候里面的数据会直接被回收那种“删了个测试卷结果把生产数据库同时删了”的事故我见过不止一次。4. 企业应用容器化改造与镜像落地实践4.1 镜像分层设计与体积瘦身这些细节直接影响交付效率企业应用容器化第一步是写好 Dockerfile。一个看起来不大的问题——镜像体积——往往在集群部署时变成大问题。想象一下你有 50 个工作节点每次发布拉取的镜像从 1.5GB 变成 300MB发布速度会快多少拉取失败率会降多少瘦身的核心思路是分层缓存与构建分离。以 Java 应用为例不推荐把构建好的 fat jar 直接塞进镜像里而是用多阶段构建# 构建阶段 FROM maven:3.8-openjdk-11 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests # 运行时阶段 FROM openjdk:11-jre-slim WORKDIR /app COPY --frombuilder /build/target/app.jar . EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]这里有一个很关键的分层技巧先把 pom.xml 拷进去单独跑一次依赖下载再把源码拷进去编译。因为 Docker 的缓存机制是基于每一条指令的输入变化来判断的只要 pom.xml 没变mvn dependency:go-offline这一层就直接命中缓存编译阶段只需要重新编译源码改动整个构建时间大幅缩短。运行时阶段选jre-slim而不是jdk这一点能省很多空间。Java 应用在容器里跑不需要编译器只需要 JRE。这个事情说起来简单但我在交付经验里见过太多团队直接把 JDK 镜像塞进去白白多出两百多兆。4.2 从 Compose 到 K8s 清单的映射别一行行翻译很多团队是先有 docker-compose.yml再往 Kubernetes 迁移。在迁移过程中最容易犯的错误是试图把 Compose 文件里的每个字段“一对一”翻译成 K8s 的 YAML。这么做的结果通常是 YAML 越来越厚维护成本越来越高。正确姿势是理解两者的抽象层级区别Compose 里的 service映射到 K8s 里大概率不是一个 Deployment 而是多个资源Deployment控制副本 Service提供稳定访问入口 ConfigMap保存配置 Secret保存密钥Compose 里的 depends_on 依赖关系在 K8s 里不应该用任何机制去模仿。K8s 中 Service 本身就提供了负载均衡和 DNS 服务发现只要服务名能被解析启动顺序就不再是关键问题你不需要关心数据库先启动还是应用先启动Compose 里的 volumes在 K8s 里要区分是临时卷还是持久卷。代码目录用 emptyDir 或临时卷即可数据库目录用 PVC这里放一个简单的映射参考表Compose 概念Kubernetes 对应资源说明serviceService DeploymentService 只负责流量路由Deployment 负责副本管理environmentConfigMap / Secret非敏感用 ConfigMap敏感用 SecretvolumesPVC / emptyDir持久化用 PVC临时缓存用 emptyDirdepends_on无需处理通过服务发现自动完成依赖解析restart: always无需设置Kubelet 会自动重启异常退出的 PodportsService 的 port/targetPort不需要再用宿主机端口映射networks无需处理CNI 插件自动打通容器网络4.3 配置、密钥与镜像拉取策略生产环境不能偷懒企业应用一定会有配置文件和密码。把这些东西直接写进镜像或者塞在环境变量里都是风险极高的做法。配置用 ConfigMap密钥用 Secret。两者本质都是 etcd 里保存的对象区别只在于 Secret 做了 Base64 编码。但是有一个很常见的安全误解Secret 的 Base64 编码并不等于加密。任何能访问 K8s API 的人都能轻松解码。要真正保护敏感信息需要配合外部密钥管理系统或启用 K8s 的静态加密配置在 API Server 的配置里指定加密 Provider。镜像拉取策略同样讲个经验值测试环境直接imagePullPolicy: Always保证每次部署都是最新代码生产环境建议IfNotPresent前提是你的 CI 给镜像打的 tag 是唯一的比如 git commit sha否则“同名 tag 本地有旧镜像”的问题会悄悄出现注意两个不同团队共用同一个镜像仓库如果你随便把 tag 命名成 latest、v1.0那么生产环境上的版本就不可控了。我们后来统一成/应用名/镜像名:GitCommitSha的规则一个问题立刻消失再也不需要深夜登录服务器上去看“这个 Pod 到底跑的哪个版本”。5. 生产环境应用部署与发布策略5.1 Deployment 还是 StatefulSet判断标准就三条很多新手在选择工作负载类型时犹豫不定其实就三条判断标准应用是否需要稳定的网络标识Pod 名称固定不变应用是否有持久化状态并且每个副本必须挂载不同数据卷应用是否需要有序启动、有序销毁比如主从架构的数据库如果以上三条都是否无脑选 Deployment。大部分企业后台服务属于这一类无状态可以随时杀掉重建可以随意横向扩容。这类服务用 Deployment 最合适因为 Deployment 自带滚动更新和回滚机制部署、升级都是顺手的事。如果应用确实需要固定网络标识和有状态存储比如一套三节点的中间件集群类似 ZooKeeper、Kafka 这类用 StatefulSet。每一行 Pod 有唯一名称例如zk-0、zk-1、zk-2通过无头服务headless service解决相互发现的问题。让我说一句大实话如果业务没有明确要求 StatefulSet不要因为它看起来更高级就选它。StatefulSet 的滚动更新、缩容都有限制处理起来要小心得多。它不会自动清理 PVC如果你删除一个 StatefulSetPVC 还在你需要自己决定是否删除这个设计是有意为之——防止数据误删。5.2 Service、Ingress 与负载均衡流量进入集群的三层关卡传统的单一应用部署好比只有一个入口门人来了直接进。在 K8s 里访问内部服务需要经过这样一条路径客户端 - Ingress Controller - Service - Pod先讲 Service。Service 给一组 Pod 提供统一的虚拟 IPClusterIP和 DNS 名字比如你在 Pod 里访问http://order-service就会解析到 ClusterIP再由 kube-proxy 或相关代理转发到后端的某个 Pod。这里有个细节很多人不了解Service 选择后端 Pod 的方式是标签选择器也就是selector。如果你的 Service 定义的 selector 不匹配任何 Pod 的标签Service 就相当于一个空壳没有后端可用。排查问题时第一站永远是它。Ingress 解决了“外部怎么访问集群内服务”的问题。它其实是一个反向代理规则集合具体实现由 Ingress Controller 负载比如 Nginx Ingress Controller。写 Ingress 时注意几个配置点apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/proxy-body-size: 50m spec: rules: - host: app.example.local http: paths: - path: /api pathType: Prefix backend: service: name: backend-service port: number: 8080关键点pathType有Exact和Prefix的区别。Prefix匹配 /api 以及 /api/anythingExact只精确匹配 /api注意这个精准细节相当影响路由规则。另外proxy-body-size注解如果不配置Nginx 默认只允许 1MB 的请求体文件上传接口就报 413这属于上线才会发现的坑。5.3 滚动更新、回滚与优雅停服发布上线不再慌滚动更新是 Deployment 最有价值的能力之一。默认策略是 RollingUpdate它不会把旧版本 Pod 全部杀掉再启动新版本而是逐批替换保证服务不中断。默认参数 maxSurge: 25% maxUnavailable: 25%意思是更新时最多允许多出 25% 的新 Pod同时最多允许 25% 的旧 Pod 不可用。比如你当前有 4 个副本更新时会先启动 1 个新 Pod就绪后杀掉 1 个旧 Pod然后循环。这个默认参数在大多数场景下够用但如果你的应用是重量级服务启动要 2 分钟内存占用高我建议把maxSurge调成 1、maxUnavailable调成 0即保证至少有一个新 Pod 完全就绪后再杀旧 Pod。代价是发布会多占用一点资源但稳定性强很多。优雅终止是发布时另一个容易忽略的点。K8s 在需要终止一个 Pod 时会先发送 SIGTERM 信号给主进程等待一个宽限期默认 30 秒宽限期过了再发 SIGKILL 强制杀死。Java 应用要特别注意一点默认的 shutdown 钩子如果没有做逻辑处理收到 SIGTERM 就直接退出了此时如果有请求还在处理中就会出现“发布时偶发 502”。解决方式是在应用代码里监听 SIGTERM先停止接受新请求再等待当前请求处理完然后再退出。Spring Boot 项目加一行配置就行server: shutdown: graceful配合spring.lifecycle.timeout-per-shutdown-phase: 30s控制等待时间。Node.js 应用也有类似机制监听 SIGTERM 后先关闭 HTTP server再退出进程。6. 集群运维、监控与常见故障排查6.1 资源配额、HPA 与集群自动伸缩K8s 的资源模型是 metrics-server 提供基础指标HPA 根据 CPU 和内存使用率自动调整副本数。HPA 的配置看起来很简单apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60这个配置的意思是当 CPU 平均使用率超过 60% 时扩容低于 60% 持续一段时间后缩容。但我要提醒一个经验HPA 不是银弹。如果你的应用没有做合理的资源请求requestsHPA 可能根本不会触发或者触发后新 Pod 因为节点资源不够而调度失败。HPA 能否工作完全取决于 Deployment 里有没有写resources.requests。没有 requests 的 Podmetrics-server 拿不到准确的基础数据或者在计算 delta 时无从比较。建议每一条生产 Deployment 必须写资源请求和限制resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Girequests 是调度依据limits 是运行上限。两者的差值代表了 Pod 可以突发使用的资源。我一直的建议是requests 写真实需要量limits 写安全上限的 1.5~2 倍。不要抠门更不要超卖太多否则节点内存打爆后内核大概率直接杀 Pod表现为莫名的 OOMKilled。6.2 日志采集、监控告警体系别等服务挂了才发现容器原生日志写在哪里一般情况下应用如果把日志写到 stdout/stderrK8s 会将其重定向到宿主机文件里Pod 被删除后日志也随之消失。这不符合企业级需求必须有集中的日志平台。业界的主流做法是Filebeat或 Fluent Bit以 DaemonSet 方式部署在每个节点采集容器日志发到日志存储系统再通过 Kibana 查询。这套链路搭起来不难但要注意三个小坑容器内应用必须把日志输出到 stdout/stderr不要自己写入文件。你可能会问我想按天切分日志文件怎么办采集层会帮你做索引和时间戳归类不需要应用层自己切文件Filebeat 采集中经常遇到模块冲突多行日志比如 Java 的异常栈会被拆成多条。需要配置 multiline 规则合并以Exception或时间戳开头的多行内容控制台日志默认是不带容器元数据的采集时必须通过 Kubernetes 的 metadatanamespace、pod_name、container_name来关联上下文否则出了问题根本定位不到是哪台机器的哪个 Pod监控告警方面我的建议是最小可用的方案是 Prometheus Grafana Alertmanager。核心指标要先关注四个层面节点层CPU、内存、磁盘、网络控制平面层API Server 的错误率与延迟、etcd 的 fsync 耗时、Scheduler 的调度延迟工作负载层Pod 重启次数、容器 OOMKilled 次数、HPA 扩缩容记录业务层请求 QPS、错误率、P99 延迟P99 延迟这个指标企业应用尤其关注。线上问题往往不是“系统不可用”而是“接口变得慢”没有业务层指标就发现不了。建议在应用里打印请求耗时日志并采集到 Prometheus 自定义指标中。6.3 高频故障复盘与排查命令速查把我这些年群里被问到最多的故障按频率排个序顺便给出排查路径。第一个镜像拉取失败 ImagePullBackOff。这个真的太常见了。先kubectl describe pod xxx看 Events 里的具体报错。如果提示unauthorized去查 imagePullSecret 和镜像仓库权限。如果提示no such host检查镜像地址有没有拼错以及私有仓库的 DNS 是否可达。如果提示 manifest unknown说明你这个 tag 不存在或者跨架构拉取比如想在 ARM 机器上跑 x86 镜像必须指定--platform或用 manifest list 方式构建多架构镜像。第二个Pod 一直 Pending。原因通常是调度不成功。kubectl describe pod xxx里的 Events 会写得很明确0/3 nodes are available: 1 node(s) had untolerated taint...表示节点上有污点但 Pod 没有容忍1 Insufficient cpu表示节点资源不够0/3 nodes are available: 3 node(s) had volume node affinity conflict表示 PVC 的可用区zone跟节点对不上这是云环境里很经典的坑。有状态服务的 PVC 绑定了某个可用区的云硬盘调度器没法把 Pod 调度到没有该可用区存储的节点上。第三个服务之间调用不通。先测 DNSkubectl run curl-test --imagecurlimages/curl -it --rm -- sh在测试 Pod 里直接 curl 对方服务的 Service 名。如果 DNS 能解析但超时检查 Service 的 endpointkubectl get endpoints 服务名如果 endpoints 列表为空说明 selector 匹配不到任何 Pod查 Deployment 的 Pod 标签和 Service 的 selector 是否一致。如果 endpoints 正常但访问不通再查网络策略是否放行以及节点安全组通信规则。第四个CrashLoopBackOff。Pod 起来后立刻崩、反复重启。看日志一眼就懂kubectl logs pod名。如果日志为空用--previous参数看上一次退出时的日志。有一种情况比较隐蔽健康检查失败导致不断重启。看就绪探针或存活探针的返回码如果应用启动比较慢探针失败会导致 K8s 杀掉进程启动时间超过initialDelaySeconds就会形成一个“永远起不来”的循环。此时把initialDelaySeconds调大一点就能解决。7. 我的一些经验总结与忠告走到这里一套企业级应用集群已经能从零搭起来并能稳定承载业务。但有几句话我还是想单独拿出来说这些话不带具体技术命令更多是踩坑换来的。第一句Kubernetes 解决的是“单点故障”问题不是“水平无限扩展”的银弹。很多团队把服务部署到集群里就以为高枕无忧了。实际上数据库这种有状态组件才是整个架构中最难处理的部分往往还需要依赖外部存储和中间件这部分编排能力短板明显。规划时一定要分清哪些适合跑在 K8s 上哪些依然需要独立部署。第二句不要追求“全家桶”。一个刚建好的集群今天装个 Service Mesh明天加个 Operator 框架后天上一套 GitOps 流水线表面上是搞现代化实际上是把很多不成熟的组件引入了生产环境。每引入一个新组件就多一个故障域。我见过把集群搞垮的案例没有一次是核心组件挂掉的基本都是生态组件之间的兼容性问题。第三句记录操作、写好文档比“能解决问题”更重要。K8s 集群是团队协作的产物一个人能熟练操作不代表团队能维护。任何一个变更操作先写变更单再做备份再执行执行后立刻验证。这套流程听起来繁琐但真到了凌晨两点集群出问题的时候你会感谢当初那个认真写文档的自己。最后说一个我这些年一直在用的习惯搭好集群后第一时间做一次“破坏性演练”。手动 kill 一个节点上的 kubelet或者直接停掉某台机器看看业务是否真的无感知。如果演练结果不是无感知那说明高可用只是写在 PPT 上的该补的架构短板赶紧补。这是我认为企业级集群交付验收里最重要的一步没有之一。
1. 从单机容器到企业级编排中间到底隔了什么1.1 Docker解决了“单机”问题却留下了“集群”的烂摊子先说个很现实的场景。很多团队从 Docker 入门docker run、docker compose 用得飞起单个应用容器化改造做完后所有的镜像、数据卷、网络配置都堆在一台物理机上。一开始人少、流量小感觉一切都很顺。但等业务量上来或者要上多套环境、多套应用互相调用的时候问题就藏不住了机器宕机了怎么办资源不够了怎么办多个副本怎么调度配置怎么统一管理版本怎么平滑升级这些问题的本质是Docker 解决的是“在一台机器上把应用跑起来”的问题但企业级应用集群需要的是“在多台机器上把一组应用管起来”的能力。容器只是打包和运行的基本单元编排才是让几十上百个容器协同工作的关键。1.2 Kubernetes 就是为解决多机编排而生的Kubernetes 的核心价值可以用四个字概括声明式编排。你告诉它“我要跑 3 个副本每个副本需要 1 核 2G 内存暴露 8080 端口”剩下的副本有多少、运行在哪台机器、网络怎么通、挂了怎么拉起、流量怎么分发全部由控制平面来保证。这与传统运维的“命令式”操作有本质区别。以前我们用脚本批量启动进程、检查存活、手工摘流量每台机器都是一个孤岛K8s 把整个集群抽象成一台“巨型机器”所有节点只是资源池。这对企业应用的意义非常直接应用不需要关心自己跑在哪台机器上只要声明需求集群负责兜底。1.3 从Docker到K8s不是替换而是分层协作有同学经常问有了 Kubernetes 是不是就不需要 Docker 了答案是不对。Kubernetes 本身不运行容器它依赖容器运行时来干活。业界最常见的方式仍然是通过 containerd或者早期版本的 dockerd拉起容器。K8s 做的是生命周期管理、网络打通、存储挂载、滚动发布Docker 负责的是镜像构建、格式标准、底层运行时隔离。两者是上下层关系不是替代关系。所以章节标题才会叫“Docker容器化部署企业级应用集群”而不是叫“用K8s抛弃Docker”。正确理解是先有 Docker 做镜像标准化再通过 K8s 把镜像变成真正可靠的分布式服务。2. 集群规划与基础环境准备这一步省不了2.1 硬件资源怎么评估别拍脑袋很多第一次搭 K8s 集群的同学上来就按“三台机器 每台 8 核 16G”的标准抄作业结果资源大量浪费或者反过来单台机器配置不够导致部署失败。做企业级集群规划第一步不是安装而是算账。先从工作负载反推。假设你的业务应用有 A、B、C 三个服务A 需要 2 副本、每副本 2C4GB 需要 3 副本、每副本 1C2GC 无状态但需要 3 副本、每副本 4C8G。加上管理组件本身的消耗etcd、API Server、Scheduler、Controller Manager、kubelet、网络插件以及 20% 左右的余量才能得出节点规格。这里有一个我实践下来比较稳的分配逻辑控制平面节点建议至少 2 台小规模集群 4C8G 起步etcd 尽量放在独立的磁盘上SSD 是硬性要求I/O 瓶颈是 etcd 最常见的故障来源工作节点按“可用内存 总内存 - 系统预留 - K8s 组件占用”来估不要把节点打满要留出 Pod 调度和系统进程的缓冲如果应用里有 Elasticsearch、ClickHouse 这类重存储的服务节点必须挂独立数据盘系统盘和数据盘分开是底线提示很多初学者以为 Kubernetes 集群节点越多越好其实小规模3-10台核数高一点反而更稳。节点太多会导致 etcd 的 watch 请求和 API Server 的列表压力变大管理面开销反而吃掉业务资源。2.2 操作系统与内核参数这些坑跳过一个是一个生产环境我建议统一使用较新的 Linux 发行版版本不要太激进选稳定维护期内的即可。为什么Kubernetes 对内核版本有要求太老的内核会导致 ipvs 模式、overlay 存储驱动、cgroup v2 支持不完整踩起来很难受。初始化时一定要检查几个关键内核参数推荐直接写成配置cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 vm.swappiness 0 vm.overcommit_memory 1 fs.inotify.max_user_instances 8192 fs.inotify.max_user_watches 524288 EOF sysctl -p /etc/sysctl.d/k8s.conf解释两个容易忽略的fs.inotify.max_user_watches这个参数如果你跑的应用里有大量文件监听比如 Java 应用、Node 应用的 watch 模式默认值很容易被打爆导致容器内报“too many open files”之类的问题很多人误以为是文件描述符限制其实是 inotify 不够net.netfilter.nf_conntrack_max也要调大一点否则你在高并发场景下出网或入网会莫名丢包尤其是大量短连接的企业应用特别明显还有记得关闭交换分区。K8s 从 1.24 之后可以支持 swap但我个人不推荐生产环境开。原因很简单内存回收策略和 Pod 的 QoS 等级会发生冲突你没法准确判断容器何时被杀死。机房里的机器内存不够就加内存比开 swap 拿系统稳定性换性能要明智得多。2.3 版本选择与服务发现组件确定性比追新重要版本选择这块我强烈建议不要踩最新版本而是选择当前社区维护的稳定版本。原因很实际Kubernetes 迭代速度很快大版本的小版本更新频繁最新的次版本往往存在一些回归问题而企业环境追求的是可预测性。举个我自己踩过的教训某次部署用了某个较新的 K8s 小版本结果集群运行一段时间后 kube-proxy 出现异常conntrack 表刷新逻辑跟内核版本有兼容性问题排查了整整两天最后回退一个补丁版本就好了。所以选版本别选最潮的选最多人用的。容器运行时如果是从 Docker 时代过来的人天然会用 dockerd 作为运行时。现在情况变了K8s 已经废弃了 dockershim推荐直接用 containerd 作为运行时。这个切换本身对上面的应用影响很小因为你构建镜像时打出来的还是 OCI 镜像底层运行方式一致。镜像仓库也需要提前规划。生产集群拉取镜像经常遇到网络不稳定的问题建议提前把用到的系统组件镜像pause、coredns、metrics-server、flannel/calico 等推到私有的镜像仓库里面这样集群初始化的时候速度会快非常多也避免部署过程中因为镜像拉取失败导致初始化中断。3. 从零搭建高可用Kubernetes集群完整实操记录3.1 控制平面初始化流程拆解我以 kubeadm 工具为例它也是当前最主流的搭建方式三步走安装组件 - 初始化控制平面 - 配置 kubeconfig。先装好 kubeadm、kubelet 和 kubectl。注意安装时需要指定版本三条命令必须用同一个版本号否则版本不一致会出现 API 版本兼容问题sudo apt-get install -y kubelet1.28.2-1.1 kubeadm1.28.2-1.1 kubectl1.28.2-1.1然后写一个 init 配置文件比直接命令行传参清楚得多。这里我给出一个精力验证过的配置cat EOF /etc/kubernetes/kubeadm-init.yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 10.0.0.11 bindPort: 6443 --- apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.28.2 controlPlaneEndpoint: 10.0.0.100:6443 networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 dnsDomain: cluster.local --- apiVersion: kubeadm.k8s.io/v1beta3 kind: KubeletConfiguration cgroupDriver: systemd EOF kubeadm init --config/etc/kubernetes/kubeadm-init.yaml这里有个非常关键的概念要拆开讲controlPlaneEndpoint。单机测试集群可以不用它但企业级多控制节点集群必须配。它本质上是给整个控制平面做了一个虚拟入口所有 kubelet、kubectl 组件都通过这个地址访问 API Server而不是直连某一个 Master IP。有了它后续控制节点挂了才能飘走才能真正实现高可用。pods 网段和服务网段的选择也有讲究。Pod 网段决定了集群里每个 Pod 拿到的 IP 范围服务网段是给 Service 分配 ClusterIP 用的。这两个网段不能和宿主机网段重叠否则会出现路由冲突。我踩过的坑就是 podSubnet 选得跟公司办公网段后段重合结果 Pod 访问外部服务时经常无响应。初始化完成后把 kubeconfig 拷贝出来mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config然后查看节点状态你会发现控制节点状态是 NotReady这是正常的因为还没有装网络插件。3.2 工作节点加入集群没那么神秘生成加入令牌kubeadm token create --print-join-command输出类似这样的一条命令在工作节点上直接执行即可kubeadm join 10.0.0.100:6443 --token 你的token --discovery-token-ca-cert-hash sha256:你的hash这条命令背后做的事情值得理解一下工作节点通过 controlPlaneEndpoint 访问 API Server用 token 完成临时身份认证通过 CA 证书 hash 验证控制平面的真实性防止中间人攻击节点启动 kubelet向控制平面注册自己并保持心跳注意token 默认有效期只有 24 小时如果加入节点时提示 token 过期用kubeadm token create重新生成即可。另外如果你的控制节点是 HA 模式join 命令里的地址必须是 load balancer 的地址不能是某一个 Master 的地址否则某台 Master 挂了这个节点也连不上了。加入后查看节点状态kubectl get nodes如果节点一直显示 NotReady大概率是网络插件没装好或者 kubelet 日志里有证据。现在立刻干活看 kubelet 日志。journalctl -u kubelet -f日志指向哪里就排查哪里最常见的是容器运行时 cgroup driver 不一致。前面 init 配置文件里已经写了cgroupDriver: systemd节点上的容器运行时也需要是 systemd两者一致才行。3.3 网络插件与存储插件怎么选这次一次说清网络这块我只推荐两个路线双栈环境或严格性能场景用 Calico通用场景用 Flannel。别在这上面反复横跳网络插件的选择和迁移成本比表面看到的要大得多。Flannel 的部署很简单kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml但我更建议在生产环境走 Calico。理由不是 Flannel 不行而是企业级应用经常需要 NetworkPolicy比如只允许某个服务访问另一个服务Flannel 本身不提供网络策略能力要再加一层插件复杂度就上去了。Calico 原生支持 BGP 路由模式性能好策略能力强。Calico 部署后注意检查它的 Pod 是否能正常运行kubectl get pods -n calico-system如果 Calico Pod 反复重启最常见的两个原因一是IP_AUTODETECTION_METHOD没有指定Calico 自动选择了错误的网卡导致路由宣告失败二是主机的net.ipv4.ip_forward没有开启。第二个问题在你执行前面 sysctl 配置时已经解决第一个问题解决办法是在 Calico 的 DaemonSet 环境变量里手动指定网卡env: - name: IP_AUTODETECTION_METHOD value: interfaceeth.*存储插件方面如果跑的是有状态应用数据库、消息队列等建议在集群初始化阶段就把本地存储或网络存储接入。最省事的方案是使用local-path-provisioner这类本地存储方案注意这是本地方案不支持跨节点漂移只适合测试环境。生产环境要么走企业级存储后端需要看具体存储设备要么走开源分布式存储方案。这里只提醒一件事创建 StorageClass 时reclaimPolicy一定要设置为Retain不要用默认的Delete。否则你删除 PVC 的时候里面的数据会直接被回收那种“删了个测试卷结果把生产数据库同时删了”的事故我见过不止一次。4. 企业应用容器化改造与镜像落地实践4.1 镜像分层设计与体积瘦身这些细节直接影响交付效率企业应用容器化第一步是写好 Dockerfile。一个看起来不大的问题——镜像体积——往往在集群部署时变成大问题。想象一下你有 50 个工作节点每次发布拉取的镜像从 1.5GB 变成 300MB发布速度会快多少拉取失败率会降多少瘦身的核心思路是分层缓存与构建分离。以 Java 应用为例不推荐把构建好的 fat jar 直接塞进镜像里而是用多阶段构建# 构建阶段 FROM maven:3.8-openjdk-11 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests # 运行时阶段 FROM openjdk:11-jre-slim WORKDIR /app COPY --frombuilder /build/target/app.jar . EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]这里有一个很关键的分层技巧先把 pom.xml 拷进去单独跑一次依赖下载再把源码拷进去编译。因为 Docker 的缓存机制是基于每一条指令的输入变化来判断的只要 pom.xml 没变mvn dependency:go-offline这一层就直接命中缓存编译阶段只需要重新编译源码改动整个构建时间大幅缩短。运行时阶段选jre-slim而不是jdk这一点能省很多空间。Java 应用在容器里跑不需要编译器只需要 JRE。这个事情说起来简单但我在交付经验里见过太多团队直接把 JDK 镜像塞进去白白多出两百多兆。4.2 从 Compose 到 K8s 清单的映射别一行行翻译很多团队是先有 docker-compose.yml再往 Kubernetes 迁移。在迁移过程中最容易犯的错误是试图把 Compose 文件里的每个字段“一对一”翻译成 K8s 的 YAML。这么做的结果通常是 YAML 越来越厚维护成本越来越高。正确姿势是理解两者的抽象层级区别Compose 里的 service映射到 K8s 里大概率不是一个 Deployment 而是多个资源Deployment控制副本 Service提供稳定访问入口 ConfigMap保存配置 Secret保存密钥Compose 里的 depends_on 依赖关系在 K8s 里不应该用任何机制去模仿。K8s 中 Service 本身就提供了负载均衡和 DNS 服务发现只要服务名能被解析启动顺序就不再是关键问题你不需要关心数据库先启动还是应用先启动Compose 里的 volumes在 K8s 里要区分是临时卷还是持久卷。代码目录用 emptyDir 或临时卷即可数据库目录用 PVC这里放一个简单的映射参考表Compose 概念Kubernetes 对应资源说明serviceService DeploymentService 只负责流量路由Deployment 负责副本管理environmentConfigMap / Secret非敏感用 ConfigMap敏感用 SecretvolumesPVC / emptyDir持久化用 PVC临时缓存用 emptyDirdepends_on无需处理通过服务发现自动完成依赖解析restart: always无需设置Kubelet 会自动重启异常退出的 PodportsService 的 port/targetPort不需要再用宿主机端口映射networks无需处理CNI 插件自动打通容器网络4.3 配置、密钥与镜像拉取策略生产环境不能偷懒企业应用一定会有配置文件和密码。把这些东西直接写进镜像或者塞在环境变量里都是风险极高的做法。配置用 ConfigMap密钥用 Secret。两者本质都是 etcd 里保存的对象区别只在于 Secret 做了 Base64 编码。但是有一个很常见的安全误解Secret 的 Base64 编码并不等于加密。任何能访问 K8s API 的人都能轻松解码。要真正保护敏感信息需要配合外部密钥管理系统或启用 K8s 的静态加密配置在 API Server 的配置里指定加密 Provider。镜像拉取策略同样讲个经验值测试环境直接imagePullPolicy: Always保证每次部署都是最新代码生产环境建议IfNotPresent前提是你的 CI 给镜像打的 tag 是唯一的比如 git commit sha否则“同名 tag 本地有旧镜像”的问题会悄悄出现注意两个不同团队共用同一个镜像仓库如果你随便把 tag 命名成 latest、v1.0那么生产环境上的版本就不可控了。我们后来统一成/应用名/镜像名:GitCommitSha的规则一个问题立刻消失再也不需要深夜登录服务器上去看“这个 Pod 到底跑的哪个版本”。5. 生产环境应用部署与发布策略5.1 Deployment 还是 StatefulSet判断标准就三条很多新手在选择工作负载类型时犹豫不定其实就三条判断标准应用是否需要稳定的网络标识Pod 名称固定不变应用是否有持久化状态并且每个副本必须挂载不同数据卷应用是否需要有序启动、有序销毁比如主从架构的数据库如果以上三条都是否无脑选 Deployment。大部分企业后台服务属于这一类无状态可以随时杀掉重建可以随意横向扩容。这类服务用 Deployment 最合适因为 Deployment 自带滚动更新和回滚机制部署、升级都是顺手的事。如果应用确实需要固定网络标识和有状态存储比如一套三节点的中间件集群类似 ZooKeeper、Kafka 这类用 StatefulSet。每一行 Pod 有唯一名称例如zk-0、zk-1、zk-2通过无头服务headless service解决相互发现的问题。让我说一句大实话如果业务没有明确要求 StatefulSet不要因为它看起来更高级就选它。StatefulSet 的滚动更新、缩容都有限制处理起来要小心得多。它不会自动清理 PVC如果你删除一个 StatefulSetPVC 还在你需要自己决定是否删除这个设计是有意为之——防止数据误删。5.2 Service、Ingress 与负载均衡流量进入集群的三层关卡传统的单一应用部署好比只有一个入口门人来了直接进。在 K8s 里访问内部服务需要经过这样一条路径客户端 - Ingress Controller - Service - Pod先讲 Service。Service 给一组 Pod 提供统一的虚拟 IPClusterIP和 DNS 名字比如你在 Pod 里访问http://order-service就会解析到 ClusterIP再由 kube-proxy 或相关代理转发到后端的某个 Pod。这里有个细节很多人不了解Service 选择后端 Pod 的方式是标签选择器也就是selector。如果你的 Service 定义的 selector 不匹配任何 Pod 的标签Service 就相当于一个空壳没有后端可用。排查问题时第一站永远是它。Ingress 解决了“外部怎么访问集群内服务”的问题。它其实是一个反向代理规则集合具体实现由 Ingress Controller 负载比如 Nginx Ingress Controller。写 Ingress 时注意几个配置点apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: nginx.ingress.kubernetes.io/proxy-body-size: 50m spec: rules: - host: app.example.local http: paths: - path: /api pathType: Prefix backend: service: name: backend-service port: number: 8080关键点pathType有Exact和Prefix的区别。Prefix匹配 /api 以及 /api/anythingExact只精确匹配 /api注意这个精准细节相当影响路由规则。另外proxy-body-size注解如果不配置Nginx 默认只允许 1MB 的请求体文件上传接口就报 413这属于上线才会发现的坑。5.3 滚动更新、回滚与优雅停服发布上线不再慌滚动更新是 Deployment 最有价值的能力之一。默认策略是 RollingUpdate它不会把旧版本 Pod 全部杀掉再启动新版本而是逐批替换保证服务不中断。默认参数 maxSurge: 25% maxUnavailable: 25%意思是更新时最多允许多出 25% 的新 Pod同时最多允许 25% 的旧 Pod 不可用。比如你当前有 4 个副本更新时会先启动 1 个新 Pod就绪后杀掉 1 个旧 Pod然后循环。这个默认参数在大多数场景下够用但如果你的应用是重量级服务启动要 2 分钟内存占用高我建议把maxSurge调成 1、maxUnavailable调成 0即保证至少有一个新 Pod 完全就绪后再杀旧 Pod。代价是发布会多占用一点资源但稳定性强很多。优雅终止是发布时另一个容易忽略的点。K8s 在需要终止一个 Pod 时会先发送 SIGTERM 信号给主进程等待一个宽限期默认 30 秒宽限期过了再发 SIGKILL 强制杀死。Java 应用要特别注意一点默认的 shutdown 钩子如果没有做逻辑处理收到 SIGTERM 就直接退出了此时如果有请求还在处理中就会出现“发布时偶发 502”。解决方式是在应用代码里监听 SIGTERM先停止接受新请求再等待当前请求处理完然后再退出。Spring Boot 项目加一行配置就行server: shutdown: graceful配合spring.lifecycle.timeout-per-shutdown-phase: 30s控制等待时间。Node.js 应用也有类似机制监听 SIGTERM 后先关闭 HTTP server再退出进程。6. 集群运维、监控与常见故障排查6.1 资源配额、HPA 与集群自动伸缩K8s 的资源模型是 metrics-server 提供基础指标HPA 根据 CPU 和内存使用率自动调整副本数。HPA 的配置看起来很简单apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60这个配置的意思是当 CPU 平均使用率超过 60% 时扩容低于 60% 持续一段时间后缩容。但我要提醒一个经验HPA 不是银弹。如果你的应用没有做合理的资源请求requestsHPA 可能根本不会触发或者触发后新 Pod 因为节点资源不够而调度失败。HPA 能否工作完全取决于 Deployment 里有没有写resources.requests。没有 requests 的 Podmetrics-server 拿不到准确的基础数据或者在计算 delta 时无从比较。建议每一条生产 Deployment 必须写资源请求和限制resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Girequests 是调度依据limits 是运行上限。两者的差值代表了 Pod 可以突发使用的资源。我一直的建议是requests 写真实需要量limits 写安全上限的 1.5~2 倍。不要抠门更不要超卖太多否则节点内存打爆后内核大概率直接杀 Pod表现为莫名的 OOMKilled。6.2 日志采集、监控告警体系别等服务挂了才发现容器原生日志写在哪里一般情况下应用如果把日志写到 stdout/stderrK8s 会将其重定向到宿主机文件里Pod 被删除后日志也随之消失。这不符合企业级需求必须有集中的日志平台。业界的主流做法是Filebeat或 Fluent Bit以 DaemonSet 方式部署在每个节点采集容器日志发到日志存储系统再通过 Kibana 查询。这套链路搭起来不难但要注意三个小坑容器内应用必须把日志输出到 stdout/stderr不要自己写入文件。你可能会问我想按天切分日志文件怎么办采集层会帮你做索引和时间戳归类不需要应用层自己切文件Filebeat 采集中经常遇到模块冲突多行日志比如 Java 的异常栈会被拆成多条。需要配置 multiline 规则合并以Exception或时间戳开头的多行内容控制台日志默认是不带容器元数据的采集时必须通过 Kubernetes 的 metadatanamespace、pod_name、container_name来关联上下文否则出了问题根本定位不到是哪台机器的哪个 Pod监控告警方面我的建议是最小可用的方案是 Prometheus Grafana Alertmanager。核心指标要先关注四个层面节点层CPU、内存、磁盘、网络控制平面层API Server 的错误率与延迟、etcd 的 fsync 耗时、Scheduler 的调度延迟工作负载层Pod 重启次数、容器 OOMKilled 次数、HPA 扩缩容记录业务层请求 QPS、错误率、P99 延迟P99 延迟这个指标企业应用尤其关注。线上问题往往不是“系统不可用”而是“接口变得慢”没有业务层指标就发现不了。建议在应用里打印请求耗时日志并采集到 Prometheus 自定义指标中。6.3 高频故障复盘与排查命令速查把我这些年群里被问到最多的故障按频率排个序顺便给出排查路径。第一个镜像拉取失败 ImagePullBackOff。这个真的太常见了。先kubectl describe pod xxx看 Events 里的具体报错。如果提示unauthorized去查 imagePullSecret 和镜像仓库权限。如果提示no such host检查镜像地址有没有拼错以及私有仓库的 DNS 是否可达。如果提示 manifest unknown说明你这个 tag 不存在或者跨架构拉取比如想在 ARM 机器上跑 x86 镜像必须指定--platform或用 manifest list 方式构建多架构镜像。第二个Pod 一直 Pending。原因通常是调度不成功。kubectl describe pod xxx里的 Events 会写得很明确0/3 nodes are available: 1 node(s) had untolerated taint...表示节点上有污点但 Pod 没有容忍1 Insufficient cpu表示节点资源不够0/3 nodes are available: 3 node(s) had volume node affinity conflict表示 PVC 的可用区zone跟节点对不上这是云环境里很经典的坑。有状态服务的 PVC 绑定了某个可用区的云硬盘调度器没法把 Pod 调度到没有该可用区存储的节点上。第三个服务之间调用不通。先测 DNSkubectl run curl-test --imagecurlimages/curl -it --rm -- sh在测试 Pod 里直接 curl 对方服务的 Service 名。如果 DNS 能解析但超时检查 Service 的 endpointkubectl get endpoints 服务名如果 endpoints 列表为空说明 selector 匹配不到任何 Pod查 Deployment 的 Pod 标签和 Service 的 selector 是否一致。如果 endpoints 正常但访问不通再查网络策略是否放行以及节点安全组通信规则。第四个CrashLoopBackOff。Pod 起来后立刻崩、反复重启。看日志一眼就懂kubectl logs pod名。如果日志为空用--previous参数看上一次退出时的日志。有一种情况比较隐蔽健康检查失败导致不断重启。看就绪探针或存活探针的返回码如果应用启动比较慢探针失败会导致 K8s 杀掉进程启动时间超过initialDelaySeconds就会形成一个“永远起不来”的循环。此时把initialDelaySeconds调大一点就能解决。7. 我的一些经验总结与忠告走到这里一套企业级应用集群已经能从零搭起来并能稳定承载业务。但有几句话我还是想单独拿出来说这些话不带具体技术命令更多是踩坑换来的。第一句Kubernetes 解决的是“单点故障”问题不是“水平无限扩展”的银弹。很多团队把服务部署到集群里就以为高枕无忧了。实际上数据库这种有状态组件才是整个架构中最难处理的部分往往还需要依赖外部存储和中间件这部分编排能力短板明显。规划时一定要分清哪些适合跑在 K8s 上哪些依然需要独立部署。第二句不要追求“全家桶”。一个刚建好的集群今天装个 Service Mesh明天加个 Operator 框架后天上一套 GitOps 流水线表面上是搞现代化实际上是把很多不成熟的组件引入了生产环境。每引入一个新组件就多一个故障域。我见过把集群搞垮的案例没有一次是核心组件挂掉的基本都是生态组件之间的兼容性问题。第三句记录操作、写好文档比“能解决问题”更重要。K8s 集群是团队协作的产物一个人能熟练操作不代表团队能维护。任何一个变更操作先写变更单再做备份再执行执行后立刻验证。这套流程听起来繁琐但真到了凌晨两点集群出问题的时候你会感谢当初那个认真写文档的自己。最后说一个我这些年一直在用的习惯搭好集群后第一时间做一次“破坏性演练”。手动 kill 一个节点上的 kubelet或者直接停掉某台机器看看业务是否真的无感知。如果演练结果不是无感知那说明高可用只是写在 PPT 上的该补的架构短板赶紧补。这是我认为企业级集群交付验收里最重要的一步没有之一。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
