Kubernetes 容器编排初学者指南

去年秋天，我加入了一个新团队，该团队依赖 Kubernetes (K8s) 作为其核心基础设施的一部分。虽然我曾经使用过各种容器编排器（例如，Kubernetes、Apache Mesos、Amazon ECS），但这次工作变动让我重新回到基础知识。如果您正在使用 Kubernetes，以下是我对您应该熟悉的基石的看法。

容器编排是指用于自动化、管理和调度由单个容器定义的工作负载的工具和平台。这个领域有很多参与者，包括开源和专有，包括 Hashicorp 的 Nomad、Apache Mesos、Amazon 的 ECS，以及不要忘记 Google 自主研发的 Borg 项目（Kubernetes 从该项目 演变而来）。每种技术都有其优点和缺点，但 Kubernetes 日益普及和强大的社区支持清楚地表明，Kubernetes 目前是容器编排领域的王者。

当您使用开源软件时，我也认为 Kubernetes 具有明显的优势。作为一个<0xC2><0xA0>开源平台，它是云无关的，并且在它之上构建其他开源软件是有意义的。它还拥有超过 40,000 名贡献者的忠实拥护者，并且由于许多开发人员已经熟悉 Kubernetes，因此用户可以更轻松地集成基于 K8s 构建的开源解决方案。

将 Kubernetes 分解为构建模块

分解 Kubernetes 最简单的方法是查看容器编排器的核心概念。有容器，它们充当

工作的基础构建模块，然后是在彼此之上构建的组件，以将系统连接在一起。

组件分为两种核心类型

1. 工作负载管理器： 一种托管和运行容器的方式
2. 集群管理器： 代表集群做出全局决策的全局方式

在 Kubernetes 术语中，这些角色由工作节点和管理工作（即 Kubernetes 组件）的控制平面来履行。

管理工作负载

Kubernetes 工作节点具有嵌套的组件层。基础层是容器本身。

从技术上讲，容器在 Pod 中运行，Pod 是 Kubernetes<0xC2><0xA0>集群中的原子对象类型。以下是它们之间的关系

• Pod： Pod 定义了应用程序的逻辑单元；它可以包含一个或多个容器，并且每个 Pod 都部署到一个节点上。
• 节点： 这是充当集群中工作节点的虚拟机；Pod 在节点上运行。
• 集群： 这由工作节点组成，并由控制平面管理。

每个节点都运行一个名为 kubelet 的代理，用于在 Pod 中运行容器，以及一个 kube-proxy，用于管理网络规则。

管理集群

工作节点管理容器，而 Kubernetes 控制平面对集群做出全局决策。

控制平面由几个基本组件组成

• 内存存储 (etcd)： 这是所有集群数据的后端存储。虽然可以使用不同的后端存储运行 Kubernetes 集群，但 etcd（一个开源分布式键值存储）是默认设置。
• 调度器 (kube-scheduler)： 调度器负责将新创建的 Pod 分配给适当的节点。
• API 前端 (kube-apiserver)： 这是开发人员可以与 Kubernetes 交互的网关——用于部署服务、获取指标、检查日志等。
• 控制器管理器 (kube-controller-manager)： 它监视集群并进行必要的更改，以使集群保持在所需状态——例如扩展节点、维护每个复制控制器的正确 Pod 数量以及创建新命名空间。

控制平面做出决策以确保集群的正常运行，并抽象出这些决策，以便开发人员不必担心它们。它的功能非常复杂，系统的用户需要了解控制平面的逻辑约束，而不会过于陷入细节。

使用控制器和模板

集群的组件决定了集群如何管理自身——但是开发人员或（人工）操作员如何告诉集群如何运行软件？这就是 控制器 和模板的用武之地。

控制器协调 Pod，而 K8s 针对不同的用例具有不同类型的控制器。但关键的控制器是 Jobs，用于运行到完成的一次性作业，以及 ReplicaSets，用于运行提供服务的指定的一组相同的 Pod。

与 Kubernetes 中的其他所有内容一样，这些概念构成了更复杂系统的构建模块，这些系统允许开发人员运行弹性服务。建议您使用 Deployments 而不是直接使用 ReplicaSets。Deployments 代表用户管理 ReplicaSets，并允许滚动更新。Kubernetes Deployments 确保在更新时仅关闭某些 Pod，从而实现零停机部署。同样，CronJobs 管理 Jobs，并用于运行计划的和重复的进程。K8s 的多层结构允许更好的自定义，但 CronJobs 和 Deployments 足以满足大多数用例。

一旦您知道选择哪个控制器来运行您的服务，您将需要使用模板来配置它。

模板的结构

Kubernetes 模板是一个 YAML 文件，它定义了容器运行所依据的参数。与任何类型的配置即代码一样，它都有自己的特定格式和要求，可能需要学习很多东西。值得庆幸的是，您需要提供的信息与您针对任何容器编排器运行代码时所需的信息相同

• 告诉它应用程序的名称
• 告诉它在哪里查找容器的镜像（通常称为容器注册表）
• 告诉它要运行多少个实例（在上面的术语中，即 ReplicaSets 的数量）

图片来源

^{（Jiaqi Liu，CC BY-SA 4.0）}

配置的灵活性是 Kubernetes 的众多优势之一。借助不同的资源和模板，您还可以向集群提供有关以下方面的信息

• 环境变量
• 密钥的位置
• 应为容器挂载以供使用的任何数据卷
• 每个容器或 Pod 允许使用的 CPU 和内存量
• 容器应运行的特定命令

以及更多。

整合在一起

组合来自不同 资源 的模板允许用户在 Kubernetes 中互操作组件，并根据自己的需求进行自定义。

在更大的生态系统中，开发人员利用 Jobs、Services 和 Deployments 以及 ConfigMaps 和 Secrets 组合成一个应用程序——所有这些都需要在部署期间仔细协调。

管理这些协调步骤可以手动完成，也可以使用常见的软件包管理选项之一。虽然绝对有可能针对 Kubernetes API 推出自己的部署，但打包您的配置通常是一个好主意——特别是如果您要交付可能由团队中非直接成员部署和管理的开源软件。

Kubernetes 的首选软件包管理器是 Helm。 开始使用 Helm 不需要太多操作，它允许您打包自己的软件以便在 Kubernetes 集群上轻松安装。

一帆风顺！

容器之上坐着的许多层和扩展可能会使容器编排器难以理解。但是，一旦您分解了各个部分并了解它们如何交互，实际上一切都非常优雅。就像一个真正的管弦乐队一样，您会对每种乐器产生欣赏，并观看和谐的融合。

了解基本原理使您能够识别和应用模式，并从一个容器编排器转移到另一个容器编排器。