K8S 中的容器编排和应用编排

 众所周知，Kubernetes 是一个容器编排平台，它有很是丰富的原始的 API 来支持容器编排，可是对于用户来讲更加关心的是一个应用的编排，包含多容器和服务的组合，管理它们之间的依赖关系，以及如何管理存储。

在这个领域，Kubernetes 用 Helm 的来管理和打包应用，可是 Helm 并非十全十美的，在使用过程当中咱们发现它并不能彻底知足咱们的需求，因此在 Helm 的基础上，咱们本身研发了一套编排组件……

什么是编排？

不知道你们有没仔细思考过编排究竟是什么意思? 我查阅了 Wiki 百科，了解到咱们常说的编排的英文单词为 “Orchestration”，它常被解释为:

• 本意:为管弦乐中的配器法，主要是研究各类管弦乐器的运用和配合方法，经过各类乐器的不一样音色，以便充分表现乐曲的内容和风格。
• 计算机领域:引伸为描述复杂计算机系统、中间件 (middleware) 和业务的自动化的安排、协调和管理。

有趣的是 “Orchestration” 的标准翻译应该为“编配”，而“编排”则是另一个单词 “Choreography”，为了方便你们理解， 符合平时的习惯，咱们仍是使用编排 (Orchestration) 来描述下面的问题。至于“编配 (Orchestration)” 和 “编排(Choreography)” 之争，这里有一篇文章，有兴趣能够看一下 。

编配和编排的定义之争​www.infoq.com

Kubernetes 容器编排技术

当咱们在说容器编排的时候，咱们在说什么？

在传统的单体式架构的应用中，咱们开发、测试、交付、部署等都是针对单个组件，咱们不多听到编排这个概念。而在云的时代，微服务和容器大行其道，除了为咱们显示出了它们在敏捷性，可移植性等方面的巨大优点之外，也为咱们的交付和运维带来了新的挑战：咱们将单体式的架构拆分红愈来愈多细小的服务，运行在各自的容器中，那么该如何解决它们之间的依赖管理，服务发现，资源管理，高可用等问题呢？

在容器环境中，编排一般涉及到三个方面:

• 资源编排 - 负责资源的分配，如限制 namespace 的可用资源，scheduler 针对资源的不一样调度策略；
• 工做负载编排 - 负责在资源之间共享工做负载，如 Kubernetes 经过不一样的 controller 将 Pod 调度到合适的 node 上，而且负责管理它们的生命周期；
• 服务编排 - 负责服务发现和高可用等，如 Kubernetes 中可用经过 Service 来对内暴露服务，经过 Ingress 来对外暴露服务。

在 Kubernetes 中有 5 种咱们常常会用到的控制器来帮助咱们进行容器编排，它们分别是 Deployment, StatefulSet, DaemonSet, CronJob, Job。

在这 5 种常见资源中，Deployment 常常被做为无状态实例控制器使用; StatefulSet 是一个有状态实例控制器; DaemonSet 能够指定在选定的 Node 上跑，每一个 Node 上会跑一个副本，它有一个特色是它的 Pod 的调度不通过调度器，在 Pod 建立的时候就直接绑定 NodeName；最后一个是定时任务，它是一个上级控制器，和 Deployment 有些相似，当一个定时任务触发的时候，它会去建立一个 Job ，具体的任务其实是由 Job 来负责执行的。他们之间的关系以下图：

一个简单的例子

咱们来考虑这么一个简单的例子，一个须要使用到数据库的 API 服务在 Kubernetes 中应该如何表示:

客户端程序经过 Ingress 来访问到内部的 API Service, API Service 将流量导流到 API Server Deployment 管理的其中一个 Pod 中，这个 Server 还须要访问数据库服务，它经过 DB Service 来访问 DataBase StatefulSet 的有状态副本。由定时任务 CronJob 来按期备份数据库，经过 DaemonSet 的 Logging 来采集日志，Monitoring 来负责收集监控指标。

容器编排的困境

Kubernetes 为咱们带来了什么？

经过上面的例子，咱们发现 Kubernetes 已经为咱们对大量经常使用的基础资源进行了抽象和封装，咱们能够很是灵活地组合、使用这些资源来解决问题，同时它还提供了一系列自动化运维的机制:如 HPA, VPA, Rollback, Rolling Update 等帮助咱们进行弹性伸缩和滚动更新，并且上述全部的功能均可以用 YAML 声明式进行部署。

困境

