k8s 架构

主要组件

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 命令对观测此类信息非常有用。
    k8s 架构_第1张图片

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 项目。

你可能感兴趣的:(kubernetes,架构,容器)