kubernetes 编排_Kubernetes容器编排初学者指南

kubernetes 编排

去年秋天，我在一个依赖Kubernetes （K8s）作为其核心基础架构一部分的团队中担任了新职务。 虽然我当时曾与各种容器协调器（例如Kubernetes，Apache Mesos，Amazon ECS）一起工作，但工作的变化使我回到了基础上。 如果您使用Kubernetes，这是我应该熟悉的基础知识。

容器编排是指用于自动化，管理和调度由各个容器定义的工作负载的工具和平台。 这个领域有很多参与者，包括开源的和专有的，包括Hashicorp的Nomad ， Apache Mesos ，Amazon的ECS ，并且不要忘了Google的Borg项目（Kubernetes就是从此发展而来的 ）。 每种技术都有优点和缺点，但是K​​ubernetes的日益普及和社区的强大支持清楚地表明，Kubernetes当前是容器协调器之王。

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

将Kubernetes分解为构建块

分解Kubernetes的最简单方法是查看容器协调器的核心概念。 有一些容器，用作

组件有两种核心类型：

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

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

管理工作量

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

从技术上讲，容器在容器中运行，容器是Kubernetes集群中的原子对象类型。 它们之间的关系如下：

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

每个节点运行被称为代理kublet用于在吊舱和一运行容器KUBE代理用于管理网络的规则。

管理集群

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

控制平面包含几个基本组件：

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

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

使用控制器和模板

集群的组件决定了集群如何进行自我管理，但是开发人员或（人工）操作员如何告诉集群如何运行软件？ 这是控制器和模板进入的地方。

控制器编排吊舱，K8针对不同的用例使用不同类型的控制器。 但是关键的是Jobs （用于完成一次完成的作业）和ReplicaSets （用于运行一组指定的提供服务的相同容器） 。

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

一旦知道选择哪个控制器来运行服务，就需要使用模板对其进行配置。

模板剖析

Kubernetes模板是一个YAML文件，用于定义容器运行所用的参数。 就像任何形式的代码配置一样，它具有自己的特定格式和要求，需要学习很多东西。 值得庆幸的是，您需要提供的信息与您针对任何容器协调器运行代码相同：

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

配置的灵活性是Kubernetes的众多优势之一。 使用不同的资源和模板，您还可以提供有关以下内容的集群信息：

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

而这样的例子不胜枚举。

汇集全部

结合来自不同资源的模板，用户可以互操作Kubernetes中的组件，并根据自己的需求对其进行自定义。

在更大的生态系统中，开发人员可以通过结合使用ConfigMap和Secrets的 Jobs， Services和Deployments来组合成一个应用程序，在部署过程中需要仔细地精心安排所有这些。

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

Kubernetes首选的软件包管理器是Helm 。 使用Helm并不需要花很多时间，它使您可以打包自己的软件，以便在Kubernetes集群上轻松安装。

一帆风顺！

位于容器顶部的许多层和扩展可能会使容器协调器难以理解。 但是，一旦您分解了各个部分并了解它们之间的相互作用，它实际上就非常优雅。 就像真正的乐团一样，您会欣赏每种乐器，并欣赏和声。

了解基础知识可以使您识别并应用模式，并从一个容器协调器转到另一个容器协调器。

翻译自: https://opensource.com/article/20/6/container-orchestration

kubernetes 编排