部署 Kubernetes 时,我们将获得一个集群。
Kubernetes 集群由运行容器化应用的一组工作机,称为节点(Kubernetes 的工作节点),组成。每个集群至少有一个工作节点。
工作节点托管作为应用工作负载组件的 Pod(最小且最简单的 Kubernetes 对象,体现了集群里运行着的容器集)。舵面(暴露 API 和接口以定义、部署及管理容器生命周期的容器编排层)管理集群中的工作节点和 Pod。在生产环境中,舵面通常在多台计算机上运行,而集群通常在多个节点上运行,从而提供了容错能力和高可用性。
该指南概述了拥有完整且有效的 Kubernetes 集群所需的各种组件。
这是 Kubernetes 集群的示意图,其中所有组件都捆绑在一起。
舵面组件
舵面组件对集群进行全局决策(例如,调度),并检测和响应集群事件(例如,当部署的 replicas
字段不足时启动新的 Pod)。
舵面组件可以在集群中的任何计算机上运行。但是,为简单起见,搭建脚本通常在同一台计算机上启动所有舵面组件,并且不在该计算机上运行用户容器。有关注虚拟机搭建示例,请参阅构建高可用性集群(敬请期待~~)。
kube-apiserver
API 服务器是 Kubernetes 舵面的组件,该平台公开 Kubernetes API。API 服务器是 Kubernetes 舵面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver(敬请期待~~)。kube-apiserver 旨在水平扩展 - 即,它通过部署更多实例进行扩展。我们可以运行 kube-apiserver 的多个实例,并均衡这些实例之间的流量。
etcd
一致且高可用的键值存储用作 Kubernetes 所有集群数据后备存储。
如果我们的 Kubernetes 集群使用 etcd 作为其后备存储,请确保我们有这针对这些数据的备份(敬请期待~~)计划。
我们可以在官方文档中找到有关 etcd 的详细信息。
kube-scheduler
舵面组件,它监控没有分配节点的新创建的 Pod,并选择一个节点以使其运行。
计划决策要考虑的因素包括:个人和集体资源需求、硬件/软件/策略约束、亲和力和反亲和力规范、数据局部性、工作间干扰以及截止日期。
kube-controller-manager
运行控制器(通过 apiserver 监控集群共享状态控制回路,并作出变更以尝试从当前状态切换至期望的状态)进程的控制舵面组件。
逻辑上来说,每个控制器是一个单独的进程,但是为了降低复杂性,它们都被编译为单个二进制文件并在单个进程中运行。
这些控制器包括:
- 节点控制器:负责在节点出现故障时进行通知和响应;
- 复制控制器:负责为系统中的每个复制控制器对象维护正确数量的 Pod;
- 端点控制器:填充 “端点” 对象(即,加入 “Service 和 Pod”);
- 服务账户和令牌控制器:为新的名称空间创建默认账户和 API 访问令牌。
cloud-controller-manager
cloud-controller-manager(敬请期待~~) 运行与基础云提供商交互的控制器。cloud-controller-manager 二进制文件是 Kubernetes 1.6 版中引入的 aplha 功能。
cloud-controller-manager 仅运行 cloud-provider-specific 的控制器回路。我们必须在 kube-controller-manager 中禁用这些控制器回路。我们可以通过在启动 kube-controller-manager 时将 --cloud-provider 标志设置为 external 来禁用控制回路。
cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定于云供应商的代码来实现功能。在将来的版本中,云供应商专用的代码应由云供应商自己维护,并在运行 Kubernetes 时链接到 cloud-controller-manager。
以下控制器具有云供应商依赖性:
- 节点控制器:用于检查云供应商以确定节点停止响应后是否已在云中删除该节点;
- 路由控制器:用于在基础云基础架构中搭建路由;
- 服务控制器:用于创建、更新及删除云供应商负载均衡器;
- 卷控制器:用于创建、附加及安装卷,以及与云供应商交互以编排卷。
节点组件
节点组件在每个节点上运行,维护运行中的 Pod,并提供 Kubernetes 运行时环境。
kubelet
在集群中每个节点上运行的代码。确保容器(包含了软件及其所有依赖的轻量、可移植的可执行镜像)在 Pod 中运行。
kubelet 包含通过各种机制提供的一组 PodSpec,并确保这些 PodSpec 中描述的容器运行正常。Kubelet 不管理非 Kubernetes 创建的容器。
kube-proxy
kube-proxy 是一个网络代码,它在集群中的每个节点上运行,实现了 Kubernetes 服务(将 Pod 集中运行的应用曝光为网络服务的一种方式)概念的一部分。
kube-proxy(敬请期待~~) 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果有 kube-proxy,则 kube-proxy 使用操作系统包过滤层。否则,kube-proxy 会转发流量本身。
容器运行时
容器运行时是负责运行容器的软件。
Kubernetes 支持多种容器运行时:Docker、containerd、CRI-O,以及 Kubernetes CRI(容器运行时接口)的任何实现。
插件
插件使用 Kubernetes 资源(DaemonSet、Deployment 等)来实现集群功能。因为他们提供集群级功能,所以插件的命名空间资源属于 kube-system 命名空间。
所选的插件如下所述;有关可用插件的扩展列表,请参阅插件(敬请期待~~)。
DNS
虽然并非严格要求其他附加组件,但由于许多示例都依赖它,因此所有 Kubernetes 集群都应具有集群 DNS(敬请期待~~)。
除了我们环境中的其他 DNS 服务器之外,集群 DNS 还是一个 DNS 服务器,它为 Kubernetes 服务提供 DNS 记录。
由 Kubernetes 启动的容器会在其 DNS 搜索中自动包括该 DNS 服务器。
WEB UI(仪表盘)
仪表盘(敬请期待~~)是 Kubernetes 集群的通用的、基于 Web 的 UI。它允许用户管理集群中运行的应用以及集群本身并进行故障排除。
容器资源监控
容器资源监控(敬请期待~~)在中央数据库中记录有关容器的一般时间序列指标,并提供用于浏览该数据的 UI。
集群级别日志
集群级别日志(敬请期待~~)记录机制负责通过搜索/浏览界面将容器日志保存到中央日志存储中。
下一步怎么做
- 了解节点(敬请期待~~)
- 了解控制器(敬请期待~~)
- 了解 kube-scheduler(敬请期待~~)
- 阅读 etcd 的官方文档