主要组件

k8s有如下的主要组件：

  • Control plane(s) and worker node(s)
  • Operators
  • Services
  • Pods of containers
  • Namespaces and quotas
  • Network and policies
  • Storage.
    一个k8s集群是有一个或多个 cp（控制平面）节点和一组worker 节点组成的。这个集群全都是由对operators的api call驱动的。一个网络插件帮助处理内部和外部流量。我们接下来会更加仔细地查看这些组建。
    大部分进程是在容器内部进行的。
    当省级一个集群的时候，需要注意每个组件的版本匹配。 kubeadm upgrade plam 命令对观测此类信息非常有用。

Control Plane Node (cp Node)

Kubernetes cp 为集群运行各种服务器和管理器进程。随着软件的成熟，新的组件被创建来处理专用需求，例如云控制器管理器(cloud-controller-manager)；它处理曾经由kube-controller-manager处理的任务，以便与其他工具交互，例如用于第三方集群管理和报告的 Rancher 或 DigitalOcean。

有几个附加组件对于典型的生产集群至关重要，例如 DNS 服务。其他的是第三方解决方案，Kubernetes 尚未开发本地组件，例如集群级别的日志记录和资源监控。

作为一个概念，负责确保集群当前状态与所需状态匹配的各种 Pod 称为控制平面(control plane)。

使用 kubeadm 构建集群时，kubelet 进程由 systemd 管理。运行后，它将启动/etc/kubernetes/manifests/中找到的每个 pod 。

control plane node 的组件

  • kube-apiserver

kube -apiserver是 Kubernetes 集群运行的核心。所有请求（包括内部和外部流量）均通过此代理处理。所有操作均由该代理接受并验证，并且它是与etcd数据库的唯一连接。它验证和配置 API 对象的数据，并为 REST 操作提供服务。因此，它充当整个集群的 cp 进程，并充当集群共享状态的前端。

Konnectivity 服务从 v1.18 中开始作为测试版功能，提供了将用户发起的流量与服务器发起的流量分开的能力。在开发这些功能之前，大多数网络插件都会混合流量，这会对性能、容量和安全性产生影响。

  • kube-scheduler

kube -scheduler使用一种算法来确定哪个节点将托管容器 Pod。调度程序将尝试查看要绑定的可用资源（例如卷），然后根据可用性和成功情况尝试重试部署 Pod。有多种方法可以影响算法，或者可以使用自定义调度程序。您还可以将 Pod 绑定到特定节点，但 Pod 可能由于其他设置而保持挂起状态。第一个参考的设置是 Pod 是否可以在当前配额限制内部署。如果是，则使用 Pod 的污点、容忍度和标签（the taints and tolerations, and labels of the Pods）以及节点的元数据来确定正确的放置位置。

  • etcd Database

集群的状态、网络和其他持久信息保存在etcd数据库中，或者更准确地说，保存在 b+tree 键值存储中。值始终附加到末尾，而不是查找和更改条目。然后，对数据的先前副本进行标记，以供将来通过压缩过程删除。它与curl和其他HTTP库一起使用，并提供可靠的监视查询。

更新值的同时请求都通过kube-apiserver传输，然后将请求一系列地传递给etcd 。第一个请求将更新数据库。第二个请求将不再具有相同的版本号，在这种情况下，kube-apiserver将向请求者回复错误 409。服务器端只负责提供响应，没有其它多余的逻辑，这意味着客户端需要预料到这一点并根据拒绝更新采取行动。

有一个领导者（Leader）数据库以及可能的追随者(followers)或正在加入集群的无投票权的学习者(non-voting Learners)。他们不断地相互沟通，以确定谁将成为领导者，并在发生失败时确定另一个领导者。虽然速度非常快并且可能很耐用，但新工具（例如kubeadm ）以及整个集群升级等功能却出现了一些问题。

虽然大多数 Kubernetes 对象都被设计为解耦的，但无需过多关注etcd即可终止的瞬态微服务是例外。事实上，整个集群的持久状态必须受到保护和保障。在升级或维护之前，您应该计划备份etcd。etcdctl命令允许快照保存和快照恢复。

  • Other Agents

kube -controller-manager是一个核心控制循环守护进程，它与kube-apiserver交互以确定集群的状态。如果状态不匹配，管理器将联系必要的控制器以匹配所需的状态。有几个正在使用的operators，例如端点endpoints、命名空间namespace和复制replication。随着 Kubernetes 的成熟，完整列表也在不断扩大。

自 v1.11 起仍处于测试阶段，云控制器管理器( ccm ) 与云外部的代理进行交互。它处理曾经由kube-controller-manager处理过的任务。这样可以在不改变核心 Kubernetes 控制流程的情况下实现更快的更改。每个 kubelet 必须使用传递给二进制文件的–cloud-provider-external设置。您还可以开发自己的 ccm，它可以作为守护程序集部署为树内部署或独立的树外安装。云控制器管理器是一个可选代理，需要几个步骤才能启用。您可以在线了解有关云控制器管理器的更多信息。

根据选择的网络插件，可能有各种 pod 来控制网络流量。为了处理 DNS 查询、Kubernetes 服务发现和其他功能，CoreDNS服务器已取代kube-dns。使用插件链（提供的或自定义编写的插件之一），服务器可以轻松扩展。

Worker Nodes

所有节点都运行 kubelet 和 kube-proxy，以及容器引擎，例如 Docker 或 cri-o，等等。部署其他管理守护进程来监视这些代理或提供 Kubernetes 中尚未包含的服务。

kubelet 与同样安装在所有节点上的底层容器引擎进行交互，并确保需要运行的容器确实正在运行。kube-proxy 负责管理容器的网络连接。它通过使用 iptables 条目来实现这一点。它还具有用户空间模式，在该模式下，它使用随机端口通过 ipvs 代理流量来监视服务和端点。根据所使用的插件，可能会找到网络插件 pod，例如 calico-node。

每个节点可以在不同的引擎中运行。Kubernetes 很可能会支持额外的容器运行时引擎。

Supervisord 是传统 Linux 环境中使用的轻量级进程监视器，用于监视和通知其他进程。在非 systemd 集群中，该守护进程可用于监控 kubelet 和 docker 进程。如果失败，它将尝试重新启动它们并记录事件。虽然不是典型安装的一部分，但有些人可能会添加此监视器以添加报告。

Kubernetes 还没有集群范围的日志记录。相反，使用另一个 CNCF 项目，称为Fluentd。实施后，它为集群提供一个统一的日志记录层，用于过滤、缓冲和路由消息。

集群范围的指标是另一个功能有限的领域。指标服务器 SIG 提供基本的节点和 Pod CPU 和内存利用率。对于更多指标，许多人使用 Prometheus 项目。