生产环境的高可用Master部署方案
我司在IT设备的管理上有固定的流程，VIP这种IP地址不在标准交付范围之内。于是，我们设计了基于DNS解析的高可用方案。这种方案，是基于Load Balancer变形而来。图示如下：
这种构架方案，平衡了公司的组织结构和技术实现。如果真发生Master挂掉，系统应用不受影响，DNS的解析切换可在十分钟内指向新的Master IP，评估在可接受范围之内。
公司内部安装Master节点时，使用的基本工具是Kubeadm，但是作了脚本化改造及替换成了自己的证书生成机制。经过这样的改进之后，使用kubeadm进行集群安装时，就更有条理性，步骤更清晰，更易于在公司进行推广。
底层的etcd集群使用独立的Docker方式部署，但共享kubeadm相关目录下的证书文件，方便了api-server和etcd的认证通信。脚本的相关配置如下：
当以DNS域名的形式进行部署后，各个证书配置认证文件，就不会再以IP形式连接，而是以DNS域名形式连接api-server了。如下图所示：
公共镜像：一般以alpine基础镜像，加上时区调整，简单工具。
业务基础镜像：在公共镜像之上，加入JDK、Tomcat、Node.js、Python等中间件环境。
业务镜像：在业务基础镜像之上，再加入业务软件包。
那么，这些组件部署，我们都纳入一个统一的Nginx一级url下，二级url才是各个组件的管理地址。这样的设计，主要是为了给Dashborad及Prometheus增加一层安全性（Grafana自带登陆验证）。
这时，可能有人有疑问，Dashboard、kubectl都是可以通过cert证书及RBAC机制来实现安全性的，那为什么要自己来引入Nginx作安全控制呢？
在我们的实践过程中，cert证书及RBAC方式，结合SSH登陆帐号，会形成一系列复杂操作，且推广难度高，我们早期实现了这种模式，但目前公司并不具备条件，所以废弃了。公司的Kubernetes集群，有专门团队负责运维，我们就针对团队设计了这个安全方案。
Prometheus的二级目录挂载参数如下：
Grafana的二级目录挂载参数如下：
Dashboard在Nginx里的配置如下：
一个能生成所有软件包的Jenkins Job
在这种体系下，Jenkins就作为我们的一个纯编译工具和中转平台，高效的完成从源代码到镜像的生成。
由于每个IT应用相关的变量，脚本都已组织好，放到Prism4k上。故而，Jenkins只需要一个Job，就可以完成各样各样的镜像生成功能。其主要Pipeline脚本如下（由于信息敏感，只列举主要流程，有删节）：
在Jenkins中，我们使用了一个Yet Another Docker Plugin，来进行Jenkins编译集群进行Docker生成时的可扩展性。作到了编译节点的容器即生即死，有编译任务时，指定节点才生成相关容器进行打包等操作。
Pod的实例数，CPU和内存的配置，同样通过Web方式配置。
在配置好组件所有要素之后，日常的流程就可以基于不同部门用户的权限把握，实现流水线化的软件持续交付。
研发：新建发布单，编译软件包，形成镜像，上传Harbor库。
测试：环境流转，避免部署操作污染正在进行中的测试。
运维：运维人员进行发布操作。
下面配合截图，了解一下更具体的三大步骤。
-
发布单
在Prism4k与Jenkins的API交互，我们使用了Jenkins的Python库。
-
环境流转
-
部署
Q：Harbor有没有做相关监控，比如发布了多少镜像，以及镜像同步时长之类的？A：我们没有在Harbor上作扩展，只是在我们自己的Prism4k上，会统计各个项目的一些镜像发布数据。
Q：有没有用Helm来管理镜像包？后端存储是用的什么，原因是？A：没有使用Helm。目前集群有存储需求时，使用的是NFS。正在考虑建基于Ceph的存储，因为现在接入项目越来越多，不同的需求会导致不同的存储。
Q：想了解下，Yaml文件怎么管理的，可以自定义生成吗？A：我们的Yaml文件，都统一纳到Prism4k平台管理，有一些资源是可以自定义的，且针对不同的项目，有不同的Yaml模板，然后，透过django的模块功能统一作解析。熟悉Yaml书写的研发同事可以自己定义自己项目的Yaml模板。
Q：Pipeline会使用Jenkinfile来灵活code化Pipeline，把Pipeline的灵活性和创新性还给开发团队，这比一个模板化的统一Pipeline有哪些优势？A：Pipeline的运行模式，采用单一Job和每个项目自定义Job，各有不同的应用场景。因为我们的Jenkins是隐于幕后的组件，研发主要基于Prism4k操作，可以相对减少研发的学习成本。相对来说，Jenkins的维护人力也会减少。对于研发各种权限比较高的公司，那统一的Job可能并不合适。
Q：想了解下贵公司使用什么网络方案？Pod的网络访问权限控制怎么实现的？A：公司现在用的是Flannel网络CNI方案。同时，在不同的集群，也有作Calico网络方案的对比测试。Pod的网络权限，这块暂时没有，只是尝试Istio的可行性研究。
Q： 一个Job生成所有的Docker镜像，如果构建遇到问题，怎么去追踪这些记录？A：在项目前期接入时，生成镜像的流程都作了宣传和推广。标准化的流程，会减少产生问题的机率。如果在构建中遇到问题，Prism4k的界面中，会直接有链接到本次建的次序号。点击链接，可直接定位到Console输出。
Q：遇到节点Node上出现100+ Pod，Node会卡住，贵公司Pod资源怎么做限制的？A：我们的业务Pod资源，都作了limit和request限制。如果出现有卡住的情况，现行的方案是基于项目作拆分。Prism4k本身对多环境和多集群都是支持的。
Q：多环境下，集中化的配置管理方案，你们选用的是哪个，或是自研的？ A：我们现在正在研发的Prism4k，前提就是要支持多环境多集群的部署，本身的功能里，yaml文件的配置管理，都是其内置功能。
Q：网络方案用的什么？在选型的时候有没有对比？A：目前主要应用的还是Flannel方案，今年春节以来，还测试过Flannel、Caclico、kube-router方案。因为我们的集群有可能越机房，而涉及到BGP协议时，节点无法加入，所以一直选用了Flannel。