这篇内容接着容器化系列往下走核心就一句话把那些一台台Docker主机各自为战的部署方式收拢成一套由Kubernetes统一编排的企业级应用集群。我从某企业内部订单系统的迁移过程切入完整走了一遍从集群规划、节点初始化、网络与存储落地再到弹性伸缩和流量入口配置的实操流程。适合已经把业务容器化、正准备往Kubernetes迁移的团队也适合想搞清楚企业级编排到底在解决什么问题的同学。全程会兼顾怎么操作和为什么这么操作两个维度尽量把关键决策背后的道理讲透。1. 为什么企业级应用一定要走到编排这一步1.1 单机Docker撑不住企业级集群的三座大山我见过不少团队容器化做了很久但实际部署还在用一台台Docker主机硬扛的模式。业务少的时候问题不大一旦应用数量和节点规模上来三层压力会非常明显。第一层是通信成本。容器里的服务IP是动态的扩容、重启之后IP就变了。两台服务器上的容器要互相调用要么手动维护IP清单要么在宿主机上做端口映射。假设你有20个服务、30台机器人工维护这套调用关系基本就是在给自己埋雷。第二层是运维操作。发布新版、回滚、故障转移这些动作在单机Docker模式下全靠人工执行把容器停掉、删掉、再起一个新的整个过程不可控。半夜告警响了人还得爬起来手敲命令几分钟能解决的问题往往因为操作不熟练或者环境差异拖到半小时。第三层是资源与权限治理。多套业务混在同一批机器上没有命名空间隔离没有配额管理某个服务流量一涨就能把宿主机CPU打满把无关业务一起拖垮。企业内部合规要求里经常提到的最小权限资源隔离在这种模式下很难落地。这三层痛点叠加起来就逼着大家往前走一步让一批机器形成一个集群由调度器统一决定容器运行在哪、网络怎么通、资源怎么分。这一步就是编排系统的价值所在。1.2 Kubernetes提供的核心能力到底解决了什么Kubernetes最核心的思维转变是声明式管理。传统运维关心的是怎么执行Docker部署时你要手敲run、start、restartKubernetes里你只管描述最终状态例如这个服务要有5个副本剩下的调度、健康检查、故障恢复都由控制面完成。具体到企业级场景最直接的收益是这几条服务发现与负载均衡Service对象给一组Pod提供稳定入口Pod IP怎么变都不影响调用方kube-proxy会把流量分发到后端。自动扩缩容通过HPAHorizontalPodAutoscaler按CPU、内存或自定义指标自动调整副本数流量高峰过去还能自动缩回来不用人盯着。自愈能力Deployment控制器时刻对比期望副本数和实际副本数Pod挂了自动重建节点宕了会把Pod调度到其他可用节点。资源管控通过namespace划分环境通过ResourceQuota限制团队用量通过LimitRange约束单个Pod的资源边界。这些能力组合起来原先需要运维手工处理的一大半琐事就变成了控制面里的周期循环。企业级集群从依赖人的操作变成依赖系统的调节稳定性和可维护性完全不是一个量级。2. 集群规划与初始化前置决策2.1 节点角色划分与高可用设计动手装集群之前先把拓扑想清楚。Kubernetes节点分两类控制面节点负责API Server、调度器、控制器管理器等核心组件工作节点实际运行业务Pod。企业级环境我建议至少用3个控制面节点做高可用但如果业务本身容忍短时故障例如内部管理系统单控制面加3个以上工作节点也能接受。某内部订单系统我采用的是单控制面加3个工作节点的组合。因为这属于企业内部业务变更窗口可控控制面挂了对业务影响有限先保证业务节点有冗余就够了。控制面节点我给了4核8G工作节点按业务负载给了8核16G。注意控制面节点默认有污点业务Pod不会被调度上去这点初始化完就生效不用额外配置。节点规格选型有个容易被忽略的点不要只看当前负载要给未来半年的增长留余量。集群扩容节点本身不复杂但每次扩容都要牵涉网络、存储、监控一系列配置能一次性规划到位后面会省很多事。2.2 容器运行时从Docker到containerd这块值得单独说。早期Kubernetes版本通过dockershim直接支持Docker运行时但Kubernetes 1.24之后移除了dockershim原生支持的就是containerd、CRI-O这类符合CRI容器运行时接口标准的运行时。我实际部署时直接选了containerd理由很实际它是Kubernetes生态里默认集成度最高的运行时安装之后通过crictl命令管理容器比在Kubernetes里继续依赖Docker少一层中间转换资源开销也更低。这里有个坑必须提醒containerd装完默认配置文件并不带systemd cgroup驱动参数。Kubernetes要求kubelet和容器运行时的cgroup驱动保持一致通常都用systemd否则节点初始化之后kubelet会一直报cgroup驱动不匹配Pod根本起不来。处理方法是在containerd配置里把SystemdCgroup改成true然后重启containerdsudo containerd config default | sudo tee /etc/containerd/config.toml sudo sed -i s/SystemdCgroup false/SystemdCgroup true/g /etc/containerd/config.toml sudo systemctl restart containerdDocker和containerd的生态差异主要体现在命令习惯上。以前用docker ps、docker logs现在换成了crictl ps、crictl logs但网络端口映射、exec进入容器这些思路是相通的上手成本并不高。2.3 网络模型与存储方案的前置选择网络方案必须在初始化前定好因为初始化时就要指定Pod网段。业界主流的CNI插件有Flannel和Calico企业级选型我习惯这样判断业务规模中等、没有复杂的网络策略需求用Flannel足够部署最简单性能也能满足大部分场景需要精细的网络策略控制比如按namespace或按应用出安全规则就选Calico。我这次用的是FlannelPod网段取10.244.0.0/16Service网段取10.96.0.0/12。强调一下这两个网段以及服务器本身的内网网段之间绝对不能重合否则路由直接冲突。存储方案同理要提前想好。有状态服务比如数据库需要持久化存储Pod删了数据不能丢。Kubernetes里的标准做法是PVPersistentVolume和PVCPersistentVolumeClaim运维准备存储研发声明需求。企业级环境通常会用共享存储比如NFS或者云环境里的CSI存储驱动。如果业务规模不大本地持久卷也能凑合但要注意它和节点强绑定节点故障数据就麻烦了。3. 基于kubeadm的企业级集群部署实操3.1 初始化前的系统准备正式执行kubeadm init之前有几项系统配置必须先完成不然初始化到一半会以各种姿势失败。第一关闭swap。Kubernetes对节点内存有硬性要求swap开启时kubelet无法正常工作kubeadm会直接拒绝初始化。执行swapoff -a并注释掉/etc/fstab里的swap挂载项保证重启后也不会自动开启。第二加载内核模块并调整网络参数。Kubernetes需要br_netfilter模块配合iptables处理桥接流量同时需要开启IP转发cat EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system第三安装kubeadm、kubelet、kubectl并锁定版本。我强烈建议三件套用完全相同的版本号避免版本错位导致兼容性问题。企业级集群稳定优先不要追最新版本选一个当前稳定分支的版本就好。装完记得用apt-mark hold之类的命令锁版本防止意外升级。3.2 控制面初始化的参数取舍控制面节点上执行初始化时参数不要凭感觉写。我这次使用的核心命令如下sudo kubeadm init \ --apiserver-advertise-address192.168.x.11 \ --pod-network-cidr10.244.0.0/16 \ --service-cidr10.96.0.0/12 \ --kubernetes-versionv1.28.2 \ --control-plane-endpoint192.168.x.10解释几个关键参数。apiserver-advertise-address是API Server对外通信的IP填写控制面节点自身的内网IP。pod-network-cidr是Pod网段必须和后续CNI插件配置匹配Flannel默认就是10.244.0.0/16所以我这里直接用默认值。service-cidr是Service的虚拟网段与Pod网段不能冲突。control-plane-endpoint在高可用场景下应指向负载均衡器的虚拟IP我这里单控制面暂时填了节点IP后续扩展成高可用时再调整。镜像问题在企业内网环境比较敏感。kubeadm默认从公共镜像源拉取镜像如果网络受限可以指定企业内部镜像仓库示例kubeadm config images pull --image-repository镜像仓库地址/前缀务必确保所有节点都能访问这个镜像源。初始化成功后会输出一段提示包括连接集群所需的kubeconfig配置命令以及工作节点加入集群的完整命令先复制保存好后面要用。3.3 工作节点接入与角色标签工作节点加入集群直接执行控制面初始化成功时输出的kubeadm join命令即可。命令里带一个token这个token默认有效期是24小时。如果过期了用下面命令重新生成sudo kubeadm token create --print-join-command加入完成后在控制面节点执行kubectl get nodes就能看到节点状态。工作节点加入时不需要重复执行init只需要有kubelet、kubeadm和containerd。节点加入后一时半会显示NotReady是正常的多半是网络插件还没装好这个问题在下一节处理。节点角色和用途标签可以在必要时手动指定。例如kubectl label node node-xxx node-role.kubernetes.io/worker。标签体系是后续做亲和性调度、故障域隔离的基础企业集群一旦超过10个节点建议规范所有节点标签避免后续排障时分不清机器用途。3.4 CNI网络插件落地网络插件是整个集群里最容易被忽略却最容易出问题的一环。Pod网段、Service网段、CNI插件的网段配置一旦对不上要么Pod一直Pending要么跨节点通信直接不通。Flannel的安装非常直接kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml这里要注意企业内网环境文件路径可能无法直接获取先下载文件再apply也是常见操作。安装完成后观察kube-system命名空间下的Pod状态kubectl get pods -n kube-system当所有Pod进入Running状态特别是coredns不再Pending时基本就说明网络通了。验证方式很直观调度到两个不同工作节点上各起一个测试Pod互相ping对方IP通则正常。如果Flannel启动失败最常见的原因是从节点没有同步配置或者Pod网段被占用删除kube-flannel.yml后重新apply即可不用重启集群。节点重装网络插件时我先kubeadm reset再重新join这样做最省心单纯重启kubelet往往不起作用。4. 企业级能力的落地弹性伸缩、持久化、流量入口4.1 启用Metrics Server与HPA自动扩缩容集群装好、节点Ready之后接下来要处理的就是弹性伸缩。HPA依赖Metrics Server采集Pod的CPU和内存使用率而Metrics Server需要单独部署。有些教程会把这一步省略导致HPA创建后一直无法获取指标。我这边是先安装Metrics Serverkubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml安装后可以执行kubectl top nodes看看指标是否正常如果报错说无法连接kubelet的10250端口通常是部署参数里缺少--kubelet-insecure-tls在components.yaml的Deployment参数里补上即可。HPA配置直接定义在工作负载旁边。以订单下单服务为例我给它的Pod设置了resources.requestsCPU请求量这是HPA计算使用率的分母。然后创建如下的HPA对象apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70这个配置的意思是当所有Pod的CPU平均使用率超过70%时HPA会逐步增加副本数上限10个低于70%一段时间后自动缩回下限3个。HPA默认的指标采集周期是15秒扩容决策每30秒评估一次所以流量高峰到来后大约一两分钟就能看到Pod数量上升。值得提醒的是不设置resources.requestsHPA算不出使用率对象会一直处于Unknown状态。另外HPA只管副本数量不管流量分发和故障恢复那是Service和Deployment的事别指望一个HPA解决所有问题。4.2 为有状态和无状态服务配置持久化存储没有持久化容器删除等于数据删除这对无状态服务没问题但订单系统的数据库、消息队列的存储节点绝对不能这样玩。Kubernetes里处理持久化的标准链路是StorageClass→PVC→PV。我选用的共享存储方案是给集群挂一套NFS。先部署NFS服务端然后安装NFS CSI驱动或直接使用NFS动态供给器创建一个StorageClassapiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-storage provisioner: example.com/nfs这里注意provisioner名称要和实际部署的供给器对应。StorageClass创建好之后应用侧只需声明PVCapiVersion: v1 kind: PersistentVolumeClaim metadata: name: order-db-data spec: storageClassName: nfs-storage accessModes: - ReadWriteMany resources: requests: storage: 20Gi当PVC创建后供给器会自动创建一个PV并绑定。应用Pod里通过volumeClaimTemplates或者volumes字段引用这个PVC数据就能在Pod重建后继续保留。访问模式这块要特别留意ReadWriteOnce的卷只能被同一个节点上的Pod使用ReadWriteMany才能跨节点共享。多副本部署同一份数据例如多个只读副本读同一个存储必须选ReadWriteMany如果用的是本地磁盘多副本场景下数据会不一致千万别这么干。4.3 业务流量入口的选型与Ingress落地集群搭好了服务跑起来了最后一个关键的环节是让外部请求能进来。Kubernetes里暴露服务有三种常见方式我整理成一张对比表暴露方式适用场景优点缺点NodePort测试环境、少量服务简单直接改Service即可端口数量有限端口管理混乱LoadBalancer公有云环境有云负载均衡器托管自建集群没有现成LB成本高Ingress企业级多服务场景按域名和路径路由复用入口需要额外部署Ingress Controller企业内部应用很多、域名也很多我直接放弃了NodePort方案。因为几十个服务如果每个都占用一个宿主机端口端口规划、安全组配置、调用方维护的成本会非常高。Ingress的做法是只暴露少数几个入口比如80和443然后根据请求的Host头和URL路径转发给对应的Service。我这边落地Ingress Controller用的是ingress-nginx。部署完成后给订单服务创建一条规则apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: order-ingress spec: rules: - host: order.example.internal http: paths: - path: /api pathType: Prefix backend: service: name: order-service port: number: 80这条规则把order.example.internal域名下的/api路径流量转发到order-service的80端口。HTTPS方面通过tls字段配置证书证书文件用Secret对象挂载这里不再展开。Ingress真正落地后流量路径是外部请求到Ingress Controller节点端口Controller解析规则后转发到对应ServiceService再分发到Pod。这也是企业级最常用的流量拓扑结构。5. 高频问题与排查手记5.1 初始化失败后的恢复流程kubeadm init失败是新手最常见的阻碍好消息是恢复流程足够简单不用重装系统。我先执行kubeadm reset它会清空所有初始化相关的配置和文件然后手动清理网络残留包括删除CNI插件生成的虚拟网卡和路由最后重新执行init。整个过程大概需要10分钟比瞎改参数来回折腾要高效得多。初始化的关键在于一次想清楚一次跑通。我之前有次踩坑是kubeadm join到一半发现控制面节点IP写错导致kubelet一直在等待证书签发。折腾半天之后发现还不如早一点reset再重新join来得干脆。5.2 节点一直NotReady的排查路径节点加入后一直NotReady我先不急着重启而是按顺序排查现象可能原因处理方式kubelet服务未启动或崩溃containerd运行时配置不对、cgroup驱动不一致重新配置containerd重点检查SystemdCgroup参数节点网络插件未ReadyCNI插件没装或版本不兼容确认Pod网段和插件配置一致重新applycoredns一直Pending网络插件未就绪或Pod卷挂载异常检查flannel Pod事件优先处理网络插件kube-system里有CrashLoopBackOff镜像拉取失败或配置错误describe Pod查看具体事件原因排查工具上我最常用的三条命令是kubectl get events --sort-by.lastTimestamp查看集群事件kubectl describe pod xxx -n kube-system看单个Pod的详细状态journalctl -u kubelet -f看kubelet日志。大多数节点异常在这三步之内都能定位到根因。5.3 证书过期与新增节点的注意事项Kubernetes的证书体系是集群安全的基础。用kubeadm部署的集群控制面证书默认有效期为一年这是很多人忽略的定时炸弹。建议在证书到期前两个月就检查kubeadm certs check-expiration如果快过期了非高可用集群可以执行kubeadm certs renew all来续期然后重启控制面组件。重要提醒续期之后旧证书会失效所有节点的kubelet连接都需要重新更新所以操作前确认维护窗口。新增节点时有两个问题最常见第一控制面和工作节点时间不同步证书校验直接失败求稳起见所有节点都要配置好时间同步第二join token过期临时生成token时为了防止加入过程的配置偏差最好在窗口期内一气呵成完成所有节点接入。5.4 长期维护中我坚持的几个习惯集群稳定运行之后最容易出问题的反而是人不是机器。我养成了几个习惯这里一并分享。所有部署用到的YAML文件必须进入版本管理集群的任何变更都先跑审查、再套模板、最后执行。这本质上是GitOps的思路能避免我也不知道这个配置是谁改的这种局面。每个namespace都设置资源配额。比如apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota spec: hard: requests.cpu: 4 requests.memory: 8Gi这一步把研发环境的资源上限提前卡死避免某个团队一次扩容把集群资源耗光。定期做灾难演练。别等真的出故障了才去查文档每月找一天模拟控制面节点宕机、工作节点下线、网络抖动这些常见故障把恢复流程走一遍。真正出问题的时候心里有底动作才不变形。这套集群在我这边的运行状态目前还很稳定。如果这篇内容能帮你在企业级Kubernetes落地的过程中少走几步弯路那我花费的这些时间就值了。