公司简介
作为物联网 + 数智化园区一体化解决方案提供商，咱们致力于为大中型园区、停车场提供软硬件平台，帮忙园区运营者实现数字化、智能化经营。
在应用 K8s 之前咱们应用传统的形式部署上线，应用 spug（一款轻量级无 Agent 的自动化运维平台）自动化在单节点实现代码部署上线，也没有进行容器化，随着产品上线提上日程，对稳定性要求进步，以及私有化部署环境治理问题，咱们开始应用 Docker 以及 K8s。
背景介绍
降本增效是每个企业的指标，而 DevOps、容器化、云原生就是研发团队降本增效的方法论。在这个趋势下，应用 Docker、K8s 简直是每个开发团队的必经之路。
物联网平台对稳定性要求十分高，一旦停机，所有设施都将掉线重连，因而保障服务的稳定性，缩小停机工夫就十分重要。
在应用 K8s 之前，咱们很多工夫都要人工解决各种繁琐反复的服务保护问题，这种干燥且毫无技术含量琐碎极大的消磨开发团队的激情。为了将人力从大量反复的环境配置、服务保护中解放出来从而进步开发迭代效率，咱们就决定全面容器化，拥抱云原生。
总结来说就是：
- 服务稳定性，自动化运维，缩小停机工夫；
- 分布式部署，弹性伸缩；
- DevOps 标准的部署上线流程。
这些问题迫使咱们开始调研容器化、Docker、K8s 的利用。
选型阐明
因为没有相干教训，因而一开始咱们就心愿找到一款可能帮忙疾速上手 K8s 的工具，在调研 KubeSphere、Zadig、Rancher、KubeVela、Kubeadm 等多款工具后，咱们最终抉择了 KubeSphere。
抉择 KubeSphere 最次要的起因首先是它的社区沉闷，有问题可能找到解决方案。同时它集成了很多开箱即用的插件如 DevOps，这正是咱们所须要的。当然第一眼就选中 KubeSphere 还是因为它的颜值，能看得出来 KubeSphere 的 UI 是通过精心设计过的，这在开发工具畛域中是极为难得的，从这点上就可能看出背地的开发团队对于打造一款基于 K8s 的云原生操作系统的理念与信心。
应用 KubeSphere 让咱们立马就领有了成熟 DevOps 工作流了，而无需额定的搭建老本，这对于咱们毫无 K8s 教训的团队来说太重要了，极大的升高了上手门槛。
目前咱们将所有无状态利用全副容器化，应用 K8s 负载，提交代码 Webhook 触发 KubeSphere 流水线主动公布，对于不习惯命令行操作的用户，KubeSphere 后盾能满足所有需要。
实际过程
容器化及迁徙到 K8s、KubeSphere
第一步就是将利用全副 Docker 容器化，而后应用 K8s 的 deployment 进行部署。实现分布式高可用的服务部署。
K8s 让咱们轻易的就领有了一个分布式高牢靠的架构了，分布式部署从未如此简略。
创立 DevOps 我的项目流水线
KubeSphere 的 DevOps 我的项目不同于惯例我的项目，这是 KubeSphere 中独有的概念，和 K8s 的命名空间没关系，流水线能够间接用 Jenkinsfile，也能够用可视化的形式创立，十分不便。
配置好公布流水线后，对于开发来说只用提交代码就行了，KubeSphere 会主动帮咱们依照预期把利用部署到集群中，上线前的最初一公里问题被彻底解决了。
治理 Pod
在 KubeSphere 后盾能够间接治理 Pod，容器信息高深莫测，还能够间接进入容器，查看容器实时日志。负载也能一键伸缩，轻点鼠标就可能疾速部署和回滚。
日志和监控计划
因为咱们之前就有了 ELK 和 Prometheus、Grafana 了，因而日志咱们只须要将容器内的利用日志采集到集中的 ELK 下来就能够了。监控也是如此，只须要采集 node_exporter 和业务指标就行了。
如果之前没有相干计划，也能够间接应用 KubeSphere 开箱即用的日志监控计划，同样也是基于 Elasticsearch 和 Prometheus 的。
多租户资源可视化
企业空间完满符合了多租户治理，这样对于私有化部署、资源利用统计都十分不便，同时企业空间下的我的项目 刚好就对应 K8s 中的命名空间，这让人十分惊喜，KubeSphere 是紧贴 K8s 规范的，不会减少任何学习应用老本。
集群状态和资源用量排行能够直观看到各节点资源应用状况，不便为将来资源估算做好布局。还能够对企业空间进行配额限度，满足了不同租户资源管制需要。
存储
因为咱们目前次要是无状态利用，对贮存要求不高，所以用的是最简略的计划集中式 NFS，因为是单节点存储，所以存在单点问题，这个前面能够应用云厂商的 NAS 存储或者其它分布式存储。
应用过程中遇到的艰难及其解决方案
- CI 构建节点配置问题
节点配置至多在 4C·16G，否则 DevOps Jenkins 可能无奈失常运行，这个还是有些占资源的，倡议 应用特定节点充当 CI 节点：为依赖项缓存设置 CI 节点
- 流水线不响应问题
有时会呈现流水线始终期待运行，或者卡住的问题，这通常是构建节点资源问题，咱们遇到过前端 node 打包 cpu 占满问题，呈现这种状况时应该首先查看打包节点的资源状况，kill 掉占用高的打包过程就行了。或尝试从新创立 DevOps-jenkins 负载通常可能解决问题。有时还须要进入 Jenkins 后盾查看问题（明码与 KubeSphere 后盾明码雷同）。
- 构建缓存问题
因为 git 缓存问题，所以咱们将 jenkins-casc-config.yaml 中定义的 Agent 配置 idleMinutes 改为一个较大的值，以实现打包 Pod 在构建后不会被删除。
之所以只能这样，是因为 base-n8qkj 的卷 workspace-volume，卷类型是 EmptyDir 长期的，如果是 HostPath 类型的就好了，这点不晓得官网是怎么思考的。
- configmap 更新问题
在 K8s 中 configmap 的更新会主动失效，并同步到各个挂载了 volumes configMap 的 Pod 下来，这样就能够实现配置更新后主动失效而不必从新公布利用。
然而在应用中咱们发现存在一个问题，这种失效机制是通过软连贯实现的（扭转软连贯指向，删除旧的文件），而某些利用可能会呈现在更新配置时，短暂的找不到文件报错的问题（phpfpm），所以针对这个状况咱们额定做了解决，原理是利用不间接挂载 configMap 了，而是通过另一个容器去挂载 configMap 并解决好稳固的文件后再供指标利用应用。
应用成果
应用 KubeSphere 后咱们简直就没再关注过服务是否在线等运维的琐碎事件了，因为 K8s 会保障所有依照预期进行，这使得咱们的迭代公布速度大大提高，开发要做的只是提交代码，其它的所有都不必操心，极大的进步了开发编码的幸福度和对保障服务稳固的信念。
- 无状态利用分布式部署，弹性伸缩；
- 主动公布，自动化运维，故障自愈；
- 一次构建到处运行，无惧环境搭建。
将来布局
因为还在逐渐学习利用中，目前对 K8s 的利用场景还比较简单，将来还有很多摸索的点，如：
- 存储上，目前为了解决 web 无状态利用 可能也会有临时文件上传等需要，应用了 NFS 存储，这样多节点 Pod 能够共享存储，前面能够尝试应用其它更为牢靠的分布式存储。
- 利用上，目前次要是将无状态利用部署了上来，随着学习的深刻，前面能够将更多的有状态利用也部署上来。
最初心愿 KubeSphere 可能越来越遍及，紧跟 K8s 官网规范，在升高上手门槛、社区、文档建设等方面一直获得冲破，让更多的人可能更疾速的享受到 K8s 的益处。
本文由博客一文多发平台 OpenWrite 公布！