容器单机不够用了？Kubernetes 集群帝国与 Service Mesh 导流魔术

延伸阅读

更多相关攻略推荐：泛域名 SSL 证书自动化避坑：Acme.sh + DNS API 、BGP 是互联网的"高德地图"：打开网页时，数据是这样找路的、【优化线路 02】BGP / AS4837 常规线路年付 10 美元、高级玩家玩出花：如何在 VPS 上广播自己的 IP 地址？BYOIP、计算机科学两大难题之一：缓存失效与 CDN 瞬时刷新奥秘。

一、单机编排的甜蜜期，到了万台机器就成了噩梦

很多人第一次玩容器，都是从 Docker 开始的。写个 docker-compose.yml，敲一行 docker compose up，几秒钟里十几个服务就起来了，数据库、缓存、后端、前端整整齐齐。这种"单机编排"体验太爽了，以至于不少人心里犯嘀咕：既然 Docker Compose 这么好用，我直接把它拷到上百台机器上跑不就行了？

答案是：不行，而且会死得很惨。Docker Compose 的设计前提是——所有容器都跑在同一台机器上。它本质上是个本地进程管理器，只认你这一台主机的 CPU、内存和网卡。当你想把服务摊到 1000 台机器上，Compose 立刻暴露出三个它天生解决不了的短板。

• 它不知道哪台机器闲、哪台机器忙，没法把容器"调度"到最合适的机器上。
• 某台机器半夜宕机了，Compose 不会把上面的容器挪到别的机器重启，你得自己爬起来手动处理。
• 流量突然翻倍，它不会自动多开几个副本分担压力，只能你人肉改配置再重启。

说白了，Docker Compose 是"小卖部老板自己记账"，生意做大了、开了几十家分店，你就必须有一套总部系统。Kubernetes（江湖人称 K8s）就是这套总部系统，专门管成千上万台机器的"集群编排"。

二、K8s 的控制平面：集群的"大脑"

K8s 的架构可以分成两半：上面是控制平面（Control Plane），相当于总部大脑；下面是若干工作节点（Worker Node），相当于一家家分店。大脑不直接干活，它只做决策和管理。

控制平面里有四个核心角色。第一个是 kube-apiserver，它是整个集群的"前台大门"，你敲的所有命令、所有组件之间的通信，统统先过它这一关。它负责校验请求、记录状态，而且天生能横向扩展——多开几个实例前面挂个负载均衡就行。

第二个是 etcd，一个一致性强、高可用的键值数据库。你可以把它理解成集群的"总账本"，集群里现在有哪些节点、跑了哪些应用、每个应用想要几个副本，全记在这儿。因为它是唯一真相来源，所以 etcd 一旦坏了，整个集群就瞎了，生产环境必须给它做备份。

第三个是 kube-scheduler，调度器。它的工作很单纯：盯着那些"刚出生、还没分配家"的 Pod（容器组），给它们挑一台最合适的机器。挑哪台？要看这台机器还剩多少 CPU 和内存、有没有特殊的软硬件限制、应用之间想不想挨着放（亲和性）、数据在不在本地等等。

第四个是 kube-controller-manager，控制器管理器。这里面住着一群"监工"：节点控制器专门盯着机器是不是挂了；副本控制器负责保证你指定的应用永远有 N 个副本在跑；还有管端点、管账号的各种控制器。它们干的事，就是不断地把"现实"往"你想要的模样"上拽——这恰恰是 K8s 自我修复的根本原理。

三、Worker 节点与 Pod：干活的与最小的搬运单位

每台工作节点上跑着三个东西。kubelet 是节点上的"包工头"，听 apiserver 的话，确保该跑的容器真的跑起来了、还健康。kube-proxy 负责把网络规则铺到节点上，让服务之间能互相找到对方。容器运行时（比如 containerd）则是真正把容器跑起来的引擎。

这里要讲清一个概念：K8s 调度的最小单位不是"容器"，而是 Pod。一个 Pod 里可以装一个或多个容器，它们共享网络和数据卷，像住在同一间宿舍的室友。最常见的玩法是"主容器 + 边车容器（sidecar）"——主容器跑业务，边车容器顺手干点日志收集、证书刷新的杂活。这个边车思想，后面讲 Service Mesh 时还会用到。

四、自动扩缩容与自我修复：K8s 怎么当"保姆"

K8s 最被人称道的两招，是弹性扩容和自愈。先说自动扩缩容（HPA）。Horizontal Pod Autoscaler（水平 Pod 自动伸缩器）会盯着 CPU、内存或者你自定义的指标：白天访问量冲上来了，它自动把副本从 3 个加到 30 个；后半夜没人了，又悄悄缩回 3 个。你不用半夜爬起来改配置，钱也省了。

再说自我修复。这不是什么魔法，而是一圈圈的"调谐循环"。容器崩了？kubelet 按规则把它重启。机器彻底宕机？控制器发现节点失联，把上面的 Pod 重新调度到别的机器上。容器明明活着但卡死了、健康检查（探针）一直不过？K8s 会直接杀掉它，换一个新的顶上。结果就是：哪怕底层硬件今天坏两台、明天坏三台，你的应用对外看起来始终稳稳当当。

五、微服务多了，"服务之间怎么通信"成了新难题

