企业建站平台,遂溪手机网站建设公司,重庆做学校网站公司,温州网站制作建设主要组件
k8s有如下的主要组件#xff1a;
Control plane(s) and worker node(s)OperatorsServicesPods of containersNamespaces and quotasNetwork and policiesStorage. 一个k8s集群是有一个或多个 cp#xff08;控制平面#xff09;节点和一组worker 节点组成的。这个…主要组件
k8s有如下的主要组件
Control plane(s) and worker node(s)OperatorsServicesPods of containersNamespaces and quotasNetwork and policiesStorage. 一个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数据库中或者更准确地说保存在 btree 键值存储中。值始终附加到末尾而不是查找和更改条目。然后对数据的先前副本进行标记以供将来通过压缩过程删除。它与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 项目。
