K8s 这个名字是 Kubernetes 的缩写（K和s之间有8个字母，所以叫K8s）。它是谷歌开源的一个容器编排系统。
要理解K8s，我们必须先回想一下刚才讲的 Docker。
从Docker说起：一个集装箱
Docker就像一个集装箱，它把每个软件（比如用户服务、订单服务）和它的运行环境打包在一起，保证这个软件在任何地方都能一模一样地运行。
现在问题来了：
- ∙
如果你的企业网站很小，只有一两个服务，你手动管理几个Docker容器就足够了。
- ∙
但当你的网站变成大型系统（比如淘宝、京东），有成百上千个微服务，每个服务都需要打包成容器，并且需要运行在很多台服务器上时，麻烦就大了：
- 1.
这么多容器，应该放在哪台服务器上？
- 2.
某个容器挂了，怎么让它自动重启？
- 3.
访问流量突然变大，怎么自动增加容器数量来扛住压力？
- 4.
流量过去后，怎么自动减少容器数量来节省资源？
- 5.
如何让用户能访问到这一大堆动态创建、动态销毁的容器？
手动管理？绝对会累死，而且根本不可靠。
K8s是什么？集装箱船运的“全球调度总指挥”
如果Docker容器是单个集装箱，那么 K8s就是一艘巨大无比的、全自动化的“集装箱货轮”，以及指挥整个船队（集群）的“全球调度中心”。
它的核心工作就是自动化地管理和调度成千上万的容器，让它们按照我们期望的方式去运行。
K8s的核心功能（这个“总指挥”有多能干）
- 1.
自动化部署和伸缩 (Deployment & Scaling)
- ∙
你告诉K8s：“我需要运行3个‘用户服务’的容器实例。”
- ∙
K8s的工作：它自动检查集群里哪些服务器（Node）资源充足，然后把容器部署上去。如果某个容器挂了，它会自动重启一个新的，永远保证有3个健康实例在运行。
- ∙
流量来了：你还可以设置规则：“当CPU使用率超过80%，自动再增加2个实例。” 流量高峰过后，它又会自动缩减到3个。这叫弹性伸缩。
- ∙
- 2.
服务发现和负载均衡 (Service Discovery & Load Balancing)
- ∙
问题：容器动不动就重启、扩容、缩容，它的IP地址会变来变去。订单服务怎么才能知道用户服务的最新地址？
- ∙
K8s的解决方案：提供一个固定的“服务名”（Service） 作为访问入口。订单服务只需要访问
http://user-service这个固定地址，K8s会自动将请求负载均衡到背后所有健康的用户服务容器上，完全屏蔽了容器IP的变化。这就是上图中的“港口码头”。
- ∙
- 3.
自愈能力 (Self-healing)
- ∙
K8s不断检查所有容器的健康状况。如果发现一个容器崩溃了，它会毫不犹豫地杀掉它，然后重新启动一个新的，整个过程完全自动化，无需人工干预。
- ∙
- 4.
秘钥和配置管理 (Secrets & Configuration Management)
- ∙
像数据库密码、API密钥这些敏感信息，可以用K8s的 Secret 对象来安全地存储和传递，而不是硬编码在容器里。
- ∙
应用程序的配置文件可以用 ConfigMap 来管理，修改配置后可以统一下发，而不需要重新打包整个容器镜像。
- ∙
总结：Docker 和 K8s 的关系
- ∙
Docker：是打包和创建容器的工具。它解决了“应用和环境一起搬运”的问题。
- ∙
比喻：负责制造和标准化集装箱。
- ∙
- ∙
K8s (Kubernetes)：是自动化管理和调度大量容器的平台。它解决了“成千上万个容器如何在集群中高效、可靠地运行”的问题。
- ∙
比喻：负责指挥全球的集装箱货轮舰队，决定哪个集装箱放哪艘船、何时出发、如何路由、坏了如何替换。
- ∙
所以，在你之前了解的企业网站架构中，K8s 就位于 “支撑与运维层”，它和 Docker 一起，构成了现代化应用容器化与编排的核心基石，是实现微服务架构、DevOps 和云计算的关键技术。没有它，大规模微服务的管理将是一场噩梦。