基于Kubernetes的技术中台让云原生C位出道

一. 认识云原生与Kubernetes

　 随着云原生技术的飞速发展，新概念层出不穷，例如DevOps、微服务、容器、弹性云等，直有“乱花渐欲迷人眼”之势。云计算从业者们反复谈及“云原生”这个概念，但对其定义与理解却各有不一样。

云原生（Cloud Native）的概念，最先由Pivotal的MattStine根据其多年的架构和咨询经验于2013年首次提出。2015年7月，隶属于 Linux 基金会的云原生计算基金会CNCF（Cloud Native Computing Foundation）对云原生计算作了详细定义：所谓“云原生”，是指一个用于部署微服务应用的开源软件堆栈，其方式是把各个组件都打包到容器中并动态调度容器以优化计算资源利用率。

　　能够看到，云原生的目的是解决从DevOps到容器化的全过程。随着时间的推移，业务系统的应用模型在发生不断的变化：从早期的单体模型，到分级模型，再到如今的微服务等。所以，应用的部署以及打包方式也发生了突飞猛进的变化。以Docker为首的容器技术的出现，终结了应用交付和部署环节因环境、配置及程序自己的不一样而出现的动辄几种甚至十几种部署配置的困境。Docker将他们统一在容器镜像以内，实现了一次构建，任何地方都可运行的目的。

　　相对于物理机和虚拟机而言，容器是很轻量化的技术，这意味着在等量资源的基础上可以建立出更多的容器实例。可是，一旦面对分布在多台主机上，且拥有数百个容器的大规模应用程序时，传统的或单机的容器管理解决方案就会变得力不从心。在这种状况下，咱们就须要一种支持大规模容器的托管，编排，以及调度等一系列自动化管理工具。

　　目前，容器技术圈内有诸如Docker Swarm，Mesos Marathon、Kubernetes等分属不一样阵营的容器集群管理工具。其中， Kubernetes初版自2015年7月发布以来，其功能已发生了很大的变化。过去两年，开放式社区在发展这个容器管理平台方面取得了巨大的进步，Kubernetes的技术拥抱度也空前高涨。

　　用友云技术中台在探究容器云道路中，也一直紧跟新兴技术体系建设，将一些成熟稳定的技术栈落到产品中。目前技术中台也采用Kubernetes（K8S）做为容器的调度引擎，提供可预测性、可扩展性与高可用性的方法来彻底管理容器的生命周期。咱们接下来将会结合用友云技术中台，对Kubernetes的架构和相关技术进行详细阐述，一块儿探秘如何经过它让云原生应用C位出道。

二. Kubernetes的技术架构解读

　 Kubernetes由运行在一组节点机上的服务组成，这些节点能够是物理主机，也能够是虚拟机。Kubernetes平台运行在这些节点之上，并构成了集群。

　　在Kubernetes的系统架构图中能够看到，咱们把服务分为两种，分别为运行在工做节点（Node）上的服务和组成集群级别控制节点（Master）服务。运行应用容器必备的服务运行在Kubernetes的工做节点上，而这些服务受Master的控制。每一个工做节点上都要运行Docker，用来负责全部容器镜像的下载和容器的启动、运行、中止等操做。

　　控制节点（Master）能够认为是控制整个集群大脑，它包括Etcd组件、API-Server、Controller-Manager、Scheduler等。工做节点（Node）包含了2个组件，分别为Kubelet和Kube-Proxy.

这些组件的做用是：

Etcd：保存了整个集群的状态，存储集群中全部对象产生的数据；

　 API-Server：提供了资源操做的惟一入口，并提供认证、受权、访问控制、API注册和发现等机制；

　　Controller-Manager：负责维护集群的状态，好比故障检测、自动扩展、滚动更新等；

　　Scheduler：负责资源的调度，按照预约的调度策略将Pod调度到相应的机器上；

　　Kubelet：负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

　　Kube-Proxy：负责为Service提供cluster内部的服务发现和负载均衡。

三. 使用Kubernetes打造技术中台坚实底座

　 在长期的平台建设过程当中，咱们进行了大量的调研和“趟坑”实践：从建设总体链路，到选取网络模型，到选择安装方式，再到在专属化过程当中兼容公有云模式，最后到实现集群架构的最佳设计等。例如，在基础安装环节，须要考虑是选择二进制安装方式，仍是使用官方推荐的Kubeadm工具安装。通过分析研究实践，咱们采用了更为稳妥的二进制集群部署方式。在高可用性方面，咱们建设了Etcd以及K8S-Master集群，加强了容灾处理能力；在安全性方面，咱们采用了组件证书双向认证机制，使集群安全性获得了提高。在云原生应用的完整链路和应用高并发方面，咱们还作了一些负载策略、DNS策略、各种组件和OS层面的参数优化，同时结合Nginx、HAProxy、Keepalive、SLB等组件串通整条链路。

