当前位置：首页 > news >正文

Kubernetes (K8s)入门指南：Docker之后，为什么需要容器编排？

news 2025/8/26 6:06:23

更多云服务器知识，尽在hostol.com

你是否已经熟练地掌握了Docker这门“打包”的艺术？你的应用，被你优雅地装进了一个个标准、干净、可移植的“集装箱”里，你感觉自己拥有了“一次构建，随处运行”的超能力。

于是，你雄心勃勃地，把你那个日益庞大的项目，拆分成了十几个独立的“微服务”，并为每一个，都制作了精美的“集装箱”。你为你的用户服务做了个容器，为订单服务做了个容器，为商品服务做了个容器……

然后，灾难开始了。

你突然发现，你现在就像一个手忙脚乱的“港口调度员”，面前是上百个五颜六色的集装箱，和几十艘大小不一的货轮（服务器）。

你不知道该把“用户服务”这个集装箱，放到哪艘“货轮”上最合适。
为了保证高可用，你需要手动把“订单服务”这个集装箱，复制三份，分别放到三艘不同的“货轮”上。
如果其中一艘“货轮”不幸沉没了，你需要半夜三点爬起来，手动把那艘船上的所有集装箱，都挪到新的“货轮”上。
“用户服务”这个集装箱，该如何找到“订单服务”那个集装箱的地址？难道每次都要手动去更新IP地址吗？

你猛然惊醒：Docker，只解决了“打包”的问题，它并没有解决“运输”和“管理”的问题！ 它给了我们标准化的“集装箱”，却没有给我们一个智能化的“港口管理系统”。

而Kubernetes，就是那个我们梦寐以求的、拥有超级AI的、全自动的“全球港口自动化管理与调度系统”。它的出现，不是为了取代Docker，而是为了释放Docker的全部潜力，让管理成千上万个容器，变得像管理一个容器一样简单。

为了让你彻底理解K8s到底解决了什么神级问题，我们换一个更艺术的比喻：指挥一个交响乐团。

你的每一个Docker容器： 都是一位才华横溢、技艺精湛的“音乐家”。
你的整个微服务应用： 就是一部需要上百位音乐家协同演奏的、极其复杂的“交响乐”。
只用Docker，不用K8s的你： 就是把一百位音乐家请到舞台上，然后对他们说：“乐谱给你们了，你们自己看着办，开始演奏吧！”结果，可想而知，将会是一场灾难。

而Kubernetes，就是那位站在指挥台上、手持指挥棒、灵魂附体的“乐团总指挥”——卡拉扬。

痛点一：音乐家太多，我该让谁坐在哪里？—— 部署与弹性伸缩

只用Docker的困境： 你需要3个“小提琴手”（3个订单服务容器），你得亲自跑去找3个空闲的座位（服务器），然后一个一个地安排他们坐下（ssh登录，然后docker run）。音乐会进行到高潮，你需要临时增加5个“小提琴手”怎么办？你得再重复一遍上面的流程。其中一个“小提琴手”突然肚子疼退场了怎么办？在你发现之前，乐团的这个声部，已经出现了空白。
K8s这位“总指挥”的做法： 你不再需要亲自去安排每一个音乐家。你只需要向K8s这位“总指挥”，递上一份**“演出编制表”**（一个YAML配置文件）。你在这份“编制表”里，用一种“声明式”的语言写道：“我需要：‘小提琴手’，3位。”（replicas: 3）然后，把这份表交给K8s。K8s会搞定剩下的一切！
- 它会自动扫描整个乐团（集群），找到3个最合适的空闲座位（Node节点），然后安排“小提琴手”（Pod）坐下。
- 你觉得高潮部分需要8位小提琴手？很简单，把“编制表”里的3改成8，再提交给K8s。它会在几秒钟内，自动为你变出另外5位，并安排好座位。
- 如果演奏过程中，有一位“小提琴手”不幸“晕倒”了（容器崩溃或服务器宕机），K8s这位眼观六路的“总指挥”会立刻发现，并在万分之一秒内，从后台预备队里，找一位新的、一模一样的“小提琴手”，坐到那个空位上。
- 整个过程，你，作为“作曲家”，完全无感。你只管“声明你想要的状态”，而K8s负责“让现实世界永远等于你声明的状态”。

