一、概述
1、通过以往的学习应该可以了解到k8s 和以往提到的devops概念更容易落地了。比如我们说的CI,CD,CD
CI（Continuous Integration）：持续集成
CD（）：持续交付
CD（Continuous Deployment）：持续部署
2、早期作为运维手工来实现发布和部署来讲我们一周发布一次就很头疼了，如果是持续部署的话一天可能要部署好几次甚至几十次。即当我们应用程序的程序员写完代码以后从本地推送到gitlab或者github之上，而后由对应的监控工具资源监视着事件的发生，一旦发生提交了新代码就自动的去做某些操作，比如用一些所谓的CI的工具从仓库中拖下来后做静态检查，做预部署的测试，测试完后没问题了就开始打包，打包后就发给测试，由测试部署到测试环境中，这时候就需要部署了，有些是不用部署就能测试，有些是需要部署到测试环境中来实现在线测试。所以我们做一些部署后测试。因此就有这些步骤。
3、一共大概有如下步骤：首先推送代码到仓库。然后使用CI或CD工具把代码拖下来做静态分析。然后做一些部署前测试，即不用打包就可以做的测试。比如扫描一下代码的完整性等等。然后就开始打包发给QA，由QA手动或自动部署到QA环境中。然后做部署后测试，如果没问题就可以发给我们的相关的安装部署人员，就可以交付给我们的生产环境中的运维工程师开始发布到线上去了。所以这个时候如果从开始代码推送到后面的静态分析，打包前测试，打包后测试都是自动就称之为CI，如果随后交付给运维工程师这个过程也能通过一些工具自动实现我们通常就称之为CD。运维工程师拿到后就开始发布，比如灰度，蓝绿，金丝雀等，发布上去以后如果没问题就可以跑起来了。即如果连部署也能自动执行，比如他们交付完以后由我们的发布系统自动实现将新版本通过灰度或金丝雀或蓝绿的方式发布到线上去这种方式我们就称之为CD即持续部署。这些动作到今天为止每一步都可以使用工具来实现，比如像版本控制系统，svn，vcs,git等。另外就是一些持续集成工具，比如像jenkins等。另外其还需要构建工具去实现我们代码的构建，包括编译，打包等，比如我们的make,cmake,maven,ant等。打包后的测试我们就需要相应的测试套件来实现，比如我们的单元测试，系统测试，回归测试等等。
4、如果我们要结合我们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]
5、还有一种简单的方式，我们程序员也可以写好我们的manifests，部署时这个manifests模板用ansible或者用其它工具或Go，此处他要做的有两重作用，第一，做模板引擎渲染，即把模板中那些代码替换成他应该替换的对应的值，比如我们这个manifests为了能够做到部署多种不同的应用程序，比如我这里推到一个dockerfile中镜像标签什么的都换了，因此我们把这个信息结合manifests和ansible模板引擎对manifests完成渲染而后就可以用ansible再指挥着我们k8s拖镜像来更新了。这个过程一系列文件都要准备好，而后才会触发这些组件自动工作，而我们ansible去渲染我们manifests这个组件可能不会，默认他自己都做不了。如果可以的话可以把此段结合python 实现CI CD进行发布。
二、生产环境部署k8s，接下来我们描述一下在真正生产环境中我们部署k8s应该部署成什么样子
1、我们要部署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就是这一整套的解决方案。
2、PaaS实际生产使用时的注意事项，本k8s集群学习博客未进行记录的知识点，后续需进行深入了解
master 节点高可用
kubernetes Federation (k8s集群联合，类似于双机房效果，通过Federation Api进行联合 )
priorityClass 优先级类别，定义哪些pod应该优先被启动等
limitRange 资源限制范围
PSP ：pod 安全策略
SecurityContext 安全上下文