前言
前段时间做了些 K8S 理论上的储备，也在测试的 K8S 集群上做了些简单的测试。虽然感觉收获颇丰，但是纸上得来终觉浅，没有经过生产环境的捶打和磨练，还是没办法掌握这种技术的精华，学到的东西更多的也只是流于表面，无法深入其中。
正巧最近有机会去客户现场实操一个200多节点的 K8S 集群，在运维大拿的帮助下，也算从公司业务流程的维度进行了完整的 K8S 操作以及运维。
虽然困难重重，但是仍然学到了很多东西，也填了很多坑，在这里记录下，方便后续查阅。如果也能为正在看文章的读者们避一些坑，少走一些弯路，那这篇文章也就功德圆满了。
废话不多说，直接开启捞干货的历程。另外，由于作者本身水平以及认知的限制，可能会有部分讲述有问题，欢迎大家纠正以及讲解。下面将从几个方面对实操 K8S 进行相关的总结。
工欲善其事必先利其器
搭建生产级别的 K8S 集群
要使用一个生产级别的 K8S 集群，首先先要搭建一套生产级别的K8S集群。
所以怎么能快速且简单的搭建生产级别K8S集群是K8S生产化所面临的的第一个问题。
当前安装 K8S 的方案有很多，但是不管是 yum 安装、二进制文件安装以及官方提供的 kubeadm 安装方式，都多多少少有一些门槛，而且安装过程也比较复杂。
这对于资深运维人员或者对 K8S 很熟悉的人来说可能还好，对于刚接触K8S不久经验不是很丰富的人来说，可能是一个艰巨的任务。
所以在这里推荐一个三方工具: Sealos。下面简单介绍下：
什么是 Sealos
Sealos 是一个 Go 语言开发的简单干净且轻量的 K8S 集群部署工具，Sealos 能很好的支持在生产环境中部署高可用的 K8S 集群。
Sealos 特性与优势
- 支持离线安装，工具与部署资源包分离，方便不同版本间快速升级。
- 证书有效期默认延期至99年。
- 工具使用非常简单。
- 支持使用自定义配置文件，可灵活完成集群环境定制。
- 使用内核进行本地负载，稳定性极高，故障排查也极其简单。
这么个简单好用稳定性高，最重要还免费的工作谁不喜欢呢？所以强烈推荐大家试一试，至于搭建流程这里就不赘述了，网上很多，大家可以自己去学习下。
管理 K8S 集群
集群搭建完毕后，肯定是要进行管理的，而图形化的 K8S 管理工具显然是刚需的。毕竟能通过页面直接看，谁不也会想去打命令。
这方面作者使用过 kuboard 以及 KubeSphere，当然还有官方以及阿里提供的其他工具。作者没用过就不过多阐述了。功能都差不多，纯粹个人习惯和喜好。
下面就说说作者用过的两种的特点吧：
- kuboard 相对于 KubeSphere 更简单明了，上手难度低，且将使用人员和运维人员切分的比较彻底。显然更适合纯 K8S 使用人员来监控和管理 K8S 集群。
- KubeSphere 的复杂性体现在将部分 K8S 的创建和维护细节放到了图形界面中。虽然这样子功能变得更强大，但是功能也会显得鸡肋。毕竟使用人员不会关注和使用这些细节，而纯运维人员更喜欢和相信命令行。
所以综上，建议刚入K8S坑的小伙伴可以优先选择 kuboard，毕竟快速用起来才是王道。
配置文件管理
基础环境搭建起来后，下面就是搭建业务系统了。而业务系统的构建基本上依赖两类资源：
- 以 configmap 为主的全局配置，用以在各种应用之间进行配置共享，类似于环境变量
- 各种业务yaml配置文件，构建业务的具体逻辑都在这里
由于业务变更以及各种调优可能会导致多版本的配置，此时一定要做好配置的版本管理。尤其是开发人员在界面上修改配置，运维人员使用yaml更新配置，这样子肯定会造成各种配置不一致，进而造成很多不惜要的开销和麻烦。
如果是开发人员和运维人员共同使用这种场景下，建议共同维护一套配置入口。优先建议维护yaml配置文件，毕竟yaml配置文件的使用场景和便利性还是比界面修改好很多。
其他有用的记录
- configmap 相关的yaml文件修改后直接使用 kubectl apply -f xxx.yaml 即可以生效。但是依赖或者引用该 configmap 的 application 需要重新启动才能加载最新配置。
- application 的重启需要考虑该 application 是否依赖于其他的 application，如果有多重依赖关系，重启时需要使用kubectl rollout restart -f xxx.yaml，该命令会将当前的 application 以及 该 application 关联的 application一并重启；反之使用kubectl restart -f xxx.yaml即可。
- 如果 application 重启时需要使用新的镜像，在不确保没问题的前提下，建议先删除旧的 application，再 apply 生成新的application。否则在极端情况下，新的镜像报错，重试一定次数后 K8S 会加载旧的镜像，导致各种问题。
- 如果 application 依赖于主机名的映射，如HBase以及kafka等应用，可以通过
- 探活机制是个很有用的机制，健康检查以及 POD 状态管理和重启管理还是需要依赖于这个机制的。对于高可用性的系统这个机制还是不可或缺的。详细可以参考下图：
- K8S 有个比较尴尬的问题，如果将程序运行放在 POD 启动的时候，如果程序报错，那么 POD 中的很多信息由于 POD 未能启动而无法获得，给错误定位带来很多困难。所以建议在调试阶段加上部分机制保证调试的便利性。
如下图所示：
正常情况下可以通过docker_run.sh写在docker镜像的启动脚本中来直接启用镜像。
如果需要调试则可以打开注释，使用command命令使用tail命令先保证 POD 启动起来，然后再手动执行docker_run.sh来启动服务，此时的 POD 已经启动完毕，不会因为启动报错而关闭，相关排错的任务就可以进行了。
这里也需要注意下上面提到的探活机制，如果有该机制且探活周期比较短，建议暂时关闭探活机制，否则 POD 会因为探活机制而频繁重启。
总结
以上就是我这次去客户现场操作生产环境 K8S 的一点心得和经验，后续有新的内容我还会继续分享。这次的经历再次印证了只有在生产环境下真实的分析和解决问题，才会更深刻的学习知识并积累相关的经验。
文章到这里就结束了，最后路漫漫其修远兮，大数据之路还很漫长。如果想一起云原生以及大数据的小伙伴，欢迎点赞转发加关注，下次学习不迷路，我们在大数据的路上共同前进！
