8 月最新基于 kubernetes 的应用编排实践

今天交流的话题主要会分为三部分：

1、为什么需要应用编排

2、kubernetes社区应用编排发展现状

3、腾讯云容器服务应用编排的实践这几个方面做介绍。

在腾讯云容器服务应用编排的实践部分，主要会涉及1、配置管理，2、应用模板管理，3、基于应用的服务组管理等内容。

为什么需要应用编排：

“微服务”架构大家都知道，他具有开发效率高，扩展性好，稳定性好，维护简单等优点。越来越多的软件，开始采用微服务的方式进行开发和部署。

但任何事情都是有利有弊的，微服务架构有诸多好处。但微服务软件的部署和运维对传统的自动化运维体系提出了新的挑战。

微服务部署带来的挑战：

1、服务数量急剧增多。比较常见的情况是，一个系统可能会被拆分成多达数十个微服务。如何管理一个系统中这么多的微服务，对于运维部署系统是一种挑战。

2、服务自身的配置问题。配置问题一直是服务管理中的难点。随着服务数量的增多，对服务配置的管理也提出了更高的要求。如何去管理诸多服务，不同环境中存在差异部分以及在系统运维阶段需要灵活变更的部分，这些都是服务配置管理中需要解决的问题。

3、服务依赖关系的管理。随着服务数量增加，服务依赖关系也变得更加复杂。

4、环境信息的管理，如何在多个环境中快速复制，如何在新的环境快速的部署一个复杂的系统。

由于服务数量的增多，同时需要多环境部署。采用原有对单个的服务进行部署和管理的方式，会出现一定的部署运维上的瓶颈。

而应用编排，通过应用模板，配置管理和服务组管理的方式。能够很好的简化微服务部署管理的复杂度，实现复杂系统在多个环境中的快速部署和高效管理。

开发，测试，预发布，正式环境多环境的管理，进一步加剧了微服务管理的复杂度。

但这些都可以通过应用编排得到简化，实现对系统的高效管理和快速部署(复制)。

kubernetes社区应用编排发展现状：

Kubernetes原生的方案中，基于服务粒度对系统组件进行管理，支持服务注册发现和路由管理。对于一个服务提供多种不同的资源描述类型，比较常用的有Deployment，Job, CronJob, Stateful, Daemonset。

每种类型都表示一种特定的部署方式。Kubernetes支持通过Yaml对服务的资源进行描述，也支持通过Label(标签)的方式对服务之间的关联关系进行管理。

随着服务数量的增多，描述一个系统需要组合使用大量的Kubernetes资源，这个过程会相当复杂。于是社区就可以引入可以在更高维度对资源进行描述的管理工具，将多个服务组合成应用进行描述和编排。

kubernetes社区编排方案中，Helm基于Charts包的实现方案占主导地位。目前Helm已经成为kubernetes下应用编排的唯一子项目。推出Helm项目的Deis公司已经被微软收购。说明大家比较看好这个项目的未来。

上图是一个Chart包的示例，主要包括templates文件夹，values.yaml文件，Chart.yaml文件等部分。

Templates夹里面有含应用的多个服务资源描述的模版。资源描述的模板指的是在kubernetes原始YAML的基础上，将gotemplate的语法进行嵌入产生的一种描述文本形式。

Values.yaml 用来存储配置项，不同的环境可能会有不同的配置项。在Helm处理时候，会首先使用gotemplate对templates中的文件进行渲染，生成对应kubernetes的资源文件。文件渲染的过程，本质上是一个变量替换的过程，使用values.yaml中变量的值替换掉templates中预留的变量。

Chart.yaml是一个说明文件，描述chart包的一些基本信息。在某些chart包中还会有requirements.yaml，requirements.yaml用于描述依赖的其他的.

上图是一个Charts包的示例，Helm Template文件支持的语法包括，基本语法:1、 {{.Value}}的方式来表示一个变量，支持基本的变量替换。2、支持{{.Release.Service}}等默认的内置变量。高级语法：1、支持分支语句2、支持管道和函数处理等

kubernetes社区应用编排发展现状中存在的问题：原生kubernetes仅支持通过服务和label进行管理，在服务数量较多的对服务的管理会比较困难。

Helm编排，更加侧重于包管理；语法复杂，学习成本高；不支持按照服务更新和管理；差异化比较功能弱。

