概念 - Kubernetes 组件

部署 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 的官方文档