前言
随着容器技术的发展，容器的优势：易打包、可复制、隔离性、低开销，使得不断的有应用开始从传统的物理机、虚拟机，逐渐的搬迁到容器上。而Kubernetes的诞生和发展壮大，又降低了应用的标准化部署管理的难度，大大加速了应用搬迁到容器的进程。将一个存在前台、后台、数据库的分布式系统一键式部署到K8S上时，可以有哪些方法和途径呢？
K8S上的应用模型
Kubernetes对容器应用的编排，是将应用的运行时、配置、服务提供、存储、镜像等都定义成了多种资源对象，每种资源对象都可以按照一定的格式进行描述定义。比如环境变量可以定义到configmap对象，也可以定义在容器的配置中；而应用的运行时，则是多种工作负载：Deployment、StatefulSet、DaemonSet等。
| 资源类型 | 功能 |
| Deployment | 定义应用的容器镜像、资源要求、运行时环境等工作负载相关，无状态记录，可任意扩缩容 |
| StatefulSet | 定义应用的容器镜像、资源要求、运行时环境等工作负载相关，存在状态信息记录，按序启动与伸缩 |
| DaemonSet | 定义应用的容器镜像、资源要求、运行时环境等工作负载相关，一般是代理类应用，会在每个节点上运行实例 |
| Job | 定义应用的容器镜像、资源要求、运行时环境等工作负载相关，短时任务类，执行完成即退出 |
| ConfigMap | 定义配置，可用于挂载到容器的环境变量或者文件中 |
| Secret | 定义敏感配置信息，可用于挂载到容器的环境变量或者文件中 |
| Service | 定义应用的访问入口 |
| Ingress | 定义应用的http访问入口 |
| …… |
一个应用就会至少有一个工作负载，以及一些配置，访问入口等资源对象。通过控制这些资源对象，就可以完成一个应用，或者多个应用的统筹管理，这就是k8s上的应用编排。最原始的方式当然是直接操控每一个的资源对象，但是，多个分散的文件，又没有变量替换功能，就意味着这些文件只能在一套环境上执行，一旦环境有变化，还需要手动修改文件的内容；这些对象之间还必须以一定的先后顺序执行，否则会失败。当应用更多时，执行的流程就会更加的复杂。
分布式系统的编排要求
下面是一个典型的分布式系统，包括前端程序、后台程序、后台数据库，负载均衡器等。在应用系统发展到一定程度，自然而然的就会对系统的各部件角色进行拆分，对于每种角色，都可以进行一定的水平或者垂直的扩展，保证应用的扩展性，解除系统的单点问题。
这样的一个系统，对应用编排有这些要求：
1. 系统中可以定义多种应用
2. 每个应用的多个资源对象之间，可以定义控制依赖关系
3. 不同应用之间存在配置上的传递
4. 不同应用之间存在启动顺序上的先后依赖关系
Helm：社区原生的包管理工具
由于K8S的资源对象都具备着一定的格式化规范，社区提供了Helm用于处理k8s应用的打包，这个包叫做一个chart。Chart的包格式如下：一个Chart.yaml文件，用户定义包的名称、版本等信息，一个templates目录，里面定义了这个应用所有相关的资源描述的go-template语法的模板，而模板使用到的变量，则在values.yaml文件中进行声明定义。
Helm的实现原理很简单，在客户端实现变量的渲染替换，再将完整的内容传递到服务端（tiller），由tiller将生成的k8s对象按照一定的顺序调用k8s接口，完成应用的编排创建。
helm还支持了dependency的依赖关系，用于chart包之间的引用。而应用之间的参数传递，也可以通过共享相同的变量输入来完成。这样，分布式系统要求的1,2,3,4看起来也都满足了。
但是，在helm的实际应用中，存在着下面的几个问题。
● 应用中的任务下发，只控制了请求的发送顺序，并不能保证创建完成的先后顺序。这就导致了有时候secret之类的对象尚未处理完成，deployment就去引用而失败的情况。
● 对于Deployment之类的工作负载，helm没有去真正的判断实例是否启动就绪完成了，即使应用实例因为某些原因失败了，helm也感知不到。
● Helm的dependency依赖，只控制了chart包的引用，实际上的多个应用一起创建时，还是全部展开按照类型顺序统一执行的。
● Chart包的模板编写，一方面需要用户对k8s的资源对象结构有一定的理解基础，另一方面go-template的引入使得模板变成了非格式化的结构，无法正常的进行校验处理，导致容易出错。
对于Helm在处理分布式系统中遇到的问题，并非难解。核心在于一套完善的DAG框架，能够精确控制所有的步骤流程，以及每个步骤的结果管理和传递。而这套框架最好是格式化的简单的结构，不需要那么复杂，要精通K8S、go-template等等，最好有图形化的界面，可以辅助编写。
应用编排服务：解决依赖和配置传递
华为云上的应用编排服务（以下简称AOS），就是这样一个能够满足复杂分布式应用在K8S上的各种要求的系统。AOS服务对接了华为云的云容器引擎（CCE服务），提供了一套规范化的模型结构，可定义K8S上的各种资源对象。通过模型设计的模板，可以实现复杂分布式系统的一键式编排创建在K8S集群上。
● 优秀的图形化设计器，通过图形化拖拽即可设计应用结构，将应用所需的各种资源，精确控制所有对象的执行顺序关系，实现最大化的并行。
● 通过编排语法可以将应用之间的共享参数、应用的输出访问地址等信息进行传递输出。
● 良好的变量输入输出机制，将应用在不同环境中的部署所需配置提炼，实现一套模板，多处复用。
前面的分布式系统，在AOS编排设计后，就可以成为下面的这个图。这样的一个分布式系统，将依次创建DB数据库，执行创建数据库表结构的job，而数据库的访问信息将记录到secret中，由两个后端程序app1-back2，app-backend1挂载使用。两个后端程序还同时引用了共同的配置appconfig。前台应用通过ingress和service去访问后端程序，并提供了ingress用于外部访问。这个图中没有体现负载均衡器，因为这里的ingress配置了连接华为云的ELB服务。
应用编排系统还支持编排管理云上的各种服务，比如RDS数据库，ELB负载均衡器等，利用这些服务，将简化分布式系统的云上架构，帮助用户聚焦在自身的业务，不再需要花大力气在业务的交付和部署运维上。
AOS服务信息，请点击阅读原文获取
标签：容器,定义,编排,应用,分布式系统,K8S 来源： https://blog.51cto.com/u_15127680/2821277
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。