今天继续学习Kubernetes里面的组件。当您部署 Kubernetes 时，您将获得一个集群。
一个 Kubernetes 集群由一组工作机器组成，称为 Nodes(节点)，运行容器化应用程序。每个集群至少有一个worker node(工作节点)。
工作节点托管 Pods它们是应用程序工作负载的组成部分。这 control plane(控制平面)管理集群中的worker nodes(工作节点)和 Pod。在生产环境中，控制平面通常运行在多台计算机上，一个集群通常运行多个节点，提供容错和高可用性。
本文档概述了完整且能工作的 Kubernetes 集群所需的各种组件。
控制平面组件
控制平面的组件对集群做出全局决策（例如，调度），以及检测和响应集群事件（例如，启动一个新的 Pod当部署的replicas字段不满足时）。
控制平面组件可以在集群中的任何机器上运行。但是，为简单起见，设置脚本通常会在同一台机器上启动所有控制平面组件，并且不在这台机器上运行用户容器。有关跨多个 VM 运行的示例控制平面设置，请参阅 使用 kubeadm 创建高可用性集群。
kube-apiserver
API 服务器是 Kubernetes控制平面的一个组件，它对外暴露 Kubernetes API。API 服务器是 Kubernetes 控制平面的前端。
Kubernetes API 服务器的主要实现是kube-apiserver。kube-apiserver 旨在水平扩展——也就是说，它通过部署更多实例来扩展。您可以运行多个 kube-apiserver 实例并平衡这些实例之间的流量。
etcd
一致且高度可用的键值存储用作 Kubernetes 的所有集群数据的后备存储。
如果您的 Kubernetes 集群使用 etcd 作为其后备存储，请确保您有这些数据的备份计划。
您可以在官方文档中找到有关 etcd 的深入信息。
kube 调度器
监视新创建的控制平面组件 Pods 没有分配 node(节点)，并选择一个节点供它们运行。
调度决策考虑的因素包括：个人和集体资源需求、硬件/软件/策略约束、关联和反关联规范、数据局部性、工作负载间干扰和截止日期。
kube-controller-manager
它是控制平面的组件以用来运行控制器处理的。
逻辑上，每个 控制器 是一个单独的进程，但为了降低复杂性，它们都被编译成一个二进制文件并在一个进程中运行。
这些控制器的某些类型是：
- Node controller（节点控制器）：负责在节点宕机时进行通知和响应。
- Job controller(作业控制器)：监视表示一次性任务的作业对象，然后创建 Pod 以运行这些任务直至完成。
- Endpoints 控制器：填充 Endpoints 对象（即加入 Services & Pods）。
- 服务帐户和令牌控制器：为新命名空间创建默认帐户和 API 访问令牌。
cloud-controller-manager
一个 Kubernetes control plane(控制平面)嵌入云特定控制逻辑的组件。云控制器管理器允许您将集群链接到云提供商的 API，并将与该云平台交互的组件与仅与您的集群交互的组件分开。
cloud-controller-manager仅运行特定于您的云提供商的控制器。如果您在自己的场所或自己 PC内的学习环境中运行 Kubernetes，则集群没有云控制管理器。
与 kube-controller-manager 一样，cloud-controller-manager 将几个逻辑上独立的控制循环组合成一个二进制文件，您可以将其作为单个进程运行。您可以水平扩展（运行多个副本）以提高性能或帮助容忍故障。
以下控制器可以具有云提供商依赖项：
- Node controller（节点控制器）：用于检查云提供商以确定节点在停止响应后是否在云中被删除
- Route controller（ 路由控制器）：用于在底层云基础设施中设置路由
- Service controller（服务控制器）：用于创建、更新和删除云提供商负载均衡器
Node Components (节点组件)
节点组件在每个节点上运行，维护正在运行的 Pod 并提供 Kubernetes 运行时环境。
kubelet
它是运行在集群中每个Pod(节点)的代理。它确保容器(container) 正在运行一个 Pod里.
kubelet 采用一组通过各种机制提供的 PodSpecs，并确保这些 PodSpecs 中描述的容器正在运行和健康。kubelet 不管理非Kubernetes 创建的容器。
kube-proxy
kube-proxy 是一个网络代理，运行在在您的集群中每个 Pod(节点) 里，实现部分 Kubernetes 服务 概念。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与您的 Pod 进行网络通信。
kube-proxy 使用操作系统数据包过滤层（如果有）并且可用。否则，kube-proxy 会自行转发流量。
Container runtime
容器运行时是负责运行容器的软件。
Kubernetes 支持多种容器运行时： Docker, container, CRI-O，以及Kubernetes CRI（Container Runtime Interface）的任何实现。
Addons(插件)
插件使用 Kubernetes 资源（DaemonSet(守护进程集), Deployment(部署)等）来实现集群功能。因为这些提供集群级别的功能，插件的命名空间资源属于kube-system命名空间。
选定的插件描述如下；有关可用插件的扩展列表，请参阅Addons(插件)。
DNS
虽然其他插件不是严格要求的，但所有 Kubernetes 集群都应该有cluster DNS，因为许多示例都依赖它。
除了环境中的其他 DNS 服务器之外，集群 DNS 是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。
Kubernetes 启动的容器会自动在其 DNS 搜索中包含此 DNS 服务器。
WebUI（仪表板）
仪表板是 Kubernetes 集群的通用、基于 Web 的 UI。它允许用户对集群中运行的应用程序以及集群本身进行管理和故障排除。
Container Resource Monitoring(容器资源监控)
Container Resource Monitoring在中央数据库中记录有关容器的通用时间序列指标，并提供用于浏览该数据的 UI。
Cluster-level Logging(集群级日志记录)
一个集群级别的日志记录机制是负责保存容器日志到中央日志存储与搜索/浏览界面。
参考 kubernetes.io文档
