二十，基于K8S集群的PaaS简介

[TOC]

1、概述

　　一、经过以往的学习应该能够了解到k8s 和以往提到的devops概念更容易落地了。好比咱们说的CI,CD,CD

​ CI（Continuous Integration）：持续集成

　　　 CD（）：持续交付

　　　 CD（Continuous Deployment）：持续部署

　　二、早期做为运维手工来实现发布和部署来说咱们一周发布一次就很头疼了，若是是持续部署的话一天可能要部署好几回甚至几十次。即当咱们应用程序的程序员写完代码之后从本地推送到gitlab或者github之上，然后由对应的监控工具资源监视着事件的发生，一旦发生提交了新代码就自动的去作某些操做，好比用一些所谓的CI的工具从仓库中拖下来后作静态检查，作预部署的测试，测试完后没问题了就开始打包，打包后就发给测试，由测试部署到测试环境中，这时候就须要部署了，有些是不用部署就能测试，有些是须要部署到测试环境中来实如今线测试。因此咱们作一些部署后测试。所以就有这些步骤。

　　三、一共大概有以下步骤：首先推送代码到仓库。而后使用CI或CD工具把代码拖下来作静态分析。而后作一些部署前测试，即不用打包就能够作的测试。好比扫描一下代码的完整性等等。而后就开始打包发给QA，由QA手动或自动部署到QA环境中。而后作部署后测试，若是没问题就能够发给咱们的相关的安装部署人员，就能够交付给咱们的生产环境中的运维工程师开始发布到线上去了。因此这个时候若是从开始代码推送到后面的静态分析，打包前测试，打包后测试都是自动就称之为CI，若是随后交付给运维工程师这个过程也能经过一些工具自动实现咱们一般就称之为CD。运维工程师拿到后就开始发布，好比灰度，蓝绿，金丝雀等，发布上去之后若是没问题就能够跑起来了。即若是连部署也能自动执行，好比他们交付完之后由咱们的发布系统自动实现将新版本经过灰度或金丝雀或蓝绿的方式发布到线上去这种方式咱们就称之为CD即持续部署。这些动做到今天为止每一步均可以使用工具来实现，好比像版本控制系统，svn，vcs,git等。另外就是一些持续集成工具，好比像jenkins等。另外其还须要构建工具去实现咱们代码的构建，包括编译，打包等，好比咱们的make,cmake,maven,ant等。打包后的测试咱们就须要相应的测试套件来实现，好比咱们的单元测试，系统测试，回归测试等等。

　　四、若是咱们要结合咱们k8s环境作一套CI CD的环境的话大概以下图。咱们的研发人员push代码到git，而后咱们使用jenkins用于作CI整合工具来作构建测试等，没问题后就生成应用程序而后将应用程序打包成docker镜像。而后推到docker registry即harbor上，而后就能够被k8s从中拖下来进行部署了。若是咱们把这一整套流程集中起来能用一个一整套的自动化功能来完成的话那就是所谓的CD即持续部署。咱们从推送代码到git仓库上而后用jenkins自动把其pull下来进行构建，构建完了之后他就是一个应用程序包了，而后咱们接下来让想办法给其生成dockerfile，只有结合dockerfile和application 才能build成镜像文件。第二步，咱们开发人员还要开发第二套组件，即为咱们的应用程序写一个配套的dockerfile，dockerfile开发完成后须要Push到另一套git仓库上，当咱们提供完之后把应用程序构建完告终合dockerfile利用docker build把对应的dockerfile拖下来，应用程序也有了，可直接打包为docker镜像。打包完之后咱们给其推送到harbor上去就完了。咱们要想把应用程序部署到k8s之上k8s怎么才能完成部署呢？所以咱们要有配置清单，若是咱们写好了配置清单，好比写了helm，咱们把其定义成chart，把应用程序打包成镜像之后咱们再开发好一个chart模板放在那里，这个chart不变，在传递时把chart版本换上就好了。或者把镜像文件版本换了就行。![img]

　　五、还有一种简单的方式，咱们程序员也能够写好咱们的manifests，部署时这个manifests模板用ansible或者用其它工具或Go，此处他要作的有两重做用，第一，作模板引擎渲染，即把模板中那些代码替换成他应该替换的对应的值，好比咱们这个manifests为了可以作到部署多种不一样的应用程序，好比我这里推到一个dockerfile中镜像标签什么的都换了，所以咱们把这个信息结合manifests和ansible模板引擎对manifests完成渲染然后就能够用ansible再指挥着咱们k8s拖镜像来更新了。这个过程一系列文件都要准备好，然后才会触发这些组件自动工做，而咱们ansible去渲染咱们manifests这个组件可能不会，默认他本身都作不了。若是能够的话能够把此段结合python 实现CI CD进行发布。

2、生产环境部署k8s，接下来咱们描述一下在真正生产环境中咱们部署k8s应该部署成什么样子

　　一、咱们要部署k8s要么是在裸机上要么是在虚拟机或公有云私有云等都是支持的。这就是基础架构（Core Infrastructure），在基础架构上咱们要有网络工程师帮咱们去部署好基础网络环境和存储工程师帮咱们部署好存储环境(Network和Storage)，通常来讲这种架构不会让咱们一我的去部署。在有了基础环境和网络环境之上咱们就能够构建咱们的k8s了。有了k8s集群以后咱们还须要一个容器化的工做流系统。即确保咱们的工做负载能运行起来。即有一个正常的容器运行环境(Containized Worload)。可是无论怎么讲这一套环境中咱们还须要用到另外的两个服务。好比镜像服务(images registry)。另外为了管理咱们的集群，咱们还须要编排服务(provisioning Configuration)。接着对整个集群来说咱们都须要作监控，都要记录日志，即还须要监控系统((monitoring))和日志系统(logging)。若是能够的话k8s服务发布后还要有外置的负载均衡器(Load balancer)。另外咱们还须要公建仓库(Artifact factory)。另外咱们还须要自动化工具(Build Automation)。而且还有自动化发布工具(Rlease Automation )等。若是这个一整套环境组合完成了叫Paas，即平台即服务的环境。Openshit就是这一整套的解决方案。

　　　

　　二、PaaS实际生产使用时的注意事项，本k8s集群学习博客未进行记录的知识点，后续需进行深刻了解

​ master 节点高可用

​ kubernetes Federation (k8s集群联合，相似于双机房效果，经过Federation Api进行联合 )

​ priorityClass 优先级类别，定义哪些pod应该优先被启动等

​ limitRange 资源限制范围

​ PSP ：pod 安全策略

​ SecurityContext 安全上下文