Kubernetes实战指南：从声明式API到控制器与流量链路

网上关于 Kubernetes 的学习资料用“汗牛充栋”来形容一点都不夸张。“从入门到精通”这个说法大概也是被各种课程和文档用到近乎麻木了。但说实话我见过的大多数人实际走的路线都是“从入门到放弃”收藏了一堆教程跟着装好了集群结果工作负载一直 PendingService 写好了外部就是访问不到想查个日志发现根本不知道从哪里下手。如果让我用一句话重新概括 K8s我不会说它是一个“容器编排平台”——那是写 PPT 用的定义。真正用起来你会发现它更像一台以 API 为中枢的分布式操作系统调度、网络、存储、配置、权限、健康检查、滚动发布所有事都被抽象成一组对象再由一套控制逻辑不停地让现实状态向期望状态靠拢。理解了这一层后面所有内容都顺了。这篇文章我打算按一条比较完整的路线来讲从动手之前的认知准备到亲手搭起最小集群再到控制器、流量链路、可观测性和存储配置这些生产化主题。不追求百科全书式的全面但保证每个环节都能落地。适合两类人一类是被各种缩写搞得晕头转向的初学者另一类是已经用 Docker 跑过一些服务但始终没弄明白 Pod、Service、控制器之间到底怎么协作的朋友。1. 先想清楚再动手K8s 的边界、心智模型与学习路线1.1 容器帮你解决了打包却没解决调度很多人学 K8s 的第一步是直接去背概念我觉得这是最浪费时间的方式。你不如先问一个问题Docker 已经很好用了为什么还要一个更复杂的东西原因其实很朴素。Docker 解决的是“怎么把一个应用连同环境一起打包、在一台机器上跑起来”的问题。但一旦你的服务数量上来了事情就变味了多个服务分别跑在哪台机器上某个节点挂了上面的容器谁来迁移流量来了请求该转发到哪个容器配置变了怎么批量更新这些都不是 Docker 单机命令能回答的问题。换句话说容器只是标准化的货运箱而 K8s 是那个负责调度、装卸、维护整个港口的系统。所以我在看一个团队该不该上 K8s 时标准非常简单如果你的服务就两三个用 Docker Compose 能跑得很舒服那完全没有必要上。但如果你有五六十个服务、需要多副本、需要根据负载动态伸缩、需要频繁发布和回滚那这套系统的价值就体现出来了。它把“运维一台服务器”的思维方式彻底切换成“维护一组描述性对象”的思维方式。1.2 声明式 API如何让系统自己收敛到目标状态理解了 K8s 要解决的问题接下来必须接受一个核心认知K8s 是声明式的。这可能是从传统运维转过来时最难掰过来的一道坎。传统运维里我们的思路是命令式的先装包再改配置再启动服务再检查状态。每一步都是动词。声明式模型则完全不同你不再关心“怎么做”只描述“最终应该是什么样”。你想让某个应用保持 10 个副本就提交一个包含“replicas: 10”的描述文件系统自己会去比对当前实际副本数少于 10 就创建多了就销毁容器崩溃了它会在其他地方重新拉起来。这个“描述最终状态”的文件在 K8s 里叫声明式配置通常用 YAML 表达。你会反复看到这种套路把 YAML 提交给 API Server然后什么都不用做系统自己会想方设法满足它。刚开始这样做会觉得不踏实总想手动干预但当你看到某个节点宕机后、调度器自动在另一台机器上把副本补齐时你就会明白这种模型的可怕之处——运维工作从“亲自动手”变成了“定义规则并审核规则的执行结果”。1.3 需要哪些前置知识以及一条不会劝退的学习路线在动手之前我建议你先盘点一下基础。至少需要四样东西Linux 基础操作会看日志、会用 systemctl、懂一点文件权限。网络基础明白 IP、端口、DNS 是怎么回事最好对子网和路由有一点概念。容器基本使用至少亲手构建和运行过一个镜像。YAML 语法能看懂缩进和键值对就行不要求背。如果你的网络基础比较薄弱也不用怕但补课是必要的。K8s 里大量排错最后都会落到网络的某个环节上。至于学习路线我比较推荐“先搭一个最小集群再回头学概念”而不是先啃完理论再上手。原因很简单概念太多单靠记忆很难建立关联。一旦你亲手把一个集群跑起来了再看 Pod、Deployment 这些对象时脑子里会有真实画面。整个路线可以浓缩成五步搭集群 → 跑无状态应用 → 深入控制器与发布机制 → 打通服务流量 → 加存储和配置最后再做可观测性和权限治理。2. 最小集群的诞生记kubeadm 部署与三个高频拦路虎2.1 部署流程速览从初始化到节点加入现在动手。我建议用 kubeadm这是目前最主流也最适合学习的部署方式。你需要至少两台虚机一台做控制节点一台做工作节点规格不用高2 核 4G 足够。操作系统选 Ubuntu 或者 CentOS 都行注意系统时间要同步最好关掉 swap有些版本不关 swap 会直接导致 kubelet 状态异常。整个过程大致是这样# 控制节点上执行初始化指定 Pod 网段 kubeadm init --pod-network-cidr10.244.0.0/16 # 初始化完成后配置 kubectl mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config初始化完成后控制台会输出一条 join 命令把工作节点加入进来kubeadm join 控制节点IP:6443 --token token --discovery-token-ca-cert-hash hash这一步看起来简单但实际执行时你会遇到不少问题。最典型的有两类第一类是镜像拉不下来导致 kubeadm init 卡住这时可以指定一个可访问的镜像仓库例如把 kubeadm 的镜像源换成可用仓库第二类是 join 成功后kubectl get nodes 里工作节点还是 NotReady。这里我必须强调一个容易忽略的细节kubeadm、kubelet、kubectl 这三个工具的版本号最好保持一致或者不要相差超过一个小版本。版本不一致经常引发各种莫名奇妙的问题而这些问题在日志里通常表现得特别隐晦。2.2 CNI 选型不同插件背后的权衡节点 join 进来以后还需要装一个 CNI 插件否则 Pod 之间无法通信。这个选择直接影响集群的网络能力值得认真对待。我画过一张简单的对比表可以帮你快速做决策CNI 插件网络模型网络策略性能与运维成本适合场景Flannel简单 overlay不支持部署最简单性能一般学习、内部验证环境CalicoBGP 路由支持部署稍复杂资源占用较高性能好生产环境主力选择CiliumeBPF支持对内核版本有要求可观测性极强对性能和观测要求高的新集群我第一次搭集群时用的是 Flannel因为网上教程多。后来上了生产发现需要按命名空间隔离流量才把核心集群迁到了 Calico。这里有个经验如果你的集群规模以后会超过几十个节点或者明确要做多租户隔离直接从 Calico 起步会更省心Flannel 简单是简单但网络策略缺失这件事后期会卡脖子。2.3 节点 NotReady 的三类根因与排查思路节点 NotReady 是最常见的“第一道坎”。很多人这时候就慌了其实排查思路非常线性先看 kubelet再看容器运行时最后看 CNI。第一条命令永远是systemctl status kubelet journalctl -u kubelet -f日志里如果出现 cgroup 相关的报错那多半是 kubelet 和容器运行时的 cgroup 驱动不一致。比如容器运行时配置成了 systemd而 kubelet 用的还是 cgroupfs两个驱动对资源的管理方式不同节点就无法稳定上报状态。解决办法是打开容器运行时配置文件把 systemd_cgroup 设为 true并保持 kubelet 启动参数里的--cgroup-driversystemd一致。还有一种情况是日志里没有明显报错但你发现 node 上始终起不来任何 Pod这就要看 CNI 了。最常见的问题是/opt/cni/bin目录下缺少二进制插件或者 CNI 配置文件的网段和kubeadm init时指定的--pod-network-cidr不一致。我在一个项目里遇到过控制节点上有个 Pod 一直 ContainerCreatingdescribe 之后发现是 sandbox 镜像拉取失败。这类问题的通用排错套路是固定的kubectl describe pod pod-name -n namespace kubectl logs pod-name -n namespace --previous kubectl get events --sort-by.lastTimestamp记住一个原则K8s 的所有异常几乎都会留下事件和日志你缺的只是花十分钟看一眼的耐心。3. 控制器才是灵魂Pod、Deployment 的自愈与发布机制3.1 从 ReplicaSet 看“期望状态”如何被强制执行集群跑起来以后接下来一定要把控制器机制弄明白。因为这是 K8s 和普通容器管理工具最本质的区别。你平时接触最多的 Deployment实际上管理着一层叫 ReplicaSet 的中间对象而真正负责跑副本的是 Pod。为什么中间要多这一层想象一下你发布新版本的时候新旧版本交替如果 Deployment 直接管理 Pod它根本无法同时维护两套 Pod 的版本并协调切换顺序。有了 ReplicaSet你可以把每个版本对应一个独立的 ReplicaSet新版本逐渐扩旧版本逐渐缩回滚的时候再反过来。这层抽象让“发布”和“回滚”都变成了普通地调节副本数。控制器的执行逻辑也很像一个恒温器设定目标温度期望状态不断读取室温当前状态计算差值然后决定开热风还是开冷风。K8s 里各种 controller 做的就是这件事它们持续通过 API Server 监听资源变化发现实际状态和声明状态有偏差就去执行操作直到偏差消失。这也是为什么我们说 K8s 是“自愈”的——不是因为它有玄学智能而是控制器循环在背后一刻不停地干活。3.2 Pod 生命周期里那些“看不见”的探针与优雅退出一旦你开始管理真实业务Pod 的“健康”概念就变得特别重要。K8s 提供了三种探针我建议哪怕记不住名字也要记住它们的用途。探针探的是什么失败时后果livenessProbe容器还活着吗重启容器readinessProbe容器能接收流量吗从 Service 后端摘除startupProbe启动完成了吗保护启动慢的容器我举个例子帮你理解。假设你有一个 Java 应用启动需要两分钟但 livenessProbe 每 10 秒探测一次连续三次失败它就觉得容器“死了”直接重启。结果就是应用永远在启动-重启-再启动的循环里。这时候就要加一个 startupProbe告诉系统前两分钟属于启动期先别用 liveness 来判断死活。和探针同样重要的是优雅退出。Pod 被删除时kubelet 会给容器发 SIGTERM 信号等 30 秒默认值再发 SIGKILL。如果你的应用能正确处理 SIGTERM就能在这 30 秒内完成收尾。但很多应用框架对 SIGTERM 处理得不好这时候就需要在 Pod 里配置preStop钩子在收到删除指令后先执行一段脚本比如调用注册中心的下线接口再 sleep 几秒给流量切换留出时间。我在生产环境见过太多“发布时偶发 502”的案例最后都是靠这套组合拳解决的。3.3 滚动更新与回滚的参数艺术Deployment 的滚动更新有两个参数容易被忽略maxSurge和maxUnavailable。它们控制更新过程中的“节奏”。默认情况下更新时会允许暂时多出期望副本数的 25% 作为缓冲同时允许 25% 的旧副本先不可用。这个默认配置对大多数无状态应用是合适的但如果你对可用性特别敏感比如只能接受 100% 在线那就应该把maxUnavailable设成 0maxSurge设成 1保证先起新 Pod确认它 ready 之后再停掉旧 Pod。我记得有一个项目上线时因为数据库迁移脚本正好在更新窗口里跑新 Pod 起不来又不会立刻缩减旧 Pod 导致有段时间流量全断。之后我们就把关键服务的发布策略改成了“先扩容再缩容”加上了完整的 readiness 探针出自那次之后发布事故率降了一大截。滚动更新的本质是用小步慢跑换取风险可控这比一次性杀掉全部旧副本再创建新副本要稳得多。4. 流量进入集群的三层通路Service、kube-proxy 与 Ingress4.1 ClusterIP / NodePort / LoadBalancer 该怎么选集群内部跑起来的应用天然是动态的Pod 会被调度到任意节点IP 会随重建而变。所以 K8s 抽象出了 Service用一个固定的虚拟 IP 代表一组 Pod。Service 和 Pod 之间靠标签选择器连接后端列表由 Endpoints 对象动态维护。Service 最常见的三种类型我做了个对比类型作用范围实际用途ClusterIP集群内部服务间调用基本形态NodePort集群外部临时对外暴露、测试、非云环境LoadBalancer云环境外部通过云负载均衡器把流量送到集群初学者最容易犯的错是把 NodePort 当成生产环境的主要对外方式。NodePort 的端口范围有限还会把宿主机端口直接暴露出去管理起来很麻烦。在云上应该优先用 LoadBalancer在私有环境可以借助一些开源方案来实现类似效果。ClusterIP 则是基础中的基础你内部的微服务互相调用几乎全走的是 ClusterIP 或 DNS 名称。4.2 kube-proxy 的三代数据路径iptables、IPVS 与性能权衡Service 的虚拟 IP 本身不干活真正干活的是每个节点上的 kube-proxy 组件。它负责把发往虚拟 IP 的流量转发到真实的 Pod。kube-proxy 有三种转发模式。最老的是 userspace 模式性能太差已经过时。默认且最常用的是 iptables 模式它靠内核态规则做 DNAT实现简单、足够稳定但当集群里 Service 数量上千时iptables 规则会变得极其庞大更新规则时的延迟就会比较明显。第三种是 IPVS 模式它用内核里的 IP 虚拟服务器做负载均衡查询是哈希而不是遍历规则性能和扩展性都好得多。有经验的运维会在部署集群时直接启用 IPVS 模式。但要注意IPVS 依赖内核模块ip_vs以及相关扩展模块节点上需要预先加载否则 kube-proxy 会默默退回 iptables日志里只留一行警告。如果你发现 Service 数量增长后延迟有波动可以先检查一下 kube-proxy 到底跑在哪种模式。4.3 Ingress 资源与 Ingress Controller 的关系及常见误区很多人刚接触 Ingress 时会误以为它是 Service 的升级版或者是一个独立的负载均衡器。这个误解如果不纠正后面理解流量路径会一直卡壳。准确地说Ingress 只是一份“路由规则”对象定义了什么域名、什么路径应该转发到哪个 Service。真正侦听端口、执行转发、终止 TLS 的是一个叫 Ingress Controller 的组件最常见的实现是基于 Nginx 的控制器也有基于 Envoy、HAProxy 的版本。所以完整链路是这样的用户请求 - 域名解析到 Ingress Controller 所在入口 - Controller 按规则找到后端 Service - ClusterIP 转发到对应 Pod这里有个我在项目里反复强调的点如果 Ingress Controller 没有部署那你写一万份 Ingress 资源也毫无效果。很多人部署完 Ingress 规则后访问还是 404第一反应是改规则其实应该先确认 Controller 本身是否在运行。Ingress 解决的是七层路由和域名分发而 Service 解决的是四层负载均衡和服务发现两者是配合关系不是替代关系。5. 生产化第一课可观测性、资源治理与权限隔离5.1 监控三层与日志链路集群能跑应用能发这只是“可用”。生产环境追求的是“可观测”也就是任何时候你都能回答三个问题现在状态怎么样刚才发生了什么为什么会变成这样我习惯把监控拆成三层第一层是基础设施层采集节点的 CPU、内存、磁盘、网络通常在每个节点上跑一个指标采集器。第二层是集群资源层重点盯集群里有多少 Pod、Deployment、副本数是否有偏差、各命名空间的资源占用情况。第三层是应用层采集应用自定义的业务指标比如订单量、请求延迟分布。指标采集之后需要一个负责存储和查询的时序数据库再配合面板工具展示。这里有个起点建议先装 metrics-server它提供kubectl top命令和 HPA 的指标来源非常轻量适合入门。等你想深入看历史趋势和告警时再上更完整的监控体系。日志链路则是另一条线。K8s 里容器日志默认是打到标准输出的容器运行时接管以后会写到节点的日志文件里。采集思路一般是这样在节点上跑一个采集器读取容器日志文件转发到统一的日志检索平台。注意这里采集的是容器运行时产生的日志文件不是直接的宿主系统日志路径和文件名都有规则排查日志丢失时先确认采集器有没有权限读取这些目录。5.2 request 与 limitQoS 等级决定了被淘汰的顺序资源治理是生产集群最容易引发事故的话题。每个 Pod 都可以声明两份资源数字requests 和 limits。requests 是给调度器看的。调度器决定把 Pod 放到哪个节点时会看这个节点上所有 Pod 的 requests 总和加上新 Pod 的 requests是否超过节点容量。它不看实际使用量只看声明值。所以如果给 Pod 设置的 requests 偏高可能造成节点明明很空闲却调度不进去设置偏低又可能在高峰期节点资源被打满。limits 是给运行时看的。容器运行时用 limits 设置 cgroup 配额限制容器最多能用多少 CPU 和内存。CPU 超限只会被限流内存超限则可能被直接杀掉。这两组数字组合出来的服务质量等级决定了节点内存紧张时谁先被淘汰如果 requests 和 limits 都设置了且相等属于高优先级requests 小于 limits属于可突发等级完全没设置属于最低优先级。你在生产环境会发现优先被杀死的往往是最低优先级的那个 Pod所以如果某个应用至关重要别不舍得给它把 requests 和 limits 设成一样。这是资源模型里最重要的一条经验。5.3 namespace、RBAC 与配额的最小实践集群一旦有多个团队共用你就要开始考虑“隔离”这件事了。但请注意namespace 提供的首先是“逻辑隔离”不是“网络隔离”。它把资源按名字划开方便管理配额、权限和删除范围不代表 A 命名空间的 Pod 天生不能访问 B 命名空间的服务。权限控制靠 RBAC。K8s 内置了一套基于角色的访问控制给某个主体通常是一个 ServiceAccount绑定某个角色角色里规定了可以操作哪些资源、哪些动词。最小权限原则在这里特别重要应用跑在集群里它离集群管理权限越远越好。我在项目里看到一个团队把应用用的 ServiceAccount 绑定到了 cluster-admin那是非常危险的做法。一旦应用被攻破等于集群的钥匙直接送给了攻击者。配额方面ResourceQuota 可以限制某个 namespace 的资源总和LimitRange 可以给没有写资源的容器自动套默认值。我把这两个配合使用先用 LimitRange 强制每个 Pod 必须有 requests 和 limits再用 ResourceQuota 限制 namespace 总量防止某个团队一次性把集群资源吃光。6. 通向精通的几条主线存储、配置交付与扩展能力6.1 PV、PVC 与 StorageClass把存储当成另一类 API 资源很多任务跑起来之后你会发现容器里的数据是“一次性的”Pod 一删写入的数据就没了。解决这个问题就要引入持久化存储。理解存储的关键是分清“需求”和“供给”。用户写一个 PVC描述“我需要 10G 空间、可以同时被一个节点读写”系统去找一块符合条件、未被绑定的 PV 来做绑定。PV 是集群里的存储资源像是一个磁盘池。当然你不可能每次手动创建 PV所以就有了 StorageClass。它定义了一个存储模板用户提交 PVC 后系统会自动根据这个模板调用存储驱动程序创建一个 PV 出来这叫动态供给。如果你在私有环境里没有云厂商的存储服务可以先用基于本地目录的存储方案或者 NFS 这类共享存储。但要知道生产环境对数据安全要求高的业务通常需要分布式存储或者云盘。CSI 机制是这里的关键存储供应商只要实现 CSI 接口就能无缝接入 K8s你不需要了解底层实现。对有状态应用比如数据库建议再研究一下 StatefulSet它提供稳定的网络标识和顺序启停和普通 Deployment 的差异非常大。6.2 ConfigMap、Secret 与 Helm 的边界配置管理是“精通”路上绕不开的一环。ConfigMap 用来保存非敏感的配置内容比如环境变量、配置文件片段。Secret 用来保存敏感信息比如密码、Token。这里有两个容易被忽视的点。第一Secret 默认并不加密。它只是做了 base64 编码这不是真正的保密。生产环境应该开启 etcd 的静态加密或者引入外部密钥管理工具再把 Secret 通过 K8s 的加密机制落到 etcd 里。第二ConfigMap 和 Secret 挂载到 Pod 之后很多配置更新并不会热加载你只能在发布新版本时让它生效。想让配置“变更即生效”需要应用层配合监听文件变化并重载。再往上走一层你会接触到 Helm。Helm 解决的是“一堆 YAML 怎么组织、怎么复用、怎么管理版本”的问题。一个应用往往需要 Deployment、Service、ConfigMap、Ingress 好几个对象Helm 把这些打包成一个 Chart你只要在安装时传几个参数就能整站部署。我个人的分寸感是部署无状态应用用 Helm 足够逻辑复杂、需要自愈和自动扩缩的就考虑更上层的方案。Helm 是软件包的安装器而操作符是“应用自己的运维系统”两者完全可以共存。6.3 CRD 与 Operator把自己的经验变成控制器最后聊聊 K8s 最强大的扩展能力自定义资源定义和 Operator 模式。CRD 允许你定义自己的资源类型。比如你可以定义一个“DatabaseCluster”资源字段里写上三个节点、异步复制、每日备份。这个资源一旦创建K8s 本身并不理解它是什么意思但一个专门针对这种资源开发的控制器会监听它的变化然后替你创建 StatefulSet、Service、备份任务并在故障时执行恢复。这就是 Operator 的本质把某个领域专家的运维经验固化成代码变成一个不断盯着自定义资源看的控制器。它在 Kubernetes 里打开了一个巨大的想象空间——你不再只是使用别人提供的平台而是能制造一个“懂你的业务的平台机制”。很多人觉得 Operator 高不可攀其实它的核心就是我们前面反复提到的控制器模式只是监听的对象从内置的 Deployment 变成了你自己定义的新类型。从入门到精通并没有一口气吞下的捷径。但这条路的乐趣在于每遇到一个报错每解决一个疑难你对这套系统的理解就会深一层。我记得有一次某个集群里有两个节点的内核版本不一致导致特定节点的 Pod 网络时好时坏排查到最后才发现是内核某个模块的行为差异。那次之后我形成了一个习惯动手前先看版本排错时先看事件确认方案前先看日志。这些习惯比记住任何 API 参数都值钱。希望这篇文章不只是给了你一份知识清单更能帮你养成一套面对这套复杂系统时的健康心态。