做Kubernetes运维这几年我最大的感受是网上教程一大堆但大部分都停留在“能用”的层面离“敢上生产”还有很长一段距离。很多人照着文档把集群搭起来了Pod也跑起来了结果遇到节点重启、证书过期、镜像拉不下来、网络插件和云厂商冲突这些事照样抓瞎。这篇文章就围绕Kubernetes集群从安装到生产部署这条线把我在实际运维中趟过的坑、验证过的方案、以及那些文档里不会写明白的判断逻辑一次说清楚。适合刚把K8s列入学习计划的新手也适合集群已经跑起来但总觉得不踏实的运维同学。文章里的操作步骤、参数配置都是我在真实环境里验证过的你可以直接照着抄但更重要的是理解每一步背后的为什么。1. 安装前先想清楚集群规划与版本选型1.1 硬件配置怎么定别等上了生产再后悔很多人在安装K8s之前第一个问题就是“需要几台机器”。这个真没有标准答案但有一个基本的判断逻辑看你的业务形态再看你的高可用要求。如果只是学习或者跑测试环境三台2核4G的虚拟机就够用了一台做控制平面两台做工作节点。但如果是生产环境我的建议是至少五台起步三台控制平面节点做高可用两台或以上的工作节点跑业务负载。控制平面节点规格不用太高4核8G在大多数场景下都够用因为真正消耗资源的是业务Pod和etcd工作节点就要根据业务实际需求来算了CPU、内存、磁盘都得预留至少30%的余量。这里的余量不是拍脑袋定的你总得给系统组件、监控采集、日志收集留出运行空间也要给突发流量和滚动更新时的资源峰值留足冗余。磁盘这块很多初次部署的人不重视我见过太多集群因为etcd所在磁盘性能太差导致整个APIServer响应变慢。etcd对磁盘延迟非常敏感生产环境务必要用SSD哪怕是云主机也要选择高性能云盘。工作节点上的容器运行目录也就是docker或containerd的数据目录同样建议独立挂载一块数据盘避免和系统盘抢占I/O资源也避免系统盘被写满后整个节点不可用。1.2 版本选型与容器运行时的选择版本选择这件事原则是“选新不选旧但别选最新”。Kubernetes的版本迭代速度很快每年三个大版本每个版本支持周期只有14个月左右。选版本的时候第一看你的业务组件对K8s API的兼容性第二看社区的主流使用情况第三看云厂商托管的版本。我个人的建议是在当前时间点选择社区已经发布半年以上、且还处于支持周期内的版本比如1.28、1.29、1.30这些系列。太新的版本比如刚发布不到一个月的尽量不要在生产环境用因为一些罕见的Bug和兼容性问题通常要等一两个补丁版本才会暴露出来。容器运行时方面Docker在1.24版本之后就被移除了对dockershim的支持所以现在新部署集群直接用containerd是主流做法。很多人习惯用Docker但containerd本身就是一个完整的容器运行时而且更轻量crictl命令虽然不像docker命令那么熟悉但用法很接近。kubeadm工具在初始化集群的时候会默认去检测containerd的运行状态如果你机器上装了Docker但也装了containerd记得提前确认好kubelet用的是哪个运行时接口。1.3 网络方案选型Calico还是Flannel网络插件是集群安装完之后的第一个关键决策点。Flannel和Calico是两种最常见的CNI插件但它们的定位完全不同。Flannel的特点是简单、轻量只提供三层网络互通也就是给每个Pod分配一个集群内IP让Pod之间能互相访问。但它没有网络策略能力也就是说你没法在集群层面做精细的访问控制。Calico的功能就丰富多了除了基本的Pod网络连通它还实现了完整的NetworkPolicy可以按命名空间、标签、IP段来做流量管控。如果你的集群要承载多租户业务或者有等保合规需求Calico基本是必选。代价是Calico的组件更多、运维复杂度更高比如它依赖BGP在某些数据封装模式下不依赖但默认的BGP模式确实需要来分发路由信息。我自己的实践是测试环境用Flannel足够了生产环境直接上Calico。如果你用的是云主机还要注意云厂商的安全组策略可能会拦截Calico的BGP端口通常是179这个坑在后面的疑难解答部分会细说。2. 用kubeadm从零搭建一套可用集群2.1 环境准备与组件安装细节这部分我先把基础环境的要求列出来这些前置条件不满足后面会有各种莫名其妙的问题。操作系统我推荐Ubuntu 22.04 LTS或CentOS 7.9/Stream 8如果你还在用CentOS系的话。内核版本至少在4.18以上建议5.x。主机名要规范最好用简短有意义的名称比如k8s-master01、k8s-node01因为主机名会写入节点的标签信息之后排查问题的时候一个清晰的主机名能省不少时间。所有节点都需要做以下配置关闭swap。K8s的kubelet默认要求禁用swap因为如果开启了swap内存回收机制会和容器的内存限制产生冲突导致Pod的内存QoS失效。永久关闭方法是修改/etc/fstab把swap那一行注释掉然后执行swapoff -a。加载内核模块和调整系统参数。需要开启overlay和br_netfilter模块否则容器网络通信会有问题。系统参数方面net.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward这几个是必须打开的这些参数保证iptables规则能正确作用于桥接流量也保证Pod的进出流量能正常转发。配置时间同步。生产环境强烈建议部署chrony或systemd-timesyncd因为Kubernetes的证书机制强依赖各节点时间的同步节点间时间偏差超过5分钟kubelet和APIServer之间的通信就会出现证书校验失败表现出来就是节点反复NotReady。组件安装很简单三件套kubeadm、kubelet、kubectl。用apt或yum安装的时候需要先配置K8s的软件源然后指定安装版本。这里有个小技巧安装的时候把三者版本锁定比如都用1.28.2避免自动升级导致版本不一致。2.2 初始化控制平面与工作节点加入控制平面节点执行初始化之前先准备好两个东西一个是apiserver-advertise-address也就是控制平面节点的内网IP另一个是pod-network-cidr这里是Pod的网段要提前规划好和你的VPC网段、Service网段都不能冲突。初始化命令我习惯写成这样kubeadm init \ --apiserver-advertise-address192.168.10.10 \ --image-repositoryregistry.aliyuncs.com/google_containers \ --kubernetes-versionv1.28.2 \ --service-cidr10.96.0.0/12 \ --pod-network-cidr10.244.0.0/16--image-repository参数很关键。默认情况下kubeadm会从registry.k8s.io拉取镜像这个地址在海外的CDN节点上国内网络环境经常拉不动。换成阿里云的镜像仓库后拉取速度会快很多。初始化成功后会输出一段join命令里面带着token和证书hash先复制保存好这个在节点加入集群的时候要用。然后按照输出提示把kubeconfig文件复制到当前用户的.kube目录下这样才能用kubectl操作集群。工作节点加入集群很简单就是把kubeadm init输出的kubeadm join命令在每台工作节点上执行一遍。如果token过期了可以在控制平面节点上执行kubeadm token create --print-join-command重新生成。集群所有节点都Join进来之后统一通过kubectl get nodes来确认节点状态。这里要注意一个现象节点状态是NotReady是正常的因为此时还没安装网络插件Pod网络是不通的。安装完CNI插件之后等一两分钟节点就会变成Ready。2.3 安装Calico网络插件Calico的安装其实是应用一堆YAML文件官方推荐的方式是从Calico的GitHub仓库下载manifests文件然后修改里面的Pod网段和你的初始化参数保持一致再kubectl apply -f应用。比如我上面规划的是10.244.0.0/16那么在calico.yaml里找到CALICO_IPV4POOL_CIDR变量的位置改成这个网段就行。如果你用的Pod网段和Calico的默认值不同这个不改的话后面Pod会一直拿不到IP。安装完之后通过kubectl get pods -n kube-system查看calico相关Pod都是Running状态再看节点状态应该就是Ready了。3. 核心概念与工作负载类型的生产解读3.1 Pod、Deployment、Service的关系这部分我给一个核心概念区分方便新手快速建立认知框架。Pod是Kubernetes调度的最小单元。一个Pod里可以有一个或多个容器它们共享网络命名空间、共享存储卷。很多人以为Pod等同于容器这个理解不准确。最典型的例子就是日志收集的Sidecar容器模式业务容器负责处理业务逻辑日志采集容器如filebeat、fluentd和它共享同一个Pod的存储卷这样业务容器只需把日志写到本地文件Sidecar容器就能把日志转发出去。这种“主容器辅助容器”的搭配正是Pod这个抽象层存在的意义。Deployment是用来管理无状态应用的控制器。你只需要声明“我要跑3个副本、每个副本用这个镜像、端口是8080”Deployment就会帮你创建ReplicaSet再由ReplicaSet创建出3个Pod。它还负责滚动更新升级镜像版本的时候新版本Pod一个一个起旧版本Pod一个一个杀整个过程对用户无感知。如果新的Pod启动失败Deployment会自动回滚到上一个版本。Service则是一个稳定的访问入口。Pod的IP是不固定的今天这个Pod挂了Deployment重新调度的Pod IP就变了。如果你直接通过Pod IP去访问业务那必然要出问题。Service做的事情就是给一组Pod提供一个固定的虚拟IPClusterIP并在它内部维护一个Endpoint列表新Pod上线、旧Pod下线Service会自动更新这个列表对外部来说始终是同一个可访问地址。3.2 配置管理ConfigMap和SecretConfigMap就是用来解耦配置和镜像的。最常见的场景是同一个镜像在不同的环境开发、测试、生产里连的数据库地址不一样数据库账号密码不一样。如果不引入ConfigMap你就得为每个环境打一个镜像这显然很低效。ConfigMap可以挂载成环境变量也可以挂载成文件。我个人的建议是如果配置内容是结构化的比如application.yml尽量用文件挂载的方式如果是简单键值对用环境变量更省事。这里有个细节要注意ConfigMap挂载成文件之后如果你更新了ConfigMap已经存在的Pod里的文件内容不会自动更新除非Pod重启。一些开源项目如nginx-ingress-controller会监听ConfigMap变化并自动reload配置但你自己写的业务应用不一定有这个能力。Secret的结构和ConfigMap类似但它保存的是敏感数据密码、证书、Token存储时做了Base64编码。要注意Base64并不是加密只是编码任何能访问集群的人都可以直接解码Secret。所以生产环境建议开启etcd加密存储或者用更专业的密钥管理方案比如Sealed Secrets这类把Secret加密后再存进Git里的工具。3.3 存储抽象PV和PVC有状态应用数据库、消息队列要持久化数据这就涉及到存储。Kubernetes里存储的抽象方式很绕但理解了之后会发现它是很优雅的。PVPersistentVolume是集群里的存储资源相当于一个存储池它可以是NFS、Ceph的存储卷、云厂商的云盘或者本地磁盘。PVCPersistentVolumeClaim是用户对存储资源的申请相当于你要从存储池里申请一块空间。Pod通过PVC来挂载存储而不需要关心具体的存储后端是什么。写PV的yaml时需要指定容量、访问模式ReadWriteOnce、ReadOnlyMany、ReadWriteMany、存储类和回收策略。生产环境推荐用动态存储供给的方式也就是StorageClass这样就不用手动创建PV了。每次创建PVC存储插件会自动从后端分配一块卷做完用完释放。云厂商一般都有专门的CSI插件接入它们的云盘服务比如阿里云有alicloud-disk腾讯云有cbs-csi。我自己踩过的一个存储坑是云盘的访问模式有严格的地域限制比如一块云盘只能被同一可用区的节点挂载。如果两个Pod副本被调度到了不同可用区的节点上它们就无法共享同一块云盘。所以在设计有状态应用或多副本读写的存储方案时一定要把可用区这个因素考虑进去。4. 从“能跑”到“敢上线”生产部署的硬门槛4.1 资源配额、健康检查与调度约束很多新手部署应用yaml里只写了镜像名和副本数这种部署方式在测试环境没问题但离生产要求差得很远。生产部署的第一道门槛就是必须写清楚资源requests和limits。requests是调度器做决策时看的它告诉调度器这个Pod至少需要多少资源limits是运行时限制超过这个值的CPU会被限流内存超了就会触发OOM Kill。不写requests的后果很严重调度器会认为这个Pod对资源“没要求”结果就是一堆Pod全被塞到一个节点上资源超卖严重的时候整台节点都可能被打挂。不写limits的后果是某些应用出现内存泄漏时它会无限吃内存直到把节点内存耗尽。这里我给一个经验值业务应用的内存limits一般设为requests的1.5到2倍但要结合实际业务来判断不能套公式。Java应用因为JVM自带堆内存管理内存limits要格外注意设置的比堆内存小会导致容器频繁被杀。健康检查是第二道门槛。readinessProbe就绪探针决定这个Pod要不要被放进Service的负载均衡池里livenessProbe存活探针决定容器要不要被重启。接口健康检查的URL、端口、初始延迟时间initialDelaySeconds这些参数都需要根据你的应用启动耗时来调整。启动慢的应用initialDelaySeconds一定要给足否则应用还没起来就被livenessProbe判定失败然后反复重启陷入CrashLoopBackOff的恶性循环。调度约束这块最常用的是nodeSelector和节点亲和性。比如你的业务对磁盘性能敏感就给SSD节点打上标签然后用nodeSelector指定业务Pod只能调度到这些节点上。还可以用PodAntiAffinity把同一应用的多个副本分散到不同节点这样能避免一台节点挂了所有副本都没了。4.2 接入层Ingress与证书自动化Service的ClusterIP只能在集群内部访问集群外的流量进来需要一个入口这就是Ingress做的事。Ingress本身是一个反向代理最常见的实现是nginx-ingress-controller和traefik。Ingress配置里最关键的是域名、访问路径和后端Service的对应关系。生产环境还会涉及到HTTPS证书的管理。人工更新证书是最容易出错的事证书忘了续期导致线上访问报安全错误这种事故大家应该都遇到过。推荐的做法是部署cert-manager来自动化证书管理。cert-manager配合Lets Encrypt每90天自动续期一次证书整个过程不需要人工干预。它的工作原理是创建Certificate资源cert-manager会去申请证书并在到期前自动续期然后把证书保存到同名的Secret里Ingress引用这个Secret即可。这里有一个坑要提醒cert-manager在验证域名所有权时会发起HTTP-01或DNS-01挑战HTTP-01挑战需要你的Ingress能从公网访问到相应的验证路径DNS-01挑战则需要在域名服务商那里配置API Token。如果域名解析在有NS记录的托管服务商那里建议直接走DNS-01兼容性更好也不依赖网络的入站状态。4.3 监控告警与日志收集体系设计集群上线了业务跑起来了接下来最重要的就是监控和日志。没有监控的集群就是盲人开车宕机了都不知道为什么。监控这块现在的主流方案是Prometheus Grafana。Prometheus采集集群指标节点CPU、内存、网络、Pod资源使用情况Grafana做可视化展示。kube-prometheus-stack这个Helm Chart会把Prometheus、Alertmanager、Grafana、各种Exporter一起打包部署适合快速落地。容器健康监控、节点资源监控、K8s组件监控在这个方案里都能覆盖。告警规则是很多人容易忽略的地方。建议至少配置下面几条基础告警节点状态为NotReady持续超过1分钟节点内存使用率超过85%持续5分钟Pod反复重启CrashLoopBackOff持续10分钟集群中大量Pod处于Pending状态etcd的leader切换次数异常。告警阈值要基于实际集群规模调整小集群和大集群的资源水位本来就不同阈值设得太敏感会产生告警疲劳团队慢慢就不看告警了最后真正的故障也没人响应。日志收集的生产方案基本上就是EFK或者Loki。EFK是Elasticsearch Fluentd Kibana功能强大但是Elasticsearch本身就很吃资源。Loki是Grafana出的解决方案日志不建立索引只做压缩存储查询时再用标签过滤资源消耗小得多。如果你的业务日志量不是特别大每天几个GB到几十个GB我推荐用Loki运维成本低很多。日志收集有个细节也不能疏忽一定要做日志轮转和生命周期管理。日志保留天数是按业务需求定的超过保留期的日志要自动清理或归档到冷存储否则磁盘空间被日志占满节点会陷入异常状态。4.4 用Dashboard发布一个全新服务的实操演示很多运维同学习惯了可视化界面操作这里就演示一下通过Kubernetes Dashboard把一个新的Deployment部署上线。Dashboard本身可以通过kubectl proxy访问生产环境建议用Ingress暴露并通过OIDC或RBAC做权限验证不要直接暴露到公网。假设我这边要发布一个基于nginx的web服务在Dashboard里的操作流程是进入Dashboard的“工作负载”页面点击“创建”按钮可以切换到一个简单的表单模式。表单模式里我要填写应用名web-demo、镜像地址nginx:1.25、副本数量3个副本。这里还要把高级选项里的资源配额limits和requests填上服务类型选择ClusterIP端口映射里填上容器端口80。提交之后Dashboard会自动帮你生成并应用Deployment和Service这两个资源。切换到“服务”页面能看到这个ClusterIP服务创建成功点进去能看到它关联的3个Pod都在Running状态。如果是用YAML方式对应的Deployment大概长这样apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: default spec: replicas: 3 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: memory: 64Mi cpu: 100m limits: memory: 128Mi cpu: 200mapiVersion: v1 kind: Service metadata: name: web-demo namespace: default spec: selector: app: web-demo ports: - port: 80 targetPort: 80最后还需要在Ingress里增加一条路由规则把web.example.com这个域名指向web-demo这个Service。这样一个新服务就完整发布上线了。初始的时候如果只做验证也可以先加一个临时隧道的svc类型NodePort从节点IP加端口直接访问确认Pod起来了再切Ingress。5. 踩过的坑与排查思路5.1 镜像拉取慢或完全拉不动这是新集群最普遍的问题。默认情况下kubelet从Docker Hub拉取镜像而Docker Hub在国内网络环境下时快时慢严重的时候直接超时。解决办法是给容器运行时配置镜像加速器。containerd的镜像加速配置在/etc/containerd/config.toml的[plugins.io.containerd.grpc.v1.cri.registry.mirrors]字段里。编辑好之后要重启containerd服务。这块有一个容易踩的坑修改config.toml之后如果不重启containerd配置不生效但重启containerd会导致当前节点上所有存量容器被杀掉所以生产环境最好找维护窗口操作或者分批滚动操作。业务镜像建议多使用云厂商的容器镜像服务比如把镜像推送到阿里云ACR、腾讯云TCR然后集群内从镜像仓库的内网地址拉取。这样既快又稳定还能配合镜像仓库的免密配置做权限管理。5.2 Pod一直Pending卡在ContainerCreatingPod卡在Pending首先看这个事件kubectl describe pod pod-name -n namespace事件信息会明确告诉你原因。最常见的几类没有满足条件的节点调度器找不到能容纳Pod的资源通常是cpu或内存的requests超过了所有可用节点的可分配资源。解决办法是扩容节点、清理无用Pod或者调低资源的requests配置。镜像拉取失败ImagePullBackOff原因多半是镜像地址写错了、镜像不存在或者镜像拉取的密钥没配。执行kubectl describe pod看事件里有没有401/403的提示就能判断是不是认证问题。PVC没有绑定到PV就是存储依赖不满足调度的前提条件导致Pod一直处于ContainerCreating状态。看事件里有没有waiting for PVC to be bound的相关提示如果有去排查PVC和PV的状态。Pod一直ContainerCreating还经常和网络插件的状态有关。Calico相关Pod如果没起来新建Pod的沙箱容器一直无法创建成功就会卡在ContainerCreating。先看kube-system里的Calico是否Running再查节点上是否有没清理干净的残留路由规则。5.3 kubelet证书过期Kubernetes各组件之间的通信全靠证书kubelet的证书默认有效期是一年。集群跑久了一年之后会突然出现kubectl get nodes能看到节点但kubectl logs、kubectl exec都失败的异常情况。原因就是kubelet的服务端证书过期了。如果集群的证书由kubeadm管理解决方式是在控制平面节点执行kubeadm certs renew all systemctl restart kubelet然后更新用户的kubeconfig文件。要注意的是kubeadm certs renew all只会续期证书不会重新生成CA证书所以整个流程不用重新初始化集群不影响已有的业务Pod。运维上强烈建议给证书过期加一个监控项提前30天告警。5.4 Calico BGP模式下的云主机安全组拦截问题Calico默认的IPIP模式需要节点间通过BGP协议交换路由信息BGP使用的TCP端口是179。在云主机上云平台的安全组默认不会放通这个端口导致各节点之间无法同步路由表现为集群内跨节点的Pod网络不通。这种问题的排查思路很清晰先通过calicoctl node status查看BGP peer的状态确认是不是Established如果不是就检查云平台安全组有没有放通179端口以及节点防火墙ufw、firewalld是否拦截。解决办法很简单在安全组里放通TCP 179端口即可。如果实在不想动安全组另一个办法是把Calico切换成VXLAN模式这种封装方式只需要UDP 4789端口通常云平台默认放通。写在最后的一些经验这套集群部署和运维的流程我前后在好几套环境里验证过测试环境、生产环境、私有化环境都有。最大的感受是K8s这套系统安装只是开始真正的运维挑战在后面。像镜像加速配置、证书过期、资源配额阈值、网络插件与云平台安全组的兼容性这些问题都不是装完集群就能发现的而是在业务运行一段时间后才慢慢暴露。所以我也越来越认同一个观点做K8s运维最重要的能力不是会敲几个命令而是能理解这套系统的设计逻辑知道它每一个抽象层要解决什么问题出了问题能顺着原理去排查而不是靠瞎试。最后再分享一个小技巧我每次搭建环境的时候都会把关键操作初始化命令、join命令、网络配置、证书续期命令整理成一个Cheat Sheet贴在笔记里同时配合定时巡检脚本把节点状态、证书过期时间、磁盘水位这些指标定期扫一遍。这样集群即使出问题也能通过巡检记录快速定位变更时间和异常节点比事后慢慢翻日志高效得多。
做Kubernetes运维这几年我最大的感受是网上教程一大堆但大部分都停留在“能用”的层面离“敢上生产”还有很长一段距离。很多人照着文档把集群搭起来了Pod也跑起来了结果遇到节点重启、证书过期、镜像拉不下来、网络插件和云厂商冲突这些事照样抓瞎。这篇文章就围绕Kubernetes集群从安装到生产部署这条线把我在实际运维中趟过的坑、验证过的方案、以及那些文档里不会写明白的判断逻辑一次说清楚。适合刚把K8s列入学习计划的新手也适合集群已经跑起来但总觉得不踏实的运维同学。文章里的操作步骤、参数配置都是我在真实环境里验证过的你可以直接照着抄但更重要的是理解每一步背后的为什么。1. 安装前先想清楚集群规划与版本选型1.1 硬件配置怎么定别等上了生产再后悔很多人在安装K8s之前第一个问题就是“需要几台机器”。这个真没有标准答案但有一个基本的判断逻辑看你的业务形态再看你的高可用要求。如果只是学习或者跑测试环境三台2核4G的虚拟机就够用了一台做控制平面两台做工作节点。但如果是生产环境我的建议是至少五台起步三台控制平面节点做高可用两台或以上的工作节点跑业务负载。控制平面节点规格不用太高4核8G在大多数场景下都够用因为真正消耗资源的是业务Pod和etcd工作节点就要根据业务实际需求来算了CPU、内存、磁盘都得预留至少30%的余量。这里的余量不是拍脑袋定的你总得给系统组件、监控采集、日志收集留出运行空间也要给突发流量和滚动更新时的资源峰值留足冗余。磁盘这块很多初次部署的人不重视我见过太多集群因为etcd所在磁盘性能太差导致整个APIServer响应变慢。etcd对磁盘延迟非常敏感生产环境务必要用SSD哪怕是云主机也要选择高性能云盘。工作节点上的容器运行目录也就是docker或containerd的数据目录同样建议独立挂载一块数据盘避免和系统盘抢占I/O资源也避免系统盘被写满后整个节点不可用。1.2 版本选型与容器运行时的选择版本选择这件事原则是“选新不选旧但别选最新”。Kubernetes的版本迭代速度很快每年三个大版本每个版本支持周期只有14个月左右。选版本的时候第一看你的业务组件对K8s API的兼容性第二看社区的主流使用情况第三看云厂商托管的版本。我个人的建议是在当前时间点选择社区已经发布半年以上、且还处于支持周期内的版本比如1.28、1.29、1.30这些系列。太新的版本比如刚发布不到一个月的尽量不要在生产环境用因为一些罕见的Bug和兼容性问题通常要等一两个补丁版本才会暴露出来。容器运行时方面Docker在1.24版本之后就被移除了对dockershim的支持所以现在新部署集群直接用containerd是主流做法。很多人习惯用Docker但containerd本身就是一个完整的容器运行时而且更轻量crictl命令虽然不像docker命令那么熟悉但用法很接近。kubeadm工具在初始化集群的时候会默认去检测containerd的运行状态如果你机器上装了Docker但也装了containerd记得提前确认好kubelet用的是哪个运行时接口。1.3 网络方案选型Calico还是Flannel网络插件是集群安装完之后的第一个关键决策点。Flannel和Calico是两种最常见的CNI插件但它们的定位完全不同。Flannel的特点是简单、轻量只提供三层网络互通也就是给每个Pod分配一个集群内IP让Pod之间能互相访问。但它没有网络策略能力也就是说你没法在集群层面做精细的访问控制。Calico的功能就丰富多了除了基本的Pod网络连通它还实现了完整的NetworkPolicy可以按命名空间、标签、IP段来做流量管控。如果你的集群要承载多租户业务或者有等保合规需求Calico基本是必选。代价是Calico的组件更多、运维复杂度更高比如它依赖BGP在某些数据封装模式下不依赖但默认的BGP模式确实需要来分发路由信息。我自己的实践是测试环境用Flannel足够了生产环境直接上Calico。如果你用的是云主机还要注意云厂商的安全组策略可能会拦截Calico的BGP端口通常是179这个坑在后面的疑难解答部分会细说。2. 用kubeadm从零搭建一套可用集群2.1 环境准备与组件安装细节这部分我先把基础环境的要求列出来这些前置条件不满足后面会有各种莫名其妙的问题。操作系统我推荐Ubuntu 22.04 LTS或CentOS 7.9/Stream 8如果你还在用CentOS系的话。内核版本至少在4.18以上建议5.x。主机名要规范最好用简短有意义的名称比如k8s-master01、k8s-node01因为主机名会写入节点的标签信息之后排查问题的时候一个清晰的主机名能省不少时间。所有节点都需要做以下配置关闭swap。K8s的kubelet默认要求禁用swap因为如果开启了swap内存回收机制会和容器的内存限制产生冲突导致Pod的内存QoS失效。永久关闭方法是修改/etc/fstab把swap那一行注释掉然后执行swapoff -a。加载内核模块和调整系统参数。需要开启overlay和br_netfilter模块否则容器网络通信会有问题。系统参数方面net.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward这几个是必须打开的这些参数保证iptables规则能正确作用于桥接流量也保证Pod的进出流量能正常转发。配置时间同步。生产环境强烈建议部署chrony或systemd-timesyncd因为Kubernetes的证书机制强依赖各节点时间的同步节点间时间偏差超过5分钟kubelet和APIServer之间的通信就会出现证书校验失败表现出来就是节点反复NotReady。组件安装很简单三件套kubeadm、kubelet、kubectl。用apt或yum安装的时候需要先配置K8s的软件源然后指定安装版本。这里有个小技巧安装的时候把三者版本锁定比如都用1.28.2避免自动升级导致版本不一致。2.2 初始化控制平面与工作节点加入控制平面节点执行初始化之前先准备好两个东西一个是apiserver-advertise-address也就是控制平面节点的内网IP另一个是pod-network-cidr这里是Pod的网段要提前规划好和你的VPC网段、Service网段都不能冲突。初始化命令我习惯写成这样kubeadm init \ --apiserver-advertise-address192.168.10.10 \ --image-repositoryregistry.aliyuncs.com/google_containers \ --kubernetes-versionv1.28.2 \ --service-cidr10.96.0.0/12 \ --pod-network-cidr10.244.0.0/16--image-repository参数很关键。默认情况下kubeadm会从registry.k8s.io拉取镜像这个地址在海外的CDN节点上国内网络环境经常拉不动。换成阿里云的镜像仓库后拉取速度会快很多。初始化成功后会输出一段join命令里面带着token和证书hash先复制保存好这个在节点加入集群的时候要用。然后按照输出提示把kubeconfig文件复制到当前用户的.kube目录下这样才能用kubectl操作集群。工作节点加入集群很简单就是把kubeadm init输出的kubeadm join命令在每台工作节点上执行一遍。如果token过期了可以在控制平面节点上执行kubeadm token create --print-join-command重新生成。集群所有节点都Join进来之后统一通过kubectl get nodes来确认节点状态。这里要注意一个现象节点状态是NotReady是正常的因为此时还没安装网络插件Pod网络是不通的。安装完CNI插件之后等一两分钟节点就会变成Ready。2.3 安装Calico网络插件Calico的安装其实是应用一堆YAML文件官方推荐的方式是从Calico的GitHub仓库下载manifests文件然后修改里面的Pod网段和你的初始化参数保持一致再kubectl apply -f应用。比如我上面规划的是10.244.0.0/16那么在calico.yaml里找到CALICO_IPV4POOL_CIDR变量的位置改成这个网段就行。如果你用的Pod网段和Calico的默认值不同这个不改的话后面Pod会一直拿不到IP。安装完之后通过kubectl get pods -n kube-system查看calico相关Pod都是Running状态再看节点状态应该就是Ready了。3. 核心概念与工作负载类型的生产解读3.1 Pod、Deployment、Service的关系这部分我给一个核心概念区分方便新手快速建立认知框架。Pod是Kubernetes调度的最小单元。一个Pod里可以有一个或多个容器它们共享网络命名空间、共享存储卷。很多人以为Pod等同于容器这个理解不准确。最典型的例子就是日志收集的Sidecar容器模式业务容器负责处理业务逻辑日志采集容器如filebeat、fluentd和它共享同一个Pod的存储卷这样业务容器只需把日志写到本地文件Sidecar容器就能把日志转发出去。这种“主容器辅助容器”的搭配正是Pod这个抽象层存在的意义。Deployment是用来管理无状态应用的控制器。你只需要声明“我要跑3个副本、每个副本用这个镜像、端口是8080”Deployment就会帮你创建ReplicaSet再由ReplicaSet创建出3个Pod。它还负责滚动更新升级镜像版本的时候新版本Pod一个一个起旧版本Pod一个一个杀整个过程对用户无感知。如果新的Pod启动失败Deployment会自动回滚到上一个版本。Service则是一个稳定的访问入口。Pod的IP是不固定的今天这个Pod挂了Deployment重新调度的Pod IP就变了。如果你直接通过Pod IP去访问业务那必然要出问题。Service做的事情就是给一组Pod提供一个固定的虚拟IPClusterIP并在它内部维护一个Endpoint列表新Pod上线、旧Pod下线Service会自动更新这个列表对外部来说始终是同一个可访问地址。3.2 配置管理ConfigMap和SecretConfigMap就是用来解耦配置和镜像的。最常见的场景是同一个镜像在不同的环境开发、测试、生产里连的数据库地址不一样数据库账号密码不一样。如果不引入ConfigMap你就得为每个环境打一个镜像这显然很低效。ConfigMap可以挂载成环境变量也可以挂载成文件。我个人的建议是如果配置内容是结构化的比如application.yml尽量用文件挂载的方式如果是简单键值对用环境变量更省事。这里有个细节要注意ConfigMap挂载成文件之后如果你更新了ConfigMap已经存在的Pod里的文件内容不会自动更新除非Pod重启。一些开源项目如nginx-ingress-controller会监听ConfigMap变化并自动reload配置但你自己写的业务应用不一定有这个能力。Secret的结构和ConfigMap类似但它保存的是敏感数据密码、证书、Token存储时做了Base64编码。要注意Base64并不是加密只是编码任何能访问集群的人都可以直接解码Secret。所以生产环境建议开启etcd加密存储或者用更专业的密钥管理方案比如Sealed Secrets这类把Secret加密后再存进Git里的工具。3.3 存储抽象PV和PVC有状态应用数据库、消息队列要持久化数据这就涉及到存储。Kubernetes里存储的抽象方式很绕但理解了之后会发现它是很优雅的。PVPersistentVolume是集群里的存储资源相当于一个存储池它可以是NFS、Ceph的存储卷、云厂商的云盘或者本地磁盘。PVCPersistentVolumeClaim是用户对存储资源的申请相当于你要从存储池里申请一块空间。Pod通过PVC来挂载存储而不需要关心具体的存储后端是什么。写PV的yaml时需要指定容量、访问模式ReadWriteOnce、ReadOnlyMany、ReadWriteMany、存储类和回收策略。生产环境推荐用动态存储供给的方式也就是StorageClass这样就不用手动创建PV了。每次创建PVC存储插件会自动从后端分配一块卷做完用完释放。云厂商一般都有专门的CSI插件接入它们的云盘服务比如阿里云有alicloud-disk腾讯云有cbs-csi。我自己踩过的一个存储坑是云盘的访问模式有严格的地域限制比如一块云盘只能被同一可用区的节点挂载。如果两个Pod副本被调度到了不同可用区的节点上它们就无法共享同一块云盘。所以在设计有状态应用或多副本读写的存储方案时一定要把可用区这个因素考虑进去。4. 从“能跑”到“敢上线”生产部署的硬门槛4.1 资源配额、健康检查与调度约束很多新手部署应用yaml里只写了镜像名和副本数这种部署方式在测试环境没问题但离生产要求差得很远。生产部署的第一道门槛就是必须写清楚资源requests和limits。requests是调度器做决策时看的它告诉调度器这个Pod至少需要多少资源limits是运行时限制超过这个值的CPU会被限流内存超了就会触发OOM Kill。不写requests的后果很严重调度器会认为这个Pod对资源“没要求”结果就是一堆Pod全被塞到一个节点上资源超卖严重的时候整台节点都可能被打挂。不写limits的后果是某些应用出现内存泄漏时它会无限吃内存直到把节点内存耗尽。这里我给一个经验值业务应用的内存limits一般设为requests的1.5到2倍但要结合实际业务来判断不能套公式。Java应用因为JVM自带堆内存管理内存limits要格外注意设置的比堆内存小会导致容器频繁被杀。健康检查是第二道门槛。readinessProbe就绪探针决定这个Pod要不要被放进Service的负载均衡池里livenessProbe存活探针决定容器要不要被重启。接口健康检查的URL、端口、初始延迟时间initialDelaySeconds这些参数都需要根据你的应用启动耗时来调整。启动慢的应用initialDelaySeconds一定要给足否则应用还没起来就被livenessProbe判定失败然后反复重启陷入CrashLoopBackOff的恶性循环。调度约束这块最常用的是nodeSelector和节点亲和性。比如你的业务对磁盘性能敏感就给SSD节点打上标签然后用nodeSelector指定业务Pod只能调度到这些节点上。还可以用PodAntiAffinity把同一应用的多个副本分散到不同节点这样能避免一台节点挂了所有副本都没了。4.2 接入层Ingress与证书自动化Service的ClusterIP只能在集群内部访问集群外的流量进来需要一个入口这就是Ingress做的事。Ingress本身是一个反向代理最常见的实现是nginx-ingress-controller和traefik。Ingress配置里最关键的是域名、访问路径和后端Service的对应关系。生产环境还会涉及到HTTPS证书的管理。人工更新证书是最容易出错的事证书忘了续期导致线上访问报安全错误这种事故大家应该都遇到过。推荐的做法是部署cert-manager来自动化证书管理。cert-manager配合Lets Encrypt每90天自动续期一次证书整个过程不需要人工干预。它的工作原理是创建Certificate资源cert-manager会去申请证书并在到期前自动续期然后把证书保存到同名的Secret里Ingress引用这个Secret即可。这里有一个坑要提醒cert-manager在验证域名所有权时会发起HTTP-01或DNS-01挑战HTTP-01挑战需要你的Ingress能从公网访问到相应的验证路径DNS-01挑战则需要在域名服务商那里配置API Token。如果域名解析在有NS记录的托管服务商那里建议直接走DNS-01兼容性更好也不依赖网络的入站状态。4.3 监控告警与日志收集体系设计集群上线了业务跑起来了接下来最重要的就是监控和日志。没有监控的集群就是盲人开车宕机了都不知道为什么。监控这块现在的主流方案是Prometheus Grafana。Prometheus采集集群指标节点CPU、内存、网络、Pod资源使用情况Grafana做可视化展示。kube-prometheus-stack这个Helm Chart会把Prometheus、Alertmanager、Grafana、各种Exporter一起打包部署适合快速落地。容器健康监控、节点资源监控、K8s组件监控在这个方案里都能覆盖。告警规则是很多人容易忽略的地方。建议至少配置下面几条基础告警节点状态为NotReady持续超过1分钟节点内存使用率超过85%持续5分钟Pod反复重启CrashLoopBackOff持续10分钟集群中大量Pod处于Pending状态etcd的leader切换次数异常。告警阈值要基于实际集群规模调整小集群和大集群的资源水位本来就不同阈值设得太敏感会产生告警疲劳团队慢慢就不看告警了最后真正的故障也没人响应。日志收集的生产方案基本上就是EFK或者Loki。EFK是Elasticsearch Fluentd Kibana功能强大但是Elasticsearch本身就很吃资源。Loki是Grafana出的解决方案日志不建立索引只做压缩存储查询时再用标签过滤资源消耗小得多。如果你的业务日志量不是特别大每天几个GB到几十个GB我推荐用Loki运维成本低很多。日志收集有个细节也不能疏忽一定要做日志轮转和生命周期管理。日志保留天数是按业务需求定的超过保留期的日志要自动清理或归档到冷存储否则磁盘空间被日志占满节点会陷入异常状态。4.4 用Dashboard发布一个全新服务的实操演示很多运维同学习惯了可视化界面操作这里就演示一下通过Kubernetes Dashboard把一个新的Deployment部署上线。Dashboard本身可以通过kubectl proxy访问生产环境建议用Ingress暴露并通过OIDC或RBAC做权限验证不要直接暴露到公网。假设我这边要发布一个基于nginx的web服务在Dashboard里的操作流程是进入Dashboard的“工作负载”页面点击“创建”按钮可以切换到一个简单的表单模式。表单模式里我要填写应用名web-demo、镜像地址nginx:1.25、副本数量3个副本。这里还要把高级选项里的资源配额limits和requests填上服务类型选择ClusterIP端口映射里填上容器端口80。提交之后Dashboard会自动帮你生成并应用Deployment和Service这两个资源。切换到“服务”页面能看到这个ClusterIP服务创建成功点进去能看到它关联的3个Pod都在Running状态。如果是用YAML方式对应的Deployment大概长这样apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: default spec: replicas: 3 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: memory: 64Mi cpu: 100m limits: memory: 128Mi cpu: 200mapiVersion: v1 kind: Service metadata: name: web-demo namespace: default spec: selector: app: web-demo ports: - port: 80 targetPort: 80最后还需要在Ingress里增加一条路由规则把web.example.com这个域名指向web-demo这个Service。这样一个新服务就完整发布上线了。初始的时候如果只做验证也可以先加一个临时隧道的svc类型NodePort从节点IP加端口直接访问确认Pod起来了再切Ingress。5. 踩过的坑与排查思路5.1 镜像拉取慢或完全拉不动这是新集群最普遍的问题。默认情况下kubelet从Docker Hub拉取镜像而Docker Hub在国内网络环境下时快时慢严重的时候直接超时。解决办法是给容器运行时配置镜像加速器。containerd的镜像加速配置在/etc/containerd/config.toml的[plugins.io.containerd.grpc.v1.cri.registry.mirrors]字段里。编辑好之后要重启containerd服务。这块有一个容易踩的坑修改config.toml之后如果不重启containerd配置不生效但重启containerd会导致当前节点上所有存量容器被杀掉所以生产环境最好找维护窗口操作或者分批滚动操作。业务镜像建议多使用云厂商的容器镜像服务比如把镜像推送到阿里云ACR、腾讯云TCR然后集群内从镜像仓库的内网地址拉取。这样既快又稳定还能配合镜像仓库的免密配置做权限管理。5.2 Pod一直Pending卡在ContainerCreatingPod卡在Pending首先看这个事件kubectl describe pod pod-name -n namespace事件信息会明确告诉你原因。最常见的几类没有满足条件的节点调度器找不到能容纳Pod的资源通常是cpu或内存的requests超过了所有可用节点的可分配资源。解决办法是扩容节点、清理无用Pod或者调低资源的requests配置。镜像拉取失败ImagePullBackOff原因多半是镜像地址写错了、镜像不存在或者镜像拉取的密钥没配。执行kubectl describe pod看事件里有没有401/403的提示就能判断是不是认证问题。PVC没有绑定到PV就是存储依赖不满足调度的前提条件导致Pod一直处于ContainerCreating状态。看事件里有没有waiting for PVC to be bound的相关提示如果有去排查PVC和PV的状态。Pod一直ContainerCreating还经常和网络插件的状态有关。Calico相关Pod如果没起来新建Pod的沙箱容器一直无法创建成功就会卡在ContainerCreating。先看kube-system里的Calico是否Running再查节点上是否有没清理干净的残留路由规则。5.3 kubelet证书过期Kubernetes各组件之间的通信全靠证书kubelet的证书默认有效期是一年。集群跑久了一年之后会突然出现kubectl get nodes能看到节点但kubectl logs、kubectl exec都失败的异常情况。原因就是kubelet的服务端证书过期了。如果集群的证书由kubeadm管理解决方式是在控制平面节点执行kubeadm certs renew all systemctl restart kubelet然后更新用户的kubeconfig文件。要注意的是kubeadm certs renew all只会续期证书不会重新生成CA证书所以整个流程不用重新初始化集群不影响已有的业务Pod。运维上强烈建议给证书过期加一个监控项提前30天告警。5.4 Calico BGP模式下的云主机安全组拦截问题Calico默认的IPIP模式需要节点间通过BGP协议交换路由信息BGP使用的TCP端口是179。在云主机上云平台的安全组默认不会放通这个端口导致各节点之间无法同步路由表现为集群内跨节点的Pod网络不通。这种问题的排查思路很清晰先通过calicoctl node status查看BGP peer的状态确认是不是Established如果不是就检查云平台安全组有没有放通179端口以及节点防火墙ufw、firewalld是否拦截。解决办法很简单在安全组里放通TCP 179端口即可。如果实在不想动安全组另一个办法是把Calico切换成VXLAN模式这种封装方式只需要UDP 4789端口通常云平台默认放通。写在最后的一些经验这套集群部署和运维的流程我前后在好几套环境里验证过测试环境、生产环境、私有化环境都有。最大的感受是K8s这套系统安装只是开始真正的运维挑战在后面。像镜像加速配置、证书过期、资源配额阈值、网络插件与云平台安全组的兼容性这些问题都不是装完集群就能发现的而是在业务运行一段时间后才慢慢暴露。所以我也越来越认同一个观点做K8s运维最重要的能力不是会敲几个命令而是能理解这套系统的设计逻辑知道它每一个抽象层要解决什么问题出了问题能顺着原理去排查而不是靠瞎试。最后再分享一个小技巧我每次搭建环境的时候都会把关键操作初始化命令、join命令、网络配置、证书续期命令整理成一个Cheat Sheet贴在笔记里同时配合定时巡检脚本把节点状态、证书过期时间、磁盘水位这些指标定期扫一遍。这样集群即使出问题也能通过巡检记录快速定位变更时间和异常节点比事后慢慢翻日志高效得多。
