容器编排是指用于自动化，管理和调度由各个容器定义的工作负载的工具和平台。在容器编排领域有很多参与者，开源工具和专有工具，如Hashicorp的Nomad，Apache Mesos，AWS的ECS等等，当然还有谷歌的Borg项目(Kubernetes就是从这个项目演变而来的)。每种技术都有其优缺点，但是Kubernetes的日益普及和社区的强大支持已经清楚地表明，Kubernetes目前是容器编排当之无愧的领导者了。
在使用开源软件时，Kubernetes具有明显的优势。作为一个开源平台，它可以在本地部署，并且在Kubernetes之上构建其他开源软件也很有意义。此外，作为最为活跃的开源生态之一，它有超过40000名的贡献者，并且由于许多开发人员已经熟悉Kubernetes，因此用户可以更轻松地集成基于Kubernetes的开源解决方案。
将Kubernetes分解为构建块
分解Kubernetes的最简单方法是查看容器编排的核心概念。有一些容器，用作基础工作模块，然后将各个组件构建在彼此之上，以将系统捆绑在一起。
组件有两种核心类型：
- 工作负载管理器：一种托管和运行容器的方法
- 集群管理器：代表集群决策的全局方法
在Kubernetes术语中，这些角色由工作节点和管理工作的控制平面(即Kubernetes组件)完成。
管理工作负载
Kubernetes工作节点具有嵌套的组件层。在基础层是容器本身。
集群及其组件
从技术上讲，容器在容器中运行，容器是Kubernetes集群中的原子对象类型。它们之间的关系如下：
- Pod：Pod定义了应用程序的逻辑单元;它可以包含一个或多个容器，并且每个Pod都部署到一个节点上。
- 节点(Node)：这是在集群中充当工作负载的虚拟机;Pod在节点上运行。
- 集群：由工作节点组成，由控制平面管理。
每个节点都运行一个称为kublet的代理，该代理用于在容器中运行容器，而一个kube-proxy用于管理网络规则。
管理集群
工作节点管理容器，Kubernetes控制平面对集群进行全局决策。
控制平面及其组件
控制平面包含几个基本组件：
- 内存存储(etcd)：这是所有集群数据的后端存储。虽然可以使用其他后备存储etcd运行Kubernetes集群，但默认情况下是开源分布式键值存储。
- 调度程序(kube-scheduler)：调度程序负责将新创建的Pod分配给适当的节点。
- API前端(kube-apiserver)：这是开发人员可以与Kubernetes进行交互的网关，以部署服务，获取指标，检查日志等。
控制器管理器(kube-controller-manager)：监控集群并进行必要的更改，以使集群保持所需的状态，例如扩展节点，为每个复制控制器维护正确的Pod数量以及创建新的命名空间。
控制平面做出决策以确保集群正常运行，并抽象化这些决策，让开发者不必担心它们。它的功能非常复杂，系统的用户需要了解控制平面的逻辑约束，而又不会陷入细节上。
使用控制器和模板
集群的组件决定了集群如何进行自我管理，但是开发者管理员如何告诉集群来运行软件?这是控制器和模板发挥作用的地方。
控制器编排Pod，而Kubernetes则针对不同的用例使用不同类型的控制器。但是关键的是Jobs(用于一次性完成的作业)和ReplicaSets(用于运行一组指定的提供服务的相同容器)。
像Kubernetes中的其他所有内容一样，这些概念构成了更复杂的系统的构建块，这些系统允许开发者运行弹性服务。建议不要直接使用ReplicaSets，而应该使用Deployments。部署代表用户管理ReplicaSet，并允许滚动更新。Kubernetes部署可确保仅在更新某些Pod时将它们关闭，从而实现零停机时间部署。同样，CronJobs管理作业，并用于运行计划的和重复的流程。Kubernetes的许多层都允许更好的自定义，但是CronJobs和Deployments足以满足大多数用例。
一旦知道选择哪个控制器来运行服务，就需要使用模板对其进行配置。
模板剖析
Kubernetes模板是一个YAML文件，用于定义容器运行所用的参数。就像任何形式的代码配置一样，它具有自己的特定格式和要求，需要学习很多东西。但庆幸的是，需要提供的信息与针对任何容器编排运行代码相同：
- 告诉它如何命名应用程序
- 告诉它在哪里寻找容器的镜像(通常称为容器注册表)
- 告诉它要运行多少个实例(在上面的术语中，为ReplicaSets的数量)
配置的灵活性是Kubernetes的众多优势之一。使用不同的资源和模板，还可以提供有关以下内容的集群信息：
- 环境变量
- 密码位置
- 容器应挂载以供使用的任何数据卷
- 每个容器或Pod允许使用多少CPU和内存
- 容器应运行的特定命令
- 而这样的例子还有很多
汇集全部
组合来自不同资源的模板，使用户可以互操作Kubernetes中的组件，并根据自己的需求自定义它们。
在更大的生态系统中，开发者可以通过结合使用ConfigMap和Secrets的Jobs，services和Deployments来组合成一个应用程序(在部署过程中)，所有这些操作都必须经过精心策划。
这些编排步骤的管理可以手动完成，也可以使用常见的软件包管理选项之一来完成。虽然绝对有可能根据Kubernetes API进行自己的部署，但是打包配置通常是一个好主意(特别是如果要交付的开源软件可能是由不在团队中的人直接部署和管理的)。
Kubernetes首选的软件包管理器是Helm。使用Helm并不需要花很多时间，它使你可以打包自己的软件，以便在Kubernetes集群上轻松安装。
总结
位于容器上面的许多层和扩展可能会使容器协编排难以理解。但是，一旦分解了各个部分并查看它们之间的相互作用，它实际上就非常清晰了。
