什么是 Kubernetes 架构？ 重要性+最佳实践

自 2014 年以来，Kubernetes 在采用方面经历了巨大的增长。受 Google 内部集群管理解决方案 Borg 的启发，Kubernetes 简化了应用程序的部署和管理。 与所有容器编排软件一样，Kubernetes 在 IT 专业人士中越来越受欢迎，因为它安全且简单。 然而，与所有工具一样，了解其架构如何帮助您更有效地使用它。

让我们了解 Kubernetes 架构的基础，从它是什么、它做什么以及为什么重要开始。

谷歌创建了适应性强的 Kubernetes 容器管理系统，它可以跨多种设置处理容器化应用程序。 它有助于自动化容器化应用程序部署、进行更改以及扩展和缩减这些应用程序。

不过，Kubernetes 不仅仅是一个容器编排器。 同样，桌面应用程序可以在 MacOS、Windows 或 Linux 上运行； 它是云原生应用程序的操作系统，因为它充当这些程序的云平台。

什么是容器？

容器是一种用于打包应用程序及其依赖项的标准方法，以便可以轻松地跨运行时环境执行应用程序。 使用容器，您可以采取基本措施，通过将应用程序的代码、依赖项和配置打包到一个易于使用的构建块中来减少部署时间和提高应用程序的可靠性。

公司应用程序中的容器数量可能变得难以管理。 为了充分利用您的容器，Kubernetes 可以帮助您编排它们。

Kubernetes 有什么用？

Kubernetes 是一个用于运行容器工作负载的适应性和可扩展性极强的平台。 Kubernetes 平台不仅提供创建云原生应用程序的环境，还有助于管理和自动化部署。

它旨在减轻应用程序运营商和开发人员协调底层计算、网络和存储基础设施的工作，使他们能够专注于以容器为中心的自助服务操作流程。 开发人员还可以创建专门的部署和管理程序，以及由多个容器组成的应用程序的更高级别的自动化。

Kubernetes 可以处理所有重要的后端工作负载，包括单体应用程序、无状态或有状态程序、微服务、服务、批处理作业以及介于两者之间的一切。

通常选择 Kubernetes 有以下好处。

• Kubernetes 的基础架构优于许多 DevOps 技术。
• Kubernetes 将容器分解成更小的组件以进行精确管理。
• Kubernetes 会快速且定期地部署软件更新。
• Kubernetes 提供了一个用于开发云原生应用程序的平台。

Kubernetes 架构和组件

基本的 Kubernetes 架构包含许多组件，也称为 K8s 组件，因此在我们开始之前，记住以下概念很重要。

• 基本的 Kubernetes 架构由管理节点和执行容器化应用程序的工作节点的控制平面组成。
• 当控制平面管理执行和通信时，工作节点实际上运行这些容器。
• 一个 Kubernetes 集群是一组节点，每个集群至少有一个工作节点。

Kubernetes 架构图

Kubernetes 控制平面

控制平面是 Kubernetes 集群设计的中枢神经系统中心，容纳了集群的控制组件。 它还记录集群中所有 Kubernetes 对象的配置和状态。

Kubernetes 控制平面与计算单元保持定期通信，以确保集群按预期运行。 控制器监督对象状态并使系统对象的物理、观察状态或当前状态适应所需的状态或规范以响应集群变化。

控制平面由几个基本元素组成，包括应用程序编程接口 (API) 服务器、调度程序、控制器管理器和 etcd。 这些基本的 Kubernetes 组件保证容器在适当的资源下运行。 这些组件都可以在单个主节点上运行，但许多公司将它们复制到多个节点上以实现高可用性。

1. Kubernetes API 服务器

Kubernetes API 服务器是 Kubernetes 控制平面的前端。 它通过为各种应用程序提供 API 管理来促进更新、扩展、配置数据和其他类型的生命周期编排。 因为 API server 是网关，所以用户必须能够从集群外部访问它。 在这种情况下，API 服务器是通往 pod、服务和节点的隧道。 用户通过 API 服务器进行身份验证。

2. Kubernetes 调度器

kube-scheduler 记录每个计算节点的资源利用率统计信息，评估集群是否健康，并决定是否部署新容器以及在何处部署新容器。 调度程序评估集群的整体健康状况和 pod 的资源需求，例如中央处理器 (CPU) 或内存。 然后它选择合适的计算节点并调度任务、pod 或服务，考虑资源约束或保证、数据局部性、服务质量要求、反亲和性或亲和性标准。