痛点二：乐团内部，声部之间如何“眉目传情”？—— 服务发现与负载均衡

只用Docker的困境： “弦乐部”（用户服务）需要和“铜管部”（商品服务）进行配合。但每一个“音乐家”（容器）的座位号（IP地址），都是在他们入场时随机分配的，而且随时可能因为“换座位”而改变。难道，每次演奏前，都要让所有音乐家，重新交换一遍自己的新座位号吗？这显然不现实。
K8s这位“总指挥”的做法： K8s为每一个“声部”（一组相同的容器，比如所有“订单服务”容器），都设立了一个永不改变的“声部长席位”，并给这个席位，分配了一个固定的“内部虚拟电话号码”。我们称之为**“服务”(Service)**。
- 任何其他声部的音乐家，想要找“弦乐部”时，不再需要知道具体是哪一位“小提琴手”，他只需要拨打“弦乐部”这个公开的“内线电话”即可。
- K8s这位“总指挥”，会自动把这个“电话”，转接到当前某一位有空闲的、状态健康的“小提琴手”那里。它还在内部，实现了一套完美的负载均衡。
从此，你的应用内部，服务之间的通信，变得极其简单和稳定。大家都不再关心对方的具体座位号，只关心对方所在的“声部”名称。

痛点三：如何让“观众”优雅地入场？—— Ingress与外部访问

只用Docker的困境： 你的音乐厅（服务器集群）里，有几十个不同的演奏厅（服务），分别在演奏不同的乐曲。但整个音乐厅，只有一个“正门”（服务器的80/443端口）。你怎么让想听“贝多芬”的观众，精准地走进贝多芬音乐厅，而想听“莫扎特”的，走进莫扎特音乐厅？手动配置Nginx的反向代理？当你有几十上百个服务时，这会变成一场噩梦。
K8s这位“总指挥”的做法： K8s设立了一个专业的“票务与引导系统”，我们称之为**“Ingress”**。
- Ingress就像音乐厅门口，那位拿着“演出排期表”的“首席引导员”。
- 他会检查每一位观众（网络请求）的“门票”（域名和URL路径）。
- 看到门票上写着music.com/beethoven，他就会优雅地一伸手：“贝多芬音乐厅（贝多芬服务），请这边走。”
- 看到门票上写着music.com/mozart，他则会指向另一个方向。 Ingress，以一种极其优雅和标准化的方式，统一管理了整个集群所有服务的“外部入口”，并负责了复杂的路由转发和SSL证书卸载。

痛点四：名贵的“乐器”，该如何保管？—— 持久化存储

只用Docker的困境： “音乐家”（容器）是“临时工”，他们随时可能“离场”。但他们使用的“乐器”（数据），比如那把价值连城的“斯特拉迪瓦里”小提琴（数据库文件），是极其宝贵的，绝不能随着音乐家的离开而消失。如何让数据，独立于容器的生命周期而存在？
K8s这位“总指挥”的做法： K8s建立了一套完善的“乐器管理与申领系统”——Persistent Volume (PV) 和 Persistent Volume Claim (PVC)。
- PV (持久卷)： 就像是乐团的“资产库”，里面存放着所有名贵的乐器。这些乐器，由乐团统一保管，独立于任何音乐家。
- PVC (持久卷声明)： 就像是音乐家递交的一张“乐器申领单”。上面写着：“我需要一把小提琴，至少是大师级的。”
- K8s这位“总指挥”，在收到“申领单”后，就会去“资产库”里，找到一把符合要求的“小提琴”（PV），然后把它“借”给这位音乐家（Pod）。当这位音乐家“离场”后，这把珍贵的“小提琴”，会自动归还到资产库里，等待下一位音乐家来申领。
- 通过这套机制，K8s完美地将“数据”和“计算”，进行了解耦。