《Kubernetes与云原生应用》系列之容器设计模式

http://www.infoq.com/cn/articles/kubernetes-and-cloud-native-app-container-design-pattern

 

《Kubernetes与云原生应用》专栏是InfoQ向轻元科技首席架构师王昕约稿的系列文章。本专栏包含8篇内容，将会从介绍和分析Kubernetes系统以及云原生应用入手，逐步推出基于Kubernetes的容器设计模式实践案例，但愿对计划应用Kubernetes的朋友有所帮助。本文是该专栏的第三篇，阅读本系列所有内容请在细说云计算微信公众号（CloudNote）回复K8s。

1. Kubernetes系统架构与设计理念
2. 云原生应用的设计理念与挑战
3. Kubernetes与云原生应用的容器设计模式
4. Kubernetes容器设计模式实践案例-单节点多容器模式
5. Kubernetes容器设计模式实践案例-多节点选举模式
6. Kubernetes容器设计模式实践案例-工做队列模式
7. Kubernetes容器设计模式实践案例-分散收集模式
8. 云原生应用的容器设计模式综述与展望

K8s与云原生应用

过去两年，容器和容器镜像已经成为了开发云原生应用所必不可少的技术。K8s平台的设计开发者以及K8s社区的技术人员，在不断推动K8s做为容器管理平台的快速发展的同时，也在探索如何帮助应用的设计开发者更好地运用容器技术进行云原生应用的开发。云原生应用自己必然是分布式系统，所以分布式系统的经验必然适用于云原生应用；只是通常的云原生应用，更多的借助像K8s或Mesos这样的平台来解决主要的分布式系统的问题。

 

笔者认为K8s社区人员设计K8s系统是基于两种很是重要的经验：一是Google多年来运行大型分布式系统的经验，二是支撑快速更新、敏捷迭代的云原生应用的经验。前者保证了K8s系统自己的稳定性和扩展性，后者保证了K8s系统对其用户，也就是云原生应用的运维人员和开发人员的有效性。本文将主要介绍K8s系统对云原生应用的支持。

K8s云原生应用技术理念的支持

代码仓库与部署

云原生应用理念要求严格区分应用的代码和部署。在K8s集群中与其相对应的就是Deployment操做对象。在K8s集群中，每个微服务Service操做对象就是对应一个应用代码仓库，每一个Service对应多个Deployment，正好服务一个应用屡次部署的理念。

环境配置

云原生应用理念要求将环境配置存在应用运行的环境中，在K8s集群中，全部的环境配置都存在分布式共享存储Etcd中。K8s还有一些操做对象是用来专门存储环境配置的。例如ConfigMap是存储通用的配置变量的。ConfigMap有点儿像一个统一的配置文件，使用户能够将分布式系统中用于不一样模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，而且支持K8s集群中全部通用的操做调用方式。再好比Secret是专门用来存储密钥对象的，它使得在K8s集群中用到密码等私密信息时没必要用明文环境变量来表示，从而增强密钥传递和保存的安全性。

后台支撑服务

云原生应用理念要求将后台支撑服务做为挂载资源来使用。在K8s集群中，全部的应用服务均可以被看成一种资源去访问和引用。K8s集群能够经过SkyDNS在支持DNS域名服务，全部在集群中部署的服务均可以经过以<name>.<namespace>模式的DNS域名来访问。固然，后台支撑服务也能够是来自于集群外。不论来自哪里，这些服务均可以用以DNS:Port或IP:Port来标识的一个资源来表示，而资源的使用者能够经过ConfigMap来存储这个资源的配置，这样须要访问这个资源的应用就能够同经过ConfigMap来引用这个资源。

无状态微服务实例

云原生应用理念要求应用是无状态的，对应实际环境中，就是要求应用不该该将数据存储在运行应用的主机节点上，全部状态存储在由云环境统一管理的共享存储之上，而这正是K8s中的微服务实例Pod的模型。在K8s集群中，Pod能够绑定多种存储驱动，除了emptyDIR和hostPath之外，K8s支持的多种存储驱动都是对接共享存储的。因为emptyDIR上存储的东西是临时可丢弃的，而hostPath主要用于测试，除此之外全部用于生产环境的存储都是对接共享存储的，所以能够说，K8s的存储机制是为无状态化的云原生应用而设计的。

端口映射

云原生应用理念要求应用能够根据设定的端口直接对外发布服务。在K8s集群中，集群内部访问服务的端口是经过ContainerPort属性来设置的。对于须要集群外客户端访问的服务，能够有nodePort、loadBalancer和Ingress等模式接入外网访问，其中nodePort是将服务发布到K8s集群中的每一个主机节点。

并发和水平扩展