可是这些抽象仍是在容器层面的，对于一个大型的应用而言，须要组合大量的 Kubernetes 原生资源，须要很是多的 Services, Deployments, StatefulSets 等，这里面用起来就会比较繁琐，并且其中服务之间的依赖关系须要用户本身解决，缺少统一的依赖管理机制。

应用编排

什么是应用？

一个对外提供服务的应用，首先它须要一个可以与外部通信的网络，其次还须要能运行这个服务的载体 (Pods)，若是这个应用须要存储数据，这还须要配套的存储，因此咱们能够认为:

应用单元 = 网络 + 服务载体 +存储

那么咱们很容易地能够将 Kubernetes 的资源联系起来，而后将他们划分为 4 种类型的应用：

• 无状态应用 = Services + Volumes + Deployment
• 有状态应用 = Services + Volumes + StatefulSet
• 守护型应用 = Services + Volumes + DaemonSet
• 批处理应用 = Services + Volumes + CronJob/Job

咱们来从新审视一下以前的例子：

应用层面的四个问题

经过前面的探索，咱们能够引出应用层面的四个问题：

1. 应用包的定义
2. 应用依赖管理
3. 包存储
4. 运行时管理

在社区中，这四个方面的问题分别由三个组件或者项目来解决:

• Helm Charts: 定义了应用包的结构以及依赖关系；
• Helm Registry: 解决了包存储；
• HelmTiller: 负责将包运行在 Kubernetes 集群中。

Helm Charts

Charts 在本质上是一个 tar 包，包含了一些 yaml 的 template 以及解析 template 须要的 values, 以下图：templates 是 Golang 的 template 模板，values.yaml 里面包含了这个 Charts 须要的值。

Helm Registry

用来负责存储和管理用户的 Charts, 并提供简单的版本管理，与容器领域的镜像仓库相似这个项目是开源的。（ https://github.com/caicloud/helm-registry）

Tiller

1. 负责将 Chart 部署到指定的集群当中，并管理生成的 Release (应用)；
2. 支持对 Release 的更新，删除，回滚操做；
3. 支持对 Release 的资源进行增量更新；
4. Release 的状态管理；
5. Kubernetes下属子项目(https://github.com/kubernetes/helm) 。

Tiller 的缺陷

1. 没有内建的认知受权机制，Tiller 跑在 kube-system 分区下，拥有整个集群的权限；
2. Tiller 将 Release 安装到 Kubernetes 集群中后并不会继续追踪他们的状态；
3. Helm+Tiller的架构并不符合 Kubernetes 的设计模式，这就致使它的拓展性比较差；
4. Tiller 建立的 Release 是全局的并非在某一个分区下，这就致使多用户/租户下，不能进行隔离；
5. Tiller 的回滚机制是基于更新的，每次回滚会使版本号增长，这不符合用户的直觉。

Release Controller

为了解决上述的问题，咱们基于 Kubernetes 的 Custom Resource Definition 设计并实现了咱们本身的运行时管理系统 – Release Controller， 为此咱们设计了两个新的 CRD – Release 和 Release History。

Release 建立

当 Release CRD 被建立出来，controller 为它建立一个新的 Release History, 而后将 Release 中的 Chart 和 Configuration 解析成 Kubernetes 的资源，而后将这些资源在集群中建立出来，同时会监听这些资源的变化，将它们的状态反映在 Release CRD 的 status 中。

Release 更新

当用户更新 Release 的时候，controller 计算出更新后的资源与集群中现有资源的 diff， 而后删除一部分，更新一部分，建立一部分，来使得集群中的资源与 Release 描述的一致，同时为旧的 Release 建立一份 Release History。

Release 回滚和删除

用户但愿回滚到某一个版本的 Release, controller 从 Release History 中找到对应的版本，而后将 Release 的 Spec 覆盖，同时去更新集群中对应的资源。当 Release 被删除后，controller 将它关联的 Release History 删除，同时将集群中的其余资源一并删除。

架构图

这样的设计有什么好处?

• 隔离性：资源使用 Namespace 隔离，适应多用户/租户；
• 可读性：Release Controller 会追踪每一个 Release 的子资源的状态；
• 版本控制：你能够很容易地会退到某一个版本；
• 拓展性：整个架构是遵循 Kubernetes 的 controller pattern，具备良好的可扩展性，能够在上面进行二次开发；
• 安全性：由于全部的操做都是基于 Kubernetes 的 Resource，能够充分利用 Kubernetes 内建的认证鉴权模块，如 ABAC, RBAC 。

总而言之，编排不只仅是一门技术也是一门艺术！谢谢！