考虑到社区方案中的一些问题，腾讯云容器服务参考社区Helm的实现形式，在容器服务中实现了完整的应用编排管理功能。

腾讯云容器服务编排服务主要分为配置管理，应用模板管理，基于应用的服务组管理几个主要部分。

配置管理：将应用中常变的值以变量的形式替代，配置项支持多版本，方便用户进行更新和回滚应用。

应用模板：包括多个服务的定义加一个默认配置，通过应用模板+配置项的组合，方便用户部署相同应用的不同环境。

应用：包括描述多个服务以及这些服务间的相互调用依赖关系 ，方便用户管理多个服务。

如上图所示使用应用模板对复杂系统中各个服务进行描述，通过配置项区分不同环境中差异化信息，从而实现在多环境中快速部署，快速回滚，环境快速复制。通过应用实例对服务进行分组，简化服务的管理。

配置管理的主要作用包括

1、通过提取出多个环境中不同的部分，支持同一套系统在多个环境中部署

2、提取出服务中经常变更的部分，实现服务的灵活变更。

例如一般会将服务实例数量，实例的镜像tag提取成为一个配置项。修改这些参数时，修改对应的配置项就可以实现变更。并且通过配置文件的版本管理，可以很好的对变更进行追溯和回滚。

3、通过配置项，可以隐含的实现多个服务直接依赖关系的管理。例如：服务A需要访问服务B的，一般情况下依赖于服务B的名称。

这种情况下，将服务B的名称提取成为一个配置项，而将配置项传递给服务A。这样在不同环境中，服务B名称的改变，服务A能自动感知，不需要单独修改服务A的参数。

配置管理的实现，我们支持三种：

1、Helm的模板文件支持变量渲染

2、kubernetes的Configmap中环境变量方式

3 kubernetes的Configmap通过Volume方式进行数据填充

为了简化配置管理本身的复杂度，我们将三种配置管理都统一成了“Key/Value”形式。

在用户指定应用相对应的配置文件后，使用同一份配置文件，我们会先对应用的Template文件进行渲染，然后会进行环境变量替换。

最后会在k8s中创建对应的configmap资源，支持用户通过Volume的形式挂载configmap中的Key。

这样做的好处是，没有多种形式的配置项形式，应用也不需要指定多个配置文件。应用在不同环境中的复制，只需关联对应的配置文件就可以了，不需要考虑配置文件的组合。

上图是腾讯云容器服务中配置管理操作的UI界面。配置管理支持多版本。应用的变更先修改配置，然后再通过配置触发对应的服务更新，这样对服务的更新实现规范化和可追溯。

后面我们还将实现通过配置项更新，自动触发服务的更新。可以结合CI/CD流程，通过CI编译生成新的镜像，修改配置项中镜像tag的参数，自动触发对应服务的更新。

应用模板用于描述一个或多个服务的定义，服务的定义支持原生的Yaml语法，但可以通过GoTemplate的方式定义对应的变量。

应用模板的主要作用包括：

1、实现应用的快速克隆。由于应用的相关信息已经通过对应的template文件进行了描述，复制应用的过程只需要针对性的修改应用的配置，其他结构信息不需要进行改变。

2、应用的多环境部署。在多个环境中，实现应用的部署，也不需要关系每个服务具体的部署信息，只需要在不同环境下修改环境对应的配置，即可以通过应用模板实现在新环境应用的快速部署。

3、更高阶的功能，通过应用市场可以下载通用的模板，快速的部署应用。例如：在Helm(Charts)的应用市场https://kubeapps.com/ ，已经打包好了100+应用的模板文件。直接下载对应的应用模板就可以实现应用的部署。

上图是腾讯云容器服务中应用模板操作的UI界面。在应用模板中包含一个或者多个服务，一个服务对应于一个或者多个k8s的资源。但建议将一个deployment，stateful，deamonset这样的资源，单独作为一个服务进行管理。

服务使用一个template文件进行描述，服务的template中的变量，通过一个统一的配置文件进行管理。

应用可以理解为多个服务的组合，多个服务会统一进行展示，服务支持按照应用进行搜索。多个服务的配置项，统一的通过同一个配置进行管理。通过服务组的方式，管理多个服务。可以简化多个服务管理的复杂度。

前面两张图是腾讯云容器服务中应用操作的UI界面。