　　在以前的平台设计当中，考虑到软件产品的开发到用户投入使用，整个过程期间须要进行大量的应用部署、验证、预览等操做，所以在环境上来讲，仅搭建一套环境远远不能知足现实的需求。咱们基于以前积累的技术栈，建设了生产，测试，开发，预发布等多套环境，用于知足在迭代上线的过程当中保持整套产品的规范性建设流程。在这里，咱们践行的是多套环境分治理念，针对各个环境的特性分别搭建K8S集群，并对应完善负载入口等一系列功能建设。

　　在Kubernetes集群底层建设好以后，就须要考虑将平台中的一些服务进行相应适配，这须要作大量脚本接入工做来实现。在技术中台资源池中，咱们将一组服务器主机进行了统一化的管理，方便容器的最优调度。每个接入的主机（Node）在接入过程中，安装了Docker，Kubelet，Kube-Proxy等组件，并完成向K8S-Master的注册工做。

　　在这些组件中，Kubelet是运行在工做节点之上的守护进程。它从K8S的API-Server接收关于Pod对象的配置信息并确保它们处于指望状态，同时会按期的向Master汇报节点资源使用的状况，并经过Cadvisor监控容器和节点机的资源占用情况。而Kube-Proxy服务可以按需为Service资源对象生成iptables规则，从而捕获访问当前的Service和ClusterIP流量，并将其正确的转发给后端的Pod对象。

　　在将这些Node节点机都添加至资源池后，咱们这里作了一个关于资源池ID管理的设计，即由用户ID和产品线ID组成资源池ID，这个ID由技术中台统一分配，做为每一个资源池独特的标识。这样作能够更好的结合Kubernetes的Node Label特性。通常在默认的状况下，Kube-Scheduler会将应用Pod调度到全部的可用Node节点机上，可是这样会发生跨资源池的混乱调度情形。当咱们但愿将一些服务调度到指定的资源池时，利用此资源池ID管理设计便可知足要求。

　　例如，“开发资源池-k8s”是技术中台内的一个资源池。在应用流水线中勾选了此资源池后，流水线所建立的应用都由Scheduler调度服务根据指定的调度规则发布到对应的资源池中。由此一来，运维或者开发人员对每一个资源池部署的应用都可以掌握的更加清晰，同时对不一样业务线的资源池也得以更加方便的规划和管理。

四. 技术中台让云原生C位出道　

资源池搭建完成以后，接下来要部署咱们的云原生应用了。在代码来源层面，技术中台提供了war包、源代码（Git和SVN）以及Dockerfile等多种构建方式。

　　在流水线的构建过程中，会根据用户填写的一些配置信息，如CPU、内存、健康检查、环境变量等应用信息来完成应用的构建任务。用户所填写的配置信息，都会经过发布模块直接落进K8S的Delopyment资源对象当中。应用的Docker镜像构建完成后，会将镜像推送到镜像仓库。以后，根据用户的选择，将应用部署至对应的环境和资源池中。将一系列的流程操做完毕后，应用经过技术中台的app-publish模块在指定的镜像仓库中获取构建好的Docker镜像，结合K8S-API将应用发布出来。值得一提的是，K8S也采用了REST API设计思想，对一些资源类的操做提供了至关丰富的API；而API-Server做为惟一和ETCD通信的渠道，起到了整套集群的数据交互和通信桥梁的做用。

　 在K8S当中， Pod用来承载服务的容器化，同时也是K8S概念中的一个最小单元。它由一到多个容器，以及资源设置，网络设置等逻辑对象等组成。

　　对于Deployment对象，顾名思义，即用于部署应用的对象。它是Kubernetes中部署服务最经常使用的对象。之因此再也不单独使用Pod管理对象资源，是由于它具备极大的局限性。Deployment的出现为ReplicaSet和Pod的建立提供了一种新的声明式的定义方法，从而无需手动建立ReplicaSet和Pod对象。值得注意的是，不直接建立ReplicaSet是由于Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚等。

