项目划分
1.部署Prometheus和elk
在做这个项目的时候考虑到了3种Prometheus的方案，一种是单独的部署Prometheus这样的话存在一个高可用问题，后来有了解到了Prometheus operator，使用helm部署Prometheus operator的话由于当时对helm不是很熟悉，监控的重要性刻不容缓，得先把大部分的监控到，直接用Prometheus orerator的话他类似于一个写死的程序，无法数据持久化，所以我最后选择了直接部署Prometheus，然后通过脚本来检测Prometheus如果他挂了，发送邮件立即处理，然后在每个node部署node exporter 和metrics因为他k8s集群对于Prometheus支持还是挺高的。Elk的话因为我们之前是由kafka和zookeeper这种消息队列分布式集群的，而且es和logstach也在外围，就只需要在每个pod中增加一个firebeat收集应用日志，以及在节点部署file收集系统日志或者其他需要收集的
2.迁移项目
将传统环境的项目迁移至k8s集群，最重要的就是镜像的制作以及资源清单，根据当时项目的运行环境，根据centos7.6作为基础环境来搭建适合项目跑的环境，左后使用dockerfile做出来以后上传给镜像仓库，然后写资源清单，最难的是健康监测核资源限制，这两个做了很多次实验才确定数值，以及方式，因为这两个设置好了会少很多问题
遇到最大的问题就是健康检测的时间把握不准
3.k8s流水线
我需要做的就是部署jenkins的环境，可能后期流水线过多的话，就是一条线用slave来做操作，jenkins主节点负责分配，因为我们是java的项目，所以slave的环境就得有jdk和maven，用dockerfile把slave的镜像做出来上传至镜像仓库，而且需要在k8s集群内准备一个harbor的secret，接下来就是脚本的编写，首先得定义一下savle的信息，然后具体的就是先拉代码，编译构建，写一个dockerfile提供一个代码可以运行的基础环境，把代码放进去做一个镜像提交至harbor，再根据jenkins的一个k8s的插件，配置完成以后可以直接跟api做交互
通过这样来在k8s集群内部署，但是这只是测试环境，线上环境我们还是手动部署，测试的流水线把项目镜像测试过后，我们直接从harbor仓库拿镜像用就好。手动更新的话，直接set换镜像可以暂停，如果有问题的话那么更新操作取消也就是回滚上个版本，如果没问题我们就继续更新
k8s项目详细操作可以查看kubernetes专栏
https://blog.csdn.net/weixin_45413603/category_9367253.html
维护k8s过程中遇到的问题
1.对于应用的jvm限制
如果是java应用，（我原来维护的就是java应用），堆内存一旦飙高，达到limit限制的，会直接把他kill掉，然后无限重启，这样的话不是我们想看到的，所以限制应用本身的资源使用，但是要低于针对这个容器的最大资源限制
2.在更新的时候健康监测
在更新的时候健康监测尤为重要，如果没有合适的健康监测，全部替换为新版本能否提供服务尚未知晓，就贸然的引入流量，这种做法不太好，所以我们需要合适的就绪检测来检查这个应用容器是否可以对外提供服务，还需要存活检测来检查应用容器是否存活，这样来确保更新的准确性，
3.滚动更新的时候出现的丢失流量的问题
在更新的时候，kubelet会跟api交互做2个操作，一个是删除旧的pod一个是去endpoint摘掉这个pod的ip，当然删除pod会比摘ip速度块，这就会导致pod死了但是流量还在引入这个ip，那么访问肯定是失败的，给用户的极差的体验，后来发现以后，在每一个pod加入了关闭钩子，就是在pod关闭的时候可以先执行某些操作在关闭，比如睡10s，这样就可以优雅的关掉这个pod
4.针对容器做资源限制
这个是非常有必要的，因为有一次我们某个pod内存忽然飙升，就是因为没有给pod做资源限制，还好我们每个命名空间都有设置资源限制，他只是把当前他命名空间的pod oomkill了，一旦我们命名空间没有设置的话，可能会导致整个集群的容器雪崩，所以从那一次以后我们就对每个pod的资源限制以及健康监测要做很多次沙箱测试。
总而言之只是一个方向问题，这里并不能根据每个人的实际情况做出很详细，只是说是一个参考，并不需要完全按着来，可以考虑看一下运维问题处理专栏以及k8s专栏去实际的部署或者在生产环境测试然后根据自己的情况自己组织语言，在面试过程中才能将自己发挥到极致，让面试官看准你的亮点，总的来说经验必不可少，知识也必不可少，只有真正的知道了怎么用结合自己的语言说出来 才能让人感觉你是真会 就比如我一个集群3master4node 那不就直接gg了吗