应用中的服务支持单独编辑，部署和更新。同时服务支持差异化比较，方便用户查看两次修订之间的差异。

在服务编辑时，自动提取出对应的变量，简化配置的过程。支持服务回滚功能，支持服务回滚到上一个版本。

后期展望包括下面几个部分：

1、启动项管理，这个对应在启动上有先后顺序依赖的应用来说，是一个强诉求。目前docker compose 支持通过depends_on标签实现多个组件间启动顺序的管理。

k8s目前还不支持指定启动顺序的，只能通过init_container，在实例容器启动前对依赖的服务进行检测，检测到依赖的服务启动后再启动相应的容器。

2、应用下的日志聚合，其实这里应该还包括监控数据聚合。这个需求应该是系统基于服务组管理后的一个延展诉求，可以进一步强化服务组管理的能力。

3、调用关系展示，这个需求进一步在应用中突出服务与服务之间的依赖关系。更进一步对于调用链的追踪也是一个强诉求。

4、公共模板与应用市场，这个是应用编排更高阶的一个形式。通过应用市场可以快速的实现通用软件的容器化部署。

以下为互动问答的内容分享：

Q: 应用下的服务展示（未部署），是yaml资源没有创建，还是副本数为0？

W: 未部署状态是yaml资源还没有创建

Q: 腾讯云能否将Kubernetes应用编排过程做成博客或视频的形式具体分享一下？

W: 我们接下来会将Kubernetes应用编排过程做成博客分享出来，后面也会做出视频分享给大家

Q: 腾讯云k8s网络用的是哪个组件呢？

W: 我们用的是全局路由的方式，直接和我们腾讯云容器服务的VPC网络打通。

Q: 使用configmap的时候，在配置修改完，需要重启服务。腾讯云容器服务配置文件的变更如何触发服务的重新启动？

W: 通过触发器的模式，可以在修改配置时触发服务的更新。

Q: 之前讲到可以结合CI/CD流程，通过CI编译生成新的镜像，修改配置项中镜像tag的参数，自动触发对应服务的更新。 这部分有详细例子吗？

W: 我们会将详细示例放到腾讯云容器服务帮助文档，在腾讯云分享论坛--腾云阁后面也可以看到。

Q: 应用配置如何实现版本控制的？

W: 对于每一个配置文件，我们支持每一次修改默认创建一个新的版本，具有唯一的版本号

Q：应用里的服务具体要怎么更新呢？

W: 一般建议的更新方法是，先修改配置，会生成配置的一个新的版本，这样这次修改在配置中是可以记录的。然后更新应用汇总配置文件的版本。触发或者手动更新对应的服务。

在修改配置文件的版本后，我们会比较出哪些服务有变化，需要更新。

Q：应用里的服务具体要怎么更新呢？

W: 一般建议的更新方法是，先修改配置，会生成配置的一个新的版本，这样这次修改在配置中是可以记录的。然后更新应用汇总配置文件的版本。触发或者手动更新对应的服务。

在修改配置文件的版本后，我们会比较出哪些服务有变化，需要更新。

Q: 外部访问集群是通过Nginx转发到pod还是通过k8s本来都dns服务来转发，两者优缺点是什么？

W: 外部访问，支持两种方式。

一种是通过服务的LB直接转发到对应的Pod，但需要在创建服务时指定访问方式为外部访问(对应于k8s中的LoadBanace方式)。

另外一种是通过ingress的方式。这种方式会有一个统一的LB作为入口。然后配置对应的后端域名转发规则。可以将外部的访问按照配置的规则转发后端的服务。

Q: 上面提到 应用模版+应用配置=应用实例，这样一个应用模版可以对应多个应用配置并生成多份应用实例吗？例如生成200个实例，如果可以如何写ci比较合适？

W: 这个是可以的，并且我们提供集群隔离和命名空间隔离。方便多个应用实例的创建。

Q: 应用的扩容缩容通过什么监控，有什么指标可以参考？

W: 自动扩容和缩容我们参考的是社区HPA的方案。指标目前考虑的是CPU和内存。

Q: 状态化的容器怎么做的？

W: 目前看到的有三种方式：一种是社区推荐的Stateful资源+headles service

另外一种是：将服务的每一个实例拆分成独立的headless service

第三种是： 采用CoreOS提出的operater方式。存储部分一般推荐使用PVC的方式，但有其他的存储方式也可以。