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

网上关于 Kubernetes 的学习资料，用“汗牛充栋”来形容一点都不夸张。“从入门到精通”这个说法，大概也是被各种课程和文档用到近乎麻木了。但说实话，我见过的大多数人，实际走的路线都是“从入门到放弃”：收藏了一堆教程，跟着装好了集群，结果工作负载一直 Pending；Service 写好了，外部就是访问不到；想查个日志，发现根本不知道从哪里下手。

如果让我用一句话重新概括 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-cidr=10.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 之间无法通信。这个选择直接影响集群的网络能力，值得认真对待。

我画过一张简单的对比表，可以帮你快速做决策：

我第一次搭集群时用的是 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-driver=systemd一致。

还有一种情况是日志里没有明显报错，但你发现 node 上始终起不来任何 Pod，这就要看 CNI 了。最常见的问题是/opt/cni/bin目录下缺少二进制插件，或者 CNI 配置文件的网段和kubeadm init时指定的--pod-network-cidr不一致。我在一个项目里遇到过：控制节点上有个 Pod 一直 ContainerCreating，describe 之后发现是 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 提供了三种探针，我建议哪怕记不住名字，也要记住它们的用途。

我举个例子帮你理解。假设你有一个 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设成 0，maxSurge设成 1，保证先起新 Pod，确认它 ready 之后，再停掉旧 Pod。

我记得有一个项目上线时，因为数据库迁移脚本正好在更新窗口里跑，新 Pod 起不来又不会立刻缩减旧 Pod 导致有段时间流量全断。之后我们就把关键服务的发布策略改成了“先扩容再缩容”，加上了完整的 readiness 探针，出自那次之后发布事故率降了一大截。滚动更新的本质是用小步慢跑换取风险可控，这比一次性杀掉全部旧副本再创建新副本要稳得多。

4. 流量进入集群的三层通路：Service、kube-proxy 与 Ingress

4.1 ClusterIP / NodePort / LoadBalancer 该怎么选

集群内部跑起来的应用，天然是动态的：Pod 会被调度到任意节点，IP 会随重建而变。所以 K8s 抽象出了 Service，用一个固定的虚拟 IP 代表一组 Pod。Service 和 Pod 之间靠标签选择器连接，后端列表由 Endpoints 对象动态维护。

Service 最常见的三种类型，我做了个对比：

初学者最容易犯的错，是把 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 与 limit：QoS 等级决定了被淘汰的顺序

资源治理是生产集群最容易引发事故的话题。每个 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 参数都值钱。希望这篇文章不只是给了你一份知识清单，更能帮你养成一套面对这套复杂系统时的健康心态。