多年来，我一直在进行系统管理/工程/基础设施开发，但不知何故，我设法避免与Kubernetes的任何互动。这种避免并不是偶然的；我的工作需要对工作负载在物理位置的放置进行严格控制。随着时间的推移，我对Kubernetes发展了一种怀疑的看法，虽然我并没有真正的基础，只是对它有一种模糊的印象，认为它是“新兴的方法”和“多余的复杂性”。我决定基于事实而不是感知来形成我的看法，于是我在这里写下了我所学到的内容。虽然有很多教程涵盖Kubernetes集群的使用和操作，以及其组件的基本描述，但这些对我来说并不太管用。这些资源通常轻描淡写地介绍组件的功能，但常常缺失了潜在的原因或权衡。这篇文章旨在从一种我认为有用的视角覆盖这些概念，并不打算是详尽无遗的。“标准”描述Kubernetes可以让你运行任意工作负载，并提供以下能力：动态指定要求（CPU、磁盘、内存、实例数量等）动态扩展实例数量，但更重要的是，它为你做了什么：选择应用程序运行的主机“自愈”（崩溃的实例会被重新启动，实例会自动移出故障主机）为基于DNS的发现公开服务，它只需要你将工作负载打包为Docker镜像，这似乎是一个合理的代价。构成集群的基本构建块可以定义如下：Pod：一项工作单元，由一组Docker镜像及其配置组成Node：运行Kubernetes节点代理（kubelet）的计算机，执行Pods。Cluster：包含控制平面的节点的逻辑集合。Service：一组Pods的逻辑分组Namespace：集群的逻辑细分，为名称提供作用域（如DNS搜索域）观察这些概念之间关系的图示更容易：虽然这可能是一个尚可的解释，但对我来说并没有真正的用处——许多基础设施平台看起来都像这个图表；这里没有什么特别之处。我认为重要的是，我的观点是Kubernetes的价值很大一部分来自两个概念：控制循环工作负载由一组控制循环（称为控制器）管理。一个控制循环将持续执行操作（通过控制元件），如有必要，以达到期望状态，并通过观察特定变量（通过传感器）来实现这一点。有趣的细节是，控制元件并不一定直接影响传感器观察到的内容。这种描述非常通用，所以这里有一些例子：一个需要处理队列事件的工作负载预期状态：空队列传感器：队列深度控制元件：事件处理服务器的数量一个需要水平扩展以应对用户负载的工作负载预期状态：将P90延迟维持在X毫秒以下传感器：后端的延迟指标控制元件：启动新的Pods来处理需求通用健康监控预期状态：所有节点都是健康的传感器：节点的健康指标控制元件：从集群中移除节点服务服务是一个网络级别的概念，为一组支持Pods提供稳定的访问，它提供：稳定的身份：不变（虚拟）IP地址和DNS记录负载均衡：将传入流量分配到Pods服务发现：允许其他组件找到并与服务通信与“经典”集群相比，服务提供一种类似于以下组合的抽象：N个运行Keepalived + NGINX（具有动态后端集的）虚拟（Keepalived）IP的CNAME记录每次创建新服务时：将为其分配一个虚拟IP每个节点将更新其网络配置（netfilter），将任何目标指向每个服务的虚拟IP的数据包转发到支持Pods。网络配置由在每个节点上运行的控制器kube-proxy更新，主要负责监控所有服务对象的状态并在每次更改时更新netfilter规则。这样的设计意味着所有节点充当服务流量的负载均衡器，因此在服务流量转发中没有单点故障，并且流量转发能力随着集群规模的增长而扩展。对我来说，这个设计一个有趣的特性是每个节点都接收每个服务的规则，这有一些影响：kube-proxy的实现非常简单规则的数量可能很大，这对于某些流量转发实现可能是一个问题（iptables线性评估每个规则）在某些情况下，流量会多次转发，以较高的可用性为代价，给集群增加额外负载。