云原生应用理念要求应用能够水平扩展以根据业务需求随时扩展计算能力，而K8s的Replication Controller操做对象和Replica Set操做对象就是支持水平扩展能力的。

快速启动和优雅终结

云原生应用理念要求应用可以快速启动和优雅地终结，这同时也要求云平台可以处理容器启动和终结时的超时等故障状况。在K8s集群中，有两个操做对象跟微服务实例的故障处理相关，一个是微服务实例Pod，另外一个是探针Probe。其中Pod的terminationGracePeriodSeconds属性设置微服务终结时等待的时间，这段时间留给微服务自身在退出前释放资源。其中Pod的activeDeadlineSeconds属性设置微服务启动时等待的时间，若是应用超过这个时间，就不符合“云原生应用”的要求，要被云平台标识成启动失败了。Probe操做对象是K8s系统和应用用来检查应用健康情况的。K8s系统提供两种探针LivenessProbe和ReadynessProbe。前者探测容器是否还正常，后者探测容器是否能提供服务，前者是后者前提。

配置共享和环境隔离

云原生应用理念要求尽可能保证开发、测试和生产环境的配置一致，可是同时这几个不一样的环境又应该是彼此隔离。在K8s集群中，不一样的环境能够经过namespace进行隔离，保证彼此不互相干扰，例如能够有dev、test、staging和production等4个不一样环境。对于不一样环境中应该保持相同的配置，能够经过持续集成工具例如Jenkins Pipeline的脚本保持一致。

集中日志处理

云原生应用理念要求对应用日志有集中的处理，这实际上是对应用管理平台的要求。在K8s集群中一个获得普遍接受的日志解决方案是fluentd+elasticsearch+Kibana的日志收集处理方案，其中Fluentd用来收集日志，Elasticsearch用来存储、索引和查询日志，Kibana用来以图形界面展现日志的统计信息。

管理服务

云原生应用理念要求将管理任务做为一次性任务运行，至关于针对管理对象执行了一笔管理交易。K8s集群中的Deployment操做对象就是对这一理念的最好反映。Deployment对象是用来管理Pod和ReplicaSet的，Pod是一个微服务实例，而ReplicaSet是一组相同的微服务实例，即最新版的Replication Controller。Deployment对Pod和ReplicaSet的管理操做，就至关于对K8s集群中的服务作了一次交易，对服务作建立或者更新的操做。

K8s操做对象对云原生应用理念的支持

从前面对K8s操做对象和云原生应用理念的解读能够发现，以下图所示，做为一个容器编排管理系统，K8s对云原生应用理念中全部非开发构建期的理念都有了很好的支持。

(点击放大图像)

K8s与容器设计模式

在程序设计领域，面向对象设计和面向对象语言是你们最为熟悉和强大的工具，而面向对象除了其强大的核心特性以外，还有人们经过实践总结出来的一系列设计模式，能够用来解决实际应用设计中的一些复杂问题。云原生应用运行的环境都是复杂的分布式环境，在这种状况下，一些有用的设计模式能够起到四两拨千斤的做用，而K8s社区推出的容器设计模式，则是结合了K8s集群的微服务模型提出的一系列可重用的解决典型分布式系统问题的模式。容器设计模式与传统的面向对象设计模式的最明显地区别在于，容器设计模式是跨编程语言的，这个固然也来自于容器自己的编程语言无关性。

(点击放大图像)

跨斗模式（Sidecar pattern）

是一种单节点多容器组合服务模式，多容器经过共享文件系统造成本地通讯，共同提供一个微服务。

外交官模式（Ambassador pattern）

是一种单节点多容器组合服务模式，应用容器和外交官容器共享一个网络IP地址，应用容器利用这个可重用的外交官容器做为代理来访问远程服务或资源。

适配器模式（Adapter pattern）

是一种单节点多容器提供服务模式，应用容器提供应用功能，同时和一个适配器容器共享文件系统和一个网络IP地址，分布式系统管理平台能够利用适配器容器的统一接口，从应用容器收集日志和监控数据等信息。

选举模式（Election pattern）

是一种多节点组合服务模式。一个可重用的选举器容器跟应用容器组合起来，提供为在分布式系统中的多个应用实例选举主控节点的问题。

工做队列模式（Work queue pattern）

是一种多节点组合服务模式。应用容器跟可重用的队列消息处理器，共同工做，能够并行地处理队列中海量的同类型并行计算业务。

分散收集模式（Scatter/gather pattern）

是一种多节点组合服务模式，经过先将大任务分割成诸多小任务处理，在收集汇总合并产生最终结果的模式，支持复杂任务的分布式计算。

在本系列文章的后面几篇中，做者将结合实践案例介绍一些常见的容器设计模式。在本文中，咱们只是简单介绍模式以留悬念。