当你的系统从几个服务膨胀到几十上百个微服务，一个新问题冒出来了：A 服务调用 B 服务，中间要管的事情太多了——连接失败要不要重试？超时要设多久？下游挂了要不要熔断别把整条链路拖死？服务之间的流量要不要加密？出了问题怎么知道是哪一步慢了？

最笨的办法，是让每个开发团队在自己服务里把这些逻辑各写一遍。结果就是：几十个服务，几十套五花八门的 retry、超时、加密代码，风格不一、漏洞百出，还很难统一治理。Service Mesh（服务网格）就是来收拾这个烂摊子的。

六、Service Mesh：给每个微服务配个"旁路保镖"

Service Mesh 的核心思想特别巧妙：把"服务之间通信"这件苦差事，从应用代码里抽出来，下沉到基础设施。具体怎么做？给每一个 Pod 旁边塞一个轻量级代理（最常用的是 Envoy），业内叫 Sidecar（边车）模式——就像给摩托车旁边加挂一个跨斗。

从此以后，业务容器以为自己只是在跟"本机 localhost"聊天，实际上所有进出的流量都被旁边的 Envoy 劫持了。这个边车替它干完了所有脏活：

• 流量管理：把 5% 的流量导到新版本做灰度，或者按规则做 A/B 测试，全靠声明式配置，不改一行业务代码。
• 重试、超时、熔断：下游抖一下自动重试；错误率超阈值自动熔断，防止重试风暴把健康节点也冲垮。
• mTLS 双向认证加密：服务之间自动加密、互相证明身份，零信任安全开箱即用。
• 可观测性：每个调用的延迟、错误率、请求数自动上报，不用每个团队各接一套监控。

这些边车组成"数据面"，而统一指挥它们的"控制面"叫 Istiod（Istio 的控制平面），它负责把规则推给所有边车、发证书、收集指标。控制面一改策略，边车们悄悄更新，业务容器全程无感。

七、边车怎么无感劫持流量？1 到 3 毫秒的代价

你肯定好奇：边车是怎么神不知鬼不觉拦下流量的？秘诀是 iptables 规则——Pod 启动前，一个初始化容器先往网络栈里插几行规则，把所有进出流量重定向到 Envoy 的端口（出向 15001、入向 15006）。业务代码一行都不用改，完全感知不到。代价呢？每跳一次大约多花 1 到 3 毫秒，每个 Pod 多占 30 到 50 MB 内存。用 Cilium 那种基于 eBPF 内核方案能把单跳压到 0.5 毫秒左右，但功能成熟度还在追赶 Envoy。

八、为什么大家又爱又恨：太贵太复杂，却离不开

网上吐槽 K8s 和 Service Mesh"复杂、烧钱、劝退"的声音从来没停过，这话一点不假。光是 Service Mesh，你就得多运维一个分布式控制面，证书要管、边车流量出毛病调试起来要同时看懂 iptables、Envoy 路由表和一堆自定义资源（CRD），学习曲线陡得吓人。Istio 的 CRD 一抓一大把，DestinationRule 和 VirtualService 配错一个，流量就悄悄退回轮询，查半天找不到原因。

那为什么大厂还离不开？因为弹性、自愈、标准化带来的收益，在规模上来之后是碾压级的。当你的服务数以百计、机器成千上万、一天部署几十次，没有这套体系你根本管不过来。而且 K8s 把"应用怎么跑"用一套标准 YAML 描述清楚，换云厂商、换机房都能平滑迁移，不被任何一家绑定。

但请记住一句大实话：小项目真的不需要。业内有个经验分水岭——服务少于 15 到 20 个，老老实实用语言自带的 RPC 库加重试逻辑、用 cert-manager 管证书就够了，上 K8s 全家桶属于杀鸡用牛刀，反而被复杂度拖垮。K8s 1.22 之后 Istio 还推出了 ambient 模式，用节点级 ztunnel 替代每个 Pod 的边车，想减轻资源负担，这也说明社区自己也意识到"太重了"这个痛点。

九、一句话带走

• Docker Compose 只管单机，机器上千台就得靠 K8s 这种集群编排系统。
• 控制平面（API Server / etcd / Scheduler / Controller Manager）是大脑，Worker 节点是手脚，Pod 是最小调度单位。
• 自愈和 HPA 自动扩缩容，靠的是"不断把现实拉回期望状态"的调谐循环。
• Service Mesh 用 Sidecar 边车把重试、熔断、mTLS、可观测性下沉到代理，业务代码零改动。
• K8s 复杂且贵，但换来弹性与标准化；服务不到 20 个的小项目，别急着上。

常见问题 FAQ

问：Kubernetes 和单纯跑 Docker 有什么区别？ 答：Docker 只管单台机器上的容器，Kubernetes 在多台机器间调度容器、自动重启、扩缩容、做服务发现与负载均衡。简单站点用 Docker Compose 够；要弹性、高可用、多服务协作才上 K8s。

问：Service Mesh（如 Istio）解决什么问题？ 答：它把流量管理、重试、熔断、鉴权、可观测性从业务代码里抽出来，放到 sidecar 代理层统一处理。服务多了之后，不用每个语言各写一套，运维也更统一，但会多吃点资源。

问：便宜 VPS 能跑 Kubernetes 吗？ 答：能。2GB 内存起步可跑轻量 k3s 单节点练手，多节点高可用建议每台 2–4GB、至少 3 台。用 RackNerd/BuyVM 这类便宜机拼个小集群完全可行，适合学习与测试，生产再加配置。