Kubernetes容器编排系统背后的概念可能很难理解。这里做了一个简单的类比：把房子里的房间出租，帮助你了解Kubernetes是如何工作的。

如何在房子里出租房间

想象一下你拥有一座有10个房间的房子。你想通过在线住宿服务出租其中的三个房间。你有两个选择：发布广告，自己管理一切；雇人帮你做。

想省事儿，你决定雇佣一个租赁代理来处理这些事情。你与代理的合同规定：

——在任何时候，都应该有三个房间出租给客人。

——每个房间有两张床。

——每次客人预订时，钥匙都需要在适当的时间交给客人。

——每次客人离开时，房间都要打扫干净。

——如果有太多的预订请求（例如在假日期间），那么可预订的房间可以从3个增加到10个。

就这样！你不用操什么心了，愿意的话可以不时地用电话联系代理了解情况。

如何管理租赁

代理雇佣员工来满足你的需求。假设有三个员工管理三个房间：一号房间预订后，员工一确保房间状况良好，提供钥匙，清洁服务等。

床是最基本的实体，因为它是客人过夜的最低要求。

代理将员工、房间、床位、预订等所有信息保存在笔记本上。代理还记录员工的休假时间，以便在某个员工生病或休假时将另一名员工分配到房间。代理根据需要使用电话联系员工。

当客人在线预订房间时，预订会被重定向到一个确保该房间准备就绪的员工。客人来了，拿到钥匙，晚上睡在床上，走的时候打扫房间，然后重复这个循环。

这听起来很简单，但这和Kubernetes有什么关系？

Kubernetes的类似之处

你通过雇用其他员工的代理实现自动化，这与Kubernetes对应用程序的操作类似。下面是它的工作原理。

假设你是一个应用程序开发者。类比出租房中最基本的实体是床，应用程序（满足用户需求的最基本实体）运行在容器中。应用程序的“房间”称为pod，它是应用程序运行的地方。

节点或工作节点本质上是一台运行pod的机器。

代理的员工确保客房功能齐全。在Kubernetes里，你没有员工，但有kubelet。kubelet是节点内的一个代理，它确保在该节点内运行的pod是健康的。

租赁代理对应于Kubernetes中的两件事：kube-scheduler和kube-controller manager。就像代理决定应该将哪个房间分配给哪个员工一样，kube-scheduler根据可用的资源及其需求来决定哪个pod在哪个节点上运行。记住，节点是一台机器，而pod在节点内运行。就像代理决定员工下班时要做什么一样，kube-controller manager决定当节点宕机或机器因任何原因停止工作时该做什么。

代理的笔记本上记录了关于出租多少房间、有多少张床空着、哪个员工在做什么等所有细节，它与etcd数据存储相对应。这就是配置数据存储的地方，例如，如果你需要三个pod一直在运行。

Kubernetes中的主节点和worker节点类似于代理和员工用来通信的电话。主API-server类似于代理的电话，而每个worker节点的kube-proxy则类似于员工的电话。

API-server、etcd、kube-controller manager和kube-scheduler组成了这个Kubernetes实例的控制中心。

部署

你（房主）和代理之间的合同相当于在Kubernetes中的部署。部署包括一组需求，比如需要运行多少个pod，需要什么资源（例如CPU）等。Kubernetes确保无需人工干预即可满足这些要求。

还记得协议中的额外条款吗？如果有太多客人预订，该怎么办？这相当于Kubernetes中的自autoscaling。这意味着Kubernetes可以扩展你的服务，随着应用程序用户的增加，为你提供更多的pod，就像你可以在更多的客人试图预订时提供更多的房间一样。正如你不能将预订扩展到超过10个房间一样，你可能需要为自动缩放设置一个上限，因为你不能随意地继续增加pod。

原文链接：

https://opensource.com/article/20/7/kubernetes-analogy