3. Kubernetes控制器管理器

在 Kubernetes 环境中，多个控制器管理端点（pod 和服务）、令牌和服务帐户（命名空间）、节点和复制（自动缩放）的状态。 kube-controller 管理器，通常称为云控制器管理器或控制器，是一个守护进程，通过执行各种控制器职责来管理 Kubernetes 集群。

控制器在运行 Kubernetes 核心控制循环时监控集群中的对象。 它通过 API 服务器监视它们的期望状态和现有状态。 如果被管理对象的当前状态和预期状态不匹配，控制器会采取纠正措施，使对象状态更接近所需状态。 Kubernetes 控制器还处理基本的生命周期任务。

4.等

etcd 是一个分布式、容错的键值存储数据库，用于保存配置数据和集群状态信息。 尽管 etcd 可以独立设置，但它通常作为 Kubernetes 控制平面的一部分。

集群状态使用 raft 共识算法保存在 etcd 中。 这有助于处理复制状态机上下文中的典型问题，并且需要许多服务器就值达成一致。 Raft 建立了 leader、candidate 和 follower 三种角色，通过投票选出 leader 来达成共识。

因此，etcd 是所有 Kubernetes 集群组件的单一真实来源 (SSOT)，响应控制平面查询并收集有关容器、节点和 pod 状态的不同信息。 etcd 还用于存储配置信息，如 ConfigMap、子网、机密和集群状态数据。

Kubernetes 工作节点

工作节点是运行控制平面管理的容器的系统。 kubelet——核心 Kubernetes 控制器——在每个节点上运行，作为与控制平面交互的代理。 此外，每个节点都运行一个容器运行时引擎，例如 Docker 或 rkt。 用于监视、日志记录、服务发现和可选附加功能的其他组件也在该节点上运行。

一些关键的 Kubernetes 集群架构组件如下。

节点

一个 Kubernetes 集群必须至少有一个计算节点，但根据容量需求可以有更多。 因为 Pod 是协调和调度在节点上执行的，所以需要额外的节点来增加集群容量。 节点执行 Kubernetes 集群的工作。 它们链接应用程序以及网络、计算和存储资源。

数据中心中的节点可能是云原生虚拟机 (VM) 或裸机服务器。

容器运行时引擎

每个计算节点都使用容器运行时引擎来运行和管理容器生命周期。 Kubernetes 支持开放容器倡议兼容的运行时，如 Docker、CRI-O 和 rkt。

Kubelet 服务

每个计算节点上都包含一个 kubelet。 它是一个与控制平面通信以保证 pod 中的容器正常运行的代理。 当控制平面要求在节点中执行特定操作时，kubelet 通过 API 服务器获取 Pod 规范并进行操作。 然后确保相关容器处于良好的工作状态。

Kube 代理服务

每个计算节点都有一个称为 kube-proxy 的网络代理，它有助于 Kubernetes 网络服务。 为了管理集群内外的网络连接，kube-proxy 要么转发流量，要么依赖于操作系统的包过滤层。

kube-proxy 进程在每个节点上运行，以确保服务对其他方可用，并处理特定的主机子网划分。 它在其节点上充当网络代理和服务负载平衡器，处理用户数据报协议 (UDP) 和传输控制协议 (TCP) 流量的网络路由。 实际上，kube-proxy 为所有服务端点路由流量。

豆荚

到目前为止，我们已经介绍了内部和基础设施相关的想法。 然而，Pod 对 Kubernetes 至关重要，因为它们是开发人员与之交互的主要外向组件。

Pod 是 Kubernetes 容器模型中最简单的单元，代表应用程序的单个实例。 每个 Pod 包含一个容器或几个紧密相关的容器，这些容器在逻辑上组合在一起并执行管理容器功能的规则。

Pod 的寿命有限，在升级或缩减后最终会死亡。 虽然是短暂的，但它们通过连接到持久存储来执行有状态的应用程序。

Pod 也可以水平扩展，这意味着它们可以增加或减少运行的实例数量。 他们还能够进行滚动更新和金丝雀部署。

Pod 一起在节点上运行，因此它们共享内容和存储，并且可以通过本地主机与其他 Pod 通信。 容器可能跨越多台计算机，pod 也可以。 一个节点可以操作多个 pod，每个 pod 收集许多容器。

Pod 是 Kubernetes 生态系统中的中央管理单元，作为共享资源和上下文的容器的逻辑边界。 Pod 分组方法允许多个依赖进程同时运行，从而减轻了虚拟化和容器化之间的差异。

