本文档概述了功能齐全的Kubernetes集群所需要的多种二进制组件。
Master组件提供集群控制层。Master组件制定集群的总体决策(如调度),响应集群事件(当拷贝控制器的‘replicas’字段是‘unsatisfied’时启动新的Pod)。
Master组件可以在集群的任意机器运行。但简单起见,启动脚本通常在同一台机器上运行所有Master组件,并且不会在该机器上运行用户容器。多Master虚拟机设置的例子请参阅构建高可用性群集。
暴露Kubernetes API的组件。是Kubernetes控制层的前端。
被设计来进行水平扩展。通过部署更多实例来进行扩展。请参阅构建高可用性群集.。
连续高可靠的键值对存储,作为Kubernetes所有集群数据的备份。
始终为你的Kubernetes的etcd数据提供备份计划。更多etcd信息,请查看etcd文档。
监控没有分配节点的新建pod,并选择一个节点供它们运行。
用以决定调度安排的因素包括:个体和集体的资源需求、硬件/软件/政策约束、关联和非关联的规范、数据局部性、相互工作负载干涉和截至时间。
用来运行控制器的组件。
通常每个控制器是独立的进程。但为了减少复杂度,它们都被编译进一个可执行文件并在一个进程中运行。
这些控制器包括:
cloud-controller-manager运行与底层云供应商交互的控制器。cloud-controller-manager可执行程序是在Kubernetes1.6版本中引入的alpha功能。cloud-controller-manager只运行针对云供应商的控制器环。在kube-controller-manager中你必须禁用这些控制器环。你可以通过在启动kube-controller-manager时设置--cloud-provider标识为external来禁用。
cloud-controller-manager允许云供应商代码和Kubernetes代码独自演化。在之前的发布中,云供应商的特定代码需要云供应商自己维护,并且在运行Kubernetes时关联到cloud-controller-manager。
以下的控制器有云提供者依赖:
Node组件在每个节点上运行,维护运行时的pod并提供Kubernetes运行时环境。
在集群上每个节点运行的代理者。确保容器在pod上运行。
kubelet维持一套多种装置提供的PodSpecs,并确保这些PodSpecs所描述的容器是健康运行的。kubelet并不管理非 Kubernetes创建的容器。
kube-proxy允许Kubernetes服务通过 在主机上维护网络规则和执行连接转发 抽象
container runtime是对运行的容器负责的软件。Kubernetes提供多个runtime:Docker, containerd, cri-o, rktle和任意Kubernetes CRI (Container Runtime Interface)的实现.
插件是指实现集群功能的pods和服务。pods可以通过Deployments, ReplicationControllers等管理。名称空间插件对象在kube-system名称空间创建。
下面介绍精选的插件,更多可用插件查看Addons。
由于许多实例的依赖,所有Kubernetes集群都需要cluster DNS,其他插件则不是必须的。
Cluster DNS是一个DNS服务器,和你环境上其他DNS服务器一样,为Kubernetes服务提供DNS记录服务。
Kubernetes启动的容器会自动在它们的DNS搜索列表中包含这个DNS服务器。
Dashboard是Kubernetes集群基于web的通用UI。Dashboard允许用户对集群和集群上的应用进行管理和错误排查。
Container Resource Monitoring在中央数据库记录关于容器的普通时间序列指标,并提供UI来浏览这些数据。
Cluster-level logging构件负责保存容器日志到中央日志存储,并提供搜索存储接口。