　　在大规模云计算当中，咱们能够经过指定应用的副本数，来肯定后端负载的实体数量，并经由统一入口服务后，提供分流能力。结合着副本控制器Controller-Manager，K8S也得以具有服务自愈能力。所谓服务自愈能力，即当容器重启，或者节点机发生故障，异或因为某些缘由致使应用健康检查不经过，导致容器关闭现象出现时，系统能够自动恢复应用容器，并将其调度到资源池当前可用的机器中。

　　容器的健康检查机制及服务更新策略是两点很是重要的功能设计，由于这两个点对应用的正常使用会产生重要影响。

　　Kubernetes提供了两种探针能够检测Pod的健康状态。一种是LivenessProbe探针，用于判断容器是否存活，即Pod是否为running状态。若是LivenessProbe探针探测到容器不健康，那么Kubelet将会kill掉容器，并根据容器的重启策略决定是否重启。若是一个容器不包含LivenessProbe探针，那么Kubelet将会认为容器始终为running状态。在生产环境中，建议结合此探针来使用。

　　另外一种探针是ReadinessProbe探针，用于判断容器是否启动完成，即容器的Ready状态是否为True，可正常提供服务。若是ReadinessProbe探测失败，则会将容器的Ready状态设置为False.以后，控制器将此Pod的Endpoint从对应的Service的Endpoint列表中移除，此时任何请求均不会调度至此Pod上，直到下次ReadinessProbe探测成功。

　　每类探针都支持三种探测方法，分别是 HTTP检查，TCP检查，COMMAND检查。

　　HTTP健康检查：经过发送http请求检查服务是否正常。请求返回的状态码在200-399之间则表示容器健康；

　　TCP健康检查：经过容器的IP和Port执行TCP检查。若是可以正确创建TCP链接，则代表容器健康；

　　COMMAND健康检查：经过执行命令来检查服务是否正常。针对复杂场景或无http接口的服务，命令返回值为0则表示容器健康。

　　用友云技术中台集成了这三种健康检查方式。在使用过程当中只须要修改健康检查的协议，就可以配置不一样的检测方式。业务健康检查的正确配置，对系统的稳定运行相当重要，它可以第一时间准确的反馈应用是否出现故障，而且根据设置的规则由系统触发故障自恢复动做。

　　在发布负责人经过流水线进行应用发布上线的过程当中，为保证线上业务对客户无感，不中断的实现功能特性的更新，咱们在技术中台中内置了K8S的RollingUpdate特性。基于这个特性能够实现应用的滚动升级。默认咱们采用的是逐步替换策略。在滚动升级的策略中，咱们也增长了更多附加参数的支持，例如设置最大不可用pod数量、最小升级间隔时间等等。基于这个策略，就能作到在滚动升级时，旧的容器实例先保持存活状态，当新发布的应用在经过健康检查，达到对外提供服务的能力后，负载均衡服务将此新的容器实例接入，而后再杀掉旧的容器实例，从而实现一次服务的平滑升级过程。

　　Kubernetes的优秀特性还不少，如网络隔离、容器网络通信、负载建设、ngress-Controller的多维建设等。咱们将会在后续的文章当中继续对这些功能点做出介绍。用友云技术中台也一直紧追开源社区最新的特性，适时的进行版本升级、组件升级，将一流的技术体验实践到产品当中。咱们的最终目的就是：让您的云原生应用C位出道！

五. 总结与展望

　　在实践中能够看到，“云原生”更侧重于云软件开发后的交付与部署。其主要采用以Docker容器为基础的云模式部署，并经过Kubernetes等容器服务调度系统把一次编写的云应用程序（Cloud Native Application）分布式的分发到本地数据中心或云上。基于Kubernetes强大资源管理能力，将无数的“小”容器横向链接起来，造成了云软件规模化扩展能力。

　　在现代企业中，云服务能够在任意数量的私有和公有基础架构上运行，是新时代技术架构体系下面临的新挑战。良好的容器管理意味着只要软件运行，部署几乎老是平滑进行；意味着更快的部署体验；意味着研发效率的提高和架构水平的提高。能够说云原生能有效的帮助企业更加轻易的构造一个可扩展、高弹性、高稳定性的业务系统。

　　您能够尝试将已经进行云原生改造过的云业务，接入用友云开发者中心，感觉技术中台和Kubernetes带来的便捷，借此打造更加灵活的团队，更加灵动的业务，更增强大的技术支撑，和更增强大的数字化企业。

转载于:https://blog.51cto.com/14084875/2410651