亮点
- Kubernetes 架构基于控制平面/工作节点模型。
- Kubernetes 集群应该安全可靠、易于使用且可扩展。
- 集群包含两部分：负责全局决策的控制平面，以及运行应用的节点。
- 在开箱即用状态下，Kubernetes 并未提供以下几项能力：让不同节点上的 Pod 相互通信、在内部路由互联网流量，以及轻松查看日志。
- Kubernetes 提供了用于编排大型、复杂容器化应用的工具，但大量设计决策仍需由用户自行确定。
什么是 Kubernetes 架构？
Kubernetes 架构基于控制平面/工作节点模型。它将集群划分为两个主要层：控制平面（负责做出全局决策并管理集群）和工作节点（在容器内实际运行应用）。
只要您稍微了解 Kubernetes 的基础知识，您就知道它是一个用于大规模运行分布式应用和服务的开源容器编排平台。但是，您可能并不了解它的组件，以及这些组件的交互方式。
我们先来简要了解一下 Kubernetes 的设计原则，然后再解析 Kubernetes 的不同组件如何协同工作。
Kubernetes 的设计原则是什么？
正如 Kubernetes 实施细节中所述，Kubernetes 集群的设计基于三项原则。
Kubernetes 集群应该：
- 安全可靠。它应遵循最新的安全最佳实践。
- 易于使用。它应能通过一些简单的命令进行操作。
- 可扩展。不应偏向于某一个提供商，而是能通过配置文件进行自定义。
红帽 Kubernetes 高级集群管理
Kubernetes 控制平面的内部运作
Kubernetes 控制平面是集群的“大脑”。它可做出全局决策（例如调度应用），检测集群事件并对其作出响应，同时确保集群的实际状态与您声明的预期状态保持一致。
Kubernetes 控制平面内包含用于控制集群的组件，以及关于集群状态和配置的数据。这些核心 Kubernetes 组件负责处理重要的工作，确保容器以足够的数量和所需的资源运行。
控制平面会一直与您的计算机保持联系。您已将集群配置为以特定方式运行，控制平面负责确保集群按该方式运行。
kube-apiserver
Kubernetes API 是 Kubernetes 控制平面的前端，用于处理内部和外部请求。API 服务器会确定请求是否有效，如果有效，则对其进行处理。您可以通过 REST 调用、kubectl 命令行界面或其他命令行工具（例如 kubeadm）来访问 API。
kube-scheduler
调度程序会考虑 Pod 的资源需求（例如 CPU 或内存）以及集群的运行状况。随后，它会将 Pod 安排到适当的计算节点。
kube-controller-manager
控制器负责实际运行集群，Kubernetes 控制器管理器则是将多个控制器功能合而为一。控制器用于查询调度程序，并确保有正确数量的 Pod 在运行。如果有 Pod 停止运行，另一个控制器会发现并做出响应。控制器会将服务连接至 Pod，以便让请求前往正确的端点。此外，还有一些控制器用于创建账户和 API 访问 token。
etcd
配置数据以及有关集群状态的信息位于 etcd（键值存储数据库）中。etcd 采用分布式、容错设计，被视为集群的最终事实来源。
Kubernetes 节点的内部运作
控制平面相当于大脑，Kubernetes 工作节点则是肌肉，它们负责实际运行应用的繁重工作。
Kubernetes 节点可以是物理机，也可以是虚拟机（VM）。节点内部会连续循环执行一系列操作：从控制平面接收指令、运行容器、管理网络和报告健康状态。
Kubernetes 集群中至少需要一个计算节点，但通常会有多个计算节点。Pod 经过调度和编排后，就会在节点上运行。如果需要扩展集群的容量，那就要添加更多节点。
Pod
Pod 是 Kubernetes 对象模型中最小、最简单的单元。它代表了应用的单个实例。每个 Pod 都由一个容器（或一系列紧密耦合的容器）以及若干控制容器运行方式的选件组成。Pod 可以连接到持久存储，以便运行有状态应用。
容器运行时引擎
为了运行容器，每个计算节点都有一个容器运行时引擎。Docker 就是其中一个例子，但 Kubernetes 也支持其他符合开源容器运动要求的运行时，例如 rkt 和 CRI-O。
kubelet
每个计算节点中都包含一个 kubelet，这是一个与控制平面通信的微型应用。kublet 可确保容器在 Pod 内运行。当控制平面需要在节点中执行某个操作时，kubelet 就会执行该操作。
kube-proxy
每个计算节点中还包含 kube-proxy，这是一个用于优化 Kubernetes 网络服务的网络代理。kube-proxy 负责处理集群内部或外部的网络通信，主要依靠操作系统的数据包过滤层，或者自行转发流量。
Kubernetes 集群还需要什么？
只要具备控制平面和工作节点，从技术层面来讲，您就已经拥有了一个 Kubernetes 集群。然而，它是完全“裸露”的。在开箱即用状态下，Kubernete 并未提供以下几项能力：让不同节点上的 Pod 相互通信、在内部路由互联网流量，以及轻松查看日志。
要让集群达到生产就绪状态，您需要安装附加组件和配套基础架构。
- 网络：Kubernetes 需要虚拟网络覆盖，以便 Pod 在不同节点之间无缝通信。必须安装 Cilium 或 Calico 等容器网络接口（CNI）插件，才能创建此网络层并为每个 Pod 分配唯一的 IP 地址。
- 入口控制器：内部流量会自动处理，但必须借助网关才能允许外部流量进入。入口控制器（例如 NGINX 或 Traefik）充当反向代理和负载均衡器，将外部互联网流量安全路由到集群内部的相应服务。
- 集群 DNS：由于 Pod 重启时 IP 地址会频繁发生变化，因此您无法对网络路径进行硬编码。集群 DNS 提供商（通常为 CoreDNS）会自动将永久域名映射到各项服务，确保应用之间始终能够相互发现。
- 存储置备程序：容器本质上是无状态的，这意味着一旦崩溃，其内部存储的所有数据都会被清除。容器存储接口（CSI）将集群连接到外部物理存储（例如云磁盘或 NFS），自动预配置并挂载永久硬盘驱动器，从而确保数据在重启后仍然有效。
- 可观测性技术栈：由于应用分散在多台机器上，因此故障排除需要集中式观测能力。Prometheus 和 Grafana 等工具可监控集群指标，FluentBit 等日志记录代理则可将容器日志聚合到单个可搜索的信息面板中。
Kubernetes 架构面临哪些挑战？
这份有关 Kubernetes 架构的概述只不过是走马观花。一旦您开始考虑这些组件之间以及与外部资源和基础架构如何通信，就会意识到在配置和保护 Kubernetes 集群方面所面临的挑战。
Kubernetes 提供了用于编排大型、复杂容器化应用的工具，但大量设计决策仍需由用户自行确定。您要选择操作系统、容器运行时、持续集成/持续交付（CI/CD）工具、应用服务、存储以及其他大多数组件。另外，还有管理角色、访问控制、多租户和安全默认设置等工作需要您来完成。不仅如此，您也可以选择自行运行 Kubernetes，或是与能够提供受支持版本的供应商展开合作。
这种选择自由正是 Kubernetes 灵活性的一大表现。尽管实施起来可能比较复杂，但 Kubernetes 赋予了您强大的功能，让您既能按照自己的方式运行容器化应用，又能灵活应对组织内的变化。
使用 Kubernetes 构建云原生应用
观看本网络培训课堂系列视频，获取专家视角，帮助您在需要构建、运行、部署应用并实现应用现代化的企业 Kubernetes 上建立数据平台。
为什么要选择红帽来应用 Kubernetes？
红帽是开源容器技术（包括 Kubernetes）的领导者和积极构建者，我们创建的一些基本工具可以帮助您保护、简化以及自动更新容器基础架构。
红帽® OpenShift® 是企业级 Kubernetes 发行版。借助红帽 OpenShift，团队可以获得一个集成式 DevOps 平台。红帽 OpenShift 可为开发人员提供他们所选的语言、框架、中间件和数据库，并可通过 CI/CD 来构建和部署自动化，以提高生产力。同时，我们还可提供一个专为容器而设计的数据和存储服务平台，即红帽 OpenShift 数据基础。
