共计 2484 个字符，预计需要花费 7 分钟才能阅读完成。
本篇文章为大家展示了 Kubernetes 是如何工作的，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
过去几年来，运行容器化应用程序的流行度呈爆炸式增长，这已经不是什么秘密了。能够通过代码提供应用程序的依赖项来迭代和发布应用程序是一个巨大的胜利。Gartner 表示，到 2022 年，“超过 75% 的全球组织将在生产中运行容器化应用程序”。
对于大规模运行的组织来说，一个 Linux 容器实例不足以满足其应用程序的所有需求。对于足够复杂的应用程序，例如通过微服务进行通信的应用程序，需要多个相互通信的 Linux 容器并不少见。该体系结构引入了一个新的扩展问题：如何管理所有这些单独的容器？开发者仍然需要安排容器在特定机器上的部署，管理它们之间的网络，增加在高负载下分配的资源等等。
来到 Kubernetes，一个容器编排系统 – 一种管理容器化应用程序生命周期的方法。它是一种元过程，允许同时自动部署和扩展多个容器。运行相同应用程序的几个容器被分组在一起。这些容器充当副本（replica），并用于负载平衡传入的请求。然后，容器编排器监督这些组，确保它们正确地运行。
容器编排器本质上是负责操作一组容器化应用程序的管理员。如果需要重新启动容器或获取更多资源，则由编排器为你处理。
这是对大多数容器编排器工作原理的一个相当广泛的概述。让我们更深入地研究一下 Kubernetes 的所有组成部分。
Kubernetes 术语和架构
Kubernetes 引入了许多词汇来描述应用程序的组织方式。我们将从最小的一层开始。
Pod
Kubernetes pod 是一组容器，是 Kubernetes 管理的最小单元。Pod 有一个单独的 IP 地址，应用于 pod 中的每个容器。Pod 中的容器共享相同的资源，比如内存和存储。这允许将 pod 内的单个 Linux 容器作为单个应用程序一起处理，就好像在更传统的工作负载中，所有容器化的进程都在同一主机上运行一样。当应用程序或服务是需要运行的单个进程时，只有一个容器的 pod 是很常见的。但是，当事情变得更加复杂，并且多个进程需要使用相同的共享数据卷共同工作以实现正确的操作时，与单独在容器之间设置共享资源相比，多容器 pod 简化了部署配置。
例如，如果你正在处理创建 gif 的图像处理服务，一个 pod 可能有多个容器一起工作来调整图像的大小。主容器可能运行接收请求的非阻塞微服务应用程序，然后运行一个或多个辅助（侧车）容器，运行批处理后台进程或清理存储卷中的数据构件，作为管理整体应用程序性能的一部分。
Deployment
Kubernetes deployment（部署）允许你设置希望如何在 Kubernetes 节点上复制 pod 的详细信息，从而定义希望运行应用程序的规模。Deployment 描述所需运行的相同 pod 副本的数量，以及更新部署时使用的首选更新策略。Kubernetes 将跟踪 pod 的健康状况，并根据需要删除或添加 pod，使应用程序部署达到所需的状态。
Service
单个 pod 的寿命不能被依赖；从它们的 IP 地址到它们的存在，一切都有可能发生变化。事实上，在 DevOps 社区中，有一个概念是将服务器视为“宠物”（pets）或“牛”（cattle）。宠物是你需要特别照顾的东西，而牛则被认为是更值得牺牲的东西。同样，Kubernetes 也没有将它的 pods 视为惟一的长时间运行的实例；如果 pod 遇到问题而死亡，Kubernetes 的工作就是替换它，这样应用程序就不会经历任何停机时间。
Service 是对 pods 的抽象，本质上是各种应用程序使用者交互的惟一接口。当 pod 被替换时，它们的内部名称和 IP 可能会发生变化。Service 将单个机器名称或 IP 地址映射到其基础名称和编号可以是不可靠的 pod。Service 确保在外部网络中，一切看起来都是不变的。
Node
Kubernetes node（节点）管理和运行 pod；是执行给定工作的机器（无论是虚拟的还是物理的）。就像 pod 收集一起操作的单个容器一样，node 收集一起工作的整个 pod。当你进行大规模操作时，你希望能够将工作移交给一个 node，该 node 的 pod 可以接收工作。
Master server
这是管理员和用户管理各种节点的主要入口。操作通过 HTTP 调用，或连接到机器并运行命令行脚本发送给它。
Cluster
Cluster（集群）是将上述所有组件作为一个单元组合在一起。
Kubernetes 组件
对于 Kubernetes 是如何组装的有了一个大致的概念，现在就来看看确保一切顺利运行的各种软件组件。主服务器和单个工作节点都有三个主要组件。
Master server 组件
API Server
API 服务器向 Kubernetes 集群暴露一个 REST 接口。所有针对 pod、service 等的操作都是通过与它提供的端点通信以编程方式执行的。
Scheduler
调度程序负责将工作分配给各个节点。它监视资源容量，并确保工作节点（Worker node）的性能处于适当的阈值之内。
Controller-manager
controller-manager 负责确保集群的共享状态按预期运行。更准确地说，控制器管理器监视响应事件的各种控制器（例如，如果节点发生故障）。
Worker node 组件
Kubelet
Kubelet 跟踪 pod 的状态，以确保所有容器都在运行。它每隔几秒钟向主服务器（Master server）提供一条心跳消息。如果复制控制器（replication controller）没有接收到该消息，则节点被标记为不健康。
Kube proxy
Kube 代理发送从服务进入节点的流量。它将工作请求转发到正确的容器。
etcd
etcd 是一个分布式键值存储，Kubernetes 使用它来共享关于集群总体状态的信息。此外，节点可以引用存储在那里的全局配置数据，以便在重新生成它们时设置它们自己。
上述内容就是 Kubernetes 是如何工作的，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注丸趣 TV 行业资讯频道。
