-
引言
-
当你部署完kubernetes时, 便拥有了一个完整的一套集群
-
一个kubernetes集群是由一组被称作节点(node)的机器组成,这些节点上会运行由kubernetes所管理的容器化应用。且每个集群至少有一个工作节点。
-
工作节点会托管所谓的Pods,而pod就是作为应用负载的组件。控制平面管理集群中的工作节点和pods。为集群提供故障转移和高可用性,这些控制平面一般跨多主机运行,而集群也会跨多个节点运行。
本文档概述了一个正常运行的kubernetes集群所需的各种组件
kubernetes集群的组件
-
控制平面组件(Control Plane Components)
-
控制平面组件会为集群做出全局决策,比如资源的调度。以及检测和响应集群事件,例如当不满足部署的replicas字段时,要启动新的pod(pod表示你在集群上一组正在运行的容器)。
-
控制平面组件可以在集群中的任何节点上运行。然而,为了简单起见,设置脚本通常会在同一个计算机上启动所有控制平面组件,并且不会在此计算机上运行用户容器。
-
kube-apisever
-
API服务器是kubernetes控制平面(控制平面是指容器编排层,它暴露API和接口来定义、部署容器和管理容器的生命周期)的组件,该组件负责公开了kubernetes API,负责处理接受请求的工作。API服务器是kubernetes控制平面的前端。
-
kubernetes API服务器的主要实现的是kube-apiserver。kube-apiserver设计上考虑了水平扩缩,也就是说,它可通过部署多个实例来进行扩缩。你可以运行kube-apiserver的多个实例,并在这些实例之间平衡流量。
-
etcd
-
etcd是兼顾一致性与高可用性的键值数据库,可以作为保存kubernetes所有集群数据的后台数据库。
-
你的kubernetes集群的etcd数据库通常需要有个备份计划。
-
kube-scheduler
-
kube-scheduler是控制平面的组件,负责监视新创建的、未指定运行节点(node)(kubernetes中的工作机器称作节点)的pods,并选择节点来让pod在上面运行。
-
调度决策考虑的因素包括单个pod及pods集合的资源需求、软硬件及策略约束、亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
-
kube-controller-manager
-
kube-controller-manager是控制平面的组件,负责运行控制器(控制器通过apiserver监控集群的公共状态,并致力于将当前状态转变为期望的状态)进程。
-
从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在同一个进程中运行。
这些控制器包括:
-
节点控制器(node controller):负责在节点出现故障时进行通知和响应。
-
任务控制器(job controller):监测代表一次性任务的job对象,然后创建pods来运行这些任务直至完成。
-
端点控制器(endpoints controller):填充端点(endpoints)对象(即加入service与pod)。
-
服务账户和令牌控制器(service account & token controllers):为新的命名空间创建默认账户和API访问令牌
-
cloud-controller-manager
-
cloud-controller-manager是指嵌入特定云的控制逻辑之控制平面组件。cloud-controller-manager允许你将你的集群连接到云提供商的API之上,并将与该云平台交互的组件同与你的集群交互的组件分离开来。
-
cloud-controller-manager仅运行特定于云平台的控制器。因此如果你在自己的环境中运行kubernetes,或者在本地计算机中运行学习环境,所部署的集群不需要有云控制器管理器。
-
与kube-controller-manager类似,cloud-controller-manager将若干逻辑上独立的控制回落组合到同一个可执行文件中,供你以同一进程的方式运行。你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。
下面的控制器都包含对云平台驱动的依赖:
-
节点控制器(node controller):用于在节点终止响应后检查云提供商以确定节点是否已被删除
-
路由控制器(route controller):用于在底层云基础架构中设置路由
-
服务控制器(service controller):用于创建、更新和删除云提供商负载均衡器
-
Node组件
节点组件会在每个节点上运行,负责维护运行的pod并提供kubernetes运行环境。‘
-
kubelet
-
kubelet会在集群中每个节点(node)上运行。它保证容器(container)(容器是可移植、可执行的轻量级的镜像,镜像中包含软件及其相关依赖 )都运行在pod中。
-
kubelet接收一组通过各类机制提供给它的podspecs,确保这些podspecs中描述的容器处于运行状态且健康。kubelet不会管理不是由kubernetes创建的容器。
-
kube-proxy
-
kube-proxy是集群中每个节点(node)所上运行的网络代理,实现kubernetes服务(service)(将运行在一组pods上的应用程序公开为网络服务的抽象方法)概念的一部分。
-
kube-proxy维护节点上的一些网络规则,这些网络规则会允许从集群内部或外部的网络会话与pod进行网络通信。
-
如果操作系统提供了可用的数据包过滤层,则kube-proxy会通过它来实现网络规则。否则,kube-proxy仅做流量转发。
-
容器运行时(container runtime)
-
容器运行环境是负责运行容器的软件。
-
kubernetes支持许多容器运行环境,例如docker(docker是一种可以提供操作系统的虚拟化(也称容器)的软件技术)、containerd(强调简单性、健壮性和可移植性的一种容器运行时)、CRI-O(专用于kubernetes的轻量级容器运行时软件)以及kubernetes CRI (容器运行环境接口)的其他任何实现。
-
插件(Addons)
-
插件使用kubernetes资源(daemonset(确保pod副本在集群中的一组节点上运行。)、deployment(deployment是管理应用副本的API对象)等)实现集群功能。 因为这些插件提供集群级别的功能,插件中命名空间域的资源属于kube-system命名空间。
-
DNS
-
尽管其他插件都并非严格意义上的必需组件,但几乎所有kubernetes集群都应该有集群DNS,因为很多示例都需要DNS服务。
-
集群DNS是一个DNS服务器,和环境中的其他DNS服务器一起工作,它为kubernetes服务提供DNS记录。
-
kubernetes启动的容器自动将此DNS服务器包含在其DNS搜索列表中。
-
Web界面(仪表盘)
-
dashboard是kubernetes集群的通用的、基于web的用户界面。它使用户可以管理集群中运行的应用程序以及集群本身,并进行故障排除。
-
容器资源监控
-
容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中,并提供浏览这些数据的界面。
-
集群层面日志
-
集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中,这种集中日志存储提供搜索和浏览接口。