其他 Kubernetes 架构组件

Kubernetes 维护应用程序的容器，但也可以管理集群中的关联应用程序数据。 Kubernetes 的用户可以在不了解底层存储基础设施的情况下请求存储资源。

Kubernetes 卷是 pod 可以访问和存储数据的目录。 卷类型决定了卷的内容、它是如何形成的以及支持它的媒体。 持久卷 (PV)是特定于集群的存储资源，通常由管理员提供。 PV 也可以比给定的 pod 更长寿。

Kubernetes 依赖于存储在容器注册表中的容器映像。 它可能是第三方注册或组织创建的注册。

命名空间是存在于物理集群中的虚拟集群。 它们旨在为众多用户和团队创建独立的工作环境。 他们还通过限制他们可以访问的 Kubernetes 对象来防止团队相互干扰。 Pod 内的 Kubernetes 容器可以通过本地主机与其他 Pod 通信，并共享 IP 地址和网络命名空间。

Kubernetes 与 Docker Swarm

Kubernetes 和 Docker 都是提供容器管理和应用扩展的平台。 Kubernetes提供了一种有效的容器管理解决方案，非常适合具有复杂设置的高需求应用程序。 相比之下， Docker Swarm是为简单而构建的，使其成为快速部署和维护的基本应用程序的绝佳选择。

• Docker Swarm 比 Kubernetes 更容易部署和配置。
• Kubernetes 提供基于流量的一体式可扩展性，而 Docker Swarm 优先考虑快速扩展。
• 自动负载平衡在 Docker Swarm 中可用，但在 Kubernetes 中不可用。 但是，第三方解决方案可能会将外部负载均衡器链接到 Kubernetes。

贵公司的需求决定了正确的工具。

容器编排解决方案

容器编排系统使开发人员能够启动多个容器以进行应用程序部署。 IT 经理可以使用这些平台来自动管理实例、采购主机和连接容器。

以下是一些最好的容器编排工具，它们可以促进部署、识别失败的容器实施以及管理应用程序配置。

Kubernetes 架构最佳实践和设计原则

实施考虑安全性、治理、监控、存储、网络、容器生命周期管理和编排的平台战略至关重要。 然而，Kubernetes 在采用和扩展方面具有广泛的挑战性，特别是对于同时管理本地和公共云基础设施的企业而言。 为了简化它，下面讨论了在构建 kubernetes 集群时必须考虑的一些最佳实践。

• 确保您始终拥有最新版本的 Kubernetes。
• 投资于开发和运营团队的培训。
• 建立全公司治理。 确保您的工具和提供程序与 Kubernetes 编排兼容。
• 通过在持续集成和交付 (CI/CD) 工作流程中包含图像扫描技术来提高安全性。 从 GitHub 存储库下载的开源代码应始终谨慎对待。
• 在整个集群中实施基于角色的访问控制(RBAC)。 基于最小特权和零信任的模型应该成为规范。
• 仅使用非 root 用户并将文件系统设置为只读以进一步保护容器。
• 避免使用默认值，因为简单的声明不容易出错并且可以更好地传达目的。
• 在使用基本的 Docker Hub 镜像时，要小心，因为它们可能包含恶意软件或被不需要的代码所淹没。 从精简、干净的代码开始，逐步提升。 较小的图片增长得更快，占用的存储空间更少，拉取图像的速度也更快。
• 使容器尽可能简单。 每个容器一个进程允许编排器报告该进程是否健康。
• 有疑问时崩溃。 不要在失败时重启，因为 Kubernetes 会重启失败的容器。
• 具有描述性。 描述性标签有利于现在和未来的开发人员。
• 说到微服务，不要太具体。 逻辑代码组件中的每个功能都不能是它的微服务。
• 在可能的情况下，自动化。 您可以通过自动化 CI/CD 工作流来完全跳过手动 Kubernetes 部署。
• 使用 liveliness 和 readiness 探针来协助管理 pod 生命周期； 否则，Pod 可能会在初始化或接收用户请求之前就被终止。

考虑你的容器

由于容器在企业中的广泛使用，以容器为中心的管理软件 Kubernetes 已成为部署和运行容器化应用程序的事实标准。 Kubernetes 架构简单直观。 虽然它使 IT 经理能够更好地控制其基础架构和应用程序性能，但要充分利用该技术还有很多东西需要学习。

想进一步探索这个主题？ 了解容器化在云计算中日益增长的相关性！