关于云计算:文鼎创智能物联云原生容器化平台实践

作者：sekfung，深圳市文鼎创数据科技有限公司研发工程师，负责公司物联网终端平台的开发，稳定性建设，容器化上云工作，善于应用 GO、Java 开发分布式系统，继续关注分布式，云原生等前沿技术，KubeSphere Contributor，KubeSphere 社区用户委员会深圳站委员。

公司简介

深圳市文鼎创数据科技有限公司创建于 2006 年，是寰球当先的线上身份认证解决方案提供商，专一网络身份认证，数据安全畛域，保持持重经营，继续翻新、凋谢单干，在金融电子化、政府、企业办公等利用中提供解决方案，成为泛滥国有商业银行、全国性股份制银行、城市商业银行、农村商业银行、各省市税务、政府、各大 CA 机构以及跨国企业的合作伙伴，累积服务近亿用户，一直满足客户差异化需要。

公司多年来继续翻新，申请了大量的发明专利、实用新型专利和产品外观专利；注销了多项计算机软件着作权，同时是国家级高新技术企业；领有商用明码产品型号证书、明码检测证书、银联认证证书、ISO9001:2015 国内品质管理体系认证及 ISO14001 环境管理体系认证；产品通过了 CE/FCC 认证、RoHS 认证。

公司作为国内线上疾速身份验证联盟（FIDO）的核心成员之一，致力于实现寰球对立的在线验证规范，咱们将使用该技术为不同地区的人们提供享有平等的平安网络世界的权力。

背景介绍

“文鼎创智能物联”是深圳市文鼎创数据科技有限公司针对物联网利用，推出的物联网解决方案，计划蕴含对立的物联网服务平台、”云打印机“、”收款云音箱“、”收款云扫码盒子“等旗下产品，为用户的数据安全保驾护航。

作为一家 TO B 解决方案的硬件提供商，“硬件为主，软件为辅”是公司长期以来的开发模式，因而后期在对服务端的开发、部署、架构设计器重不够。传统的我的项目停留在单机（虚拟机）部署，人工打包上传，不仅费时费力，还容易出错，造成服务的不可用。

在拥抱 K8s 之前，咱们也尝试过 docker-compose 的计划，绝对于人工打包部署，docker-compose 也的确给咱们带来了一些便当：

1. ALL-IN-ONE，提供一键式的软件部署计划，无需执行繁琐的部署流程；
2. 隔离了宿主机零碎的差异性；
3. 缩小了运维人员进行版本迭代的操作，升高操作失误的可能性。

在面向物联网行业推出新产品，新解决方案之后，对服务的稳定性，以及可靠性带来了新的挑战，现有的开发模式逐渐跟不上业务的迭代需要，为此咱们迫切需要突破现有的框架，摸索新的一套软件迭代流程。

选型阐明

在决定拥抱云原生之时，咱们对市面上的容器治理平台进行了调研，发现国外 Rancher 用户较多，国内 KubeSphere 位居前列。咱们对容器治理平台的选型有几个规范：

1. 生态：一个开源我的项目的生态是否欠缺很重要，周边配套的工具能带来极佳的应用体验和可维护性。
2. 社区活跃度：官网仓库 Issue 或问答社区是否回应及时，代码提交是否沉闷？
3. 商业公司或基金会反对：是否有商业公司或开源基金会反对，如果为集体我的项目，后续进行保护，则可能会给用户带来的肯定的危险。
4. 技术栈：应用的技术栈与团队是否吻合，是否有能力解决和保护？
5. 用户体验：是否有 UI 操作界面，界面是否好看，应用晦涩？
6. 本土化：是否做了一些本土化的优化，合乎国人的应用习惯？

在调研选型时，咱们发现 KubeSphere 能充沛满足的咱们的要求。KubeSphere 团队开源的 KubeKey 工具，能帮忙咱们疾速搭建一个 KubeSphere 集群，省去了繁琐且简单的部署流程，OpenELB 我的项目则为咱们提供了本地集群负载平衡的解决方案。

在应用过程中发现的问题，在中文问答社区根本都能找到对应的解决方案。KubeSphere 的控制台简化了 Kubernetes 服务的部署，使得团队一些没有 K8s 应用教训的成员也能疾速上手，用过的共事都说好。

目前架构

目前采纳微服务设计，开发语言以 Golang、Java 为主，服务之间通信应用 gRPC。

生产环境应用两个腾讯云 CLB 别离接入来自业务和物联网终端的流量。整个业务服务部署在腾讯云 TKE 集群，并应用 KubeSphere 来治理利用的日常公布。而集群的基础设施，本着“能买就买，切实不能买就自建”的准则（并不是不差钱，而是小公司运维压力大）。之所以没有应用 TKE 的控制台来治理利用的公布，次要是 TKE 的控制台体验并不是很敌对，另外一个很重要的起因，利用商店对第三方 Helm 仓库反对很差，无奈充分利用 Helm 的生态。

实际过程

硬件资源

测试环境：10 台 ESXI 虚拟机，自建 Kubernetes 集群。

生产环境：7 台 腾讯云 CVM 节点，Kubernetes 应用腾讯云托管 TKE 集群。

存储计划

测试环境：应用 3 台 ESXI 虚拟机作为分布式存储 Ceph 的 OSD 节点。

生产环境：出于老本和稳定性的思考，应用腾讯云 CBS 作为 K8s 存储计划。

最小化装置

因为生产环境和测试环境曾经有一些内部服务，比方 Prometheus 和 Logging，为了最大化利用现有资源，在部署 KubepShere 采取了最小化装置。

值得一提的是，Monitor 并不是可插拔组件，即便最小化装置，KubeSphere 仍然会默认装置，在生产环境中，装置 TKE 监控的 prometheus-operator 会与其抵触，须要敞开 KubeSphere 的 Prometheus 或者手动卸载。

DevOps

在晚期开发阶段，版本迭代是一件十分苦楚的事件，开发人员在本地编译打包后人工上传到服务器进行部署。在经验了屡次各种环境差别，人工操作失误教训后，团队下定决心扭转现有的流程，决定搭建适宜团队本身的 DevOps 体系。

1. 继续集成（CI）：开发在每次提交代码之前都进行 CI，以确保代码的品质和一致性。这包含运行单元测试，代码动态剖析，编译和构建过程等。当 CI 失败时，开发立刻修复代码并从新提交。
2. 继续交付（CD）：一旦代码通过了 CI 流程，就将其交付给测试团队进行测试。测试团队进行测试以确保产品的品质。在测试环境，应用了 Coding 的自定义节点作为 CI 的自动化构建，CI 通过后通过脚本自动更新 KubeSphere 的镜像版本。在生产环境，因为波及公布评审流程，配置变更，各个业务团队的协调，目前临时还是交由运维人员手动变更利用版本进行公布。
3. 监控和警报：一旦代码被部署到生产环境，对其进行监控。监控能够帮忙团队疾速发现和解决问题，确保产品的可用性和性能。

目前的 DevOps 实际，次要解决了团队以下的痛点：

1. 对立编译环境：规定我的项目内应编写 Dockerfile，应用 Docker 容器内的编译环境进行编译，同时应用 Gitlab Runner 通过代码提交事件触发代替开发机本地编译，从而隔离各个开发机环境的差别。
2. 公布版本可追溯：晚期我的项目版本治理非常随便，全凭开发人员情绪命名。导致呈现问题时无奈疾速定位。为此，咱们约定在 CI 构建时，镜像版本须要满足特定的命名格局，如：${VERSION}-${ENV}-\${CI_NUMBER}，这种命名格局能够帮忙咱们疾速定位到某个环境呈现问题某次 CI 构建的版本。
3. 平滑迭代：晚期我的项目应用单机单体部署，在进行迭代时，经常有短时间的服务不可用，导致流量损失。在进行容器化革新后，利用 Kubernetes 的探针，能够进行服务的平滑更新，并且在服务状态不衰弱时，能主动重启，无需人工染指，大大晋升了服务的可用性。
4. 运维效率：充分发挥 Kubernetes 的运维体系和云原生的可观测性实际，升高了多业务多环境运维的压力。在服务故障产生时，可能及时感知。

应用成果

流水线配置

流水线应用了 Coding 的计划，有以下几方面的思考：

1. 可能深度交融企业微信，在 CI 过程，有任何问题可能及时通过 IM 工具告诉到开发；
2. 配套工具欠缺，官网的 Jenkins 有点跟不上云原生的倒退，须要装置一系列的插件能力满足需要，配置过程也很繁琐。

利用部署

“文鼎创智能物联”我的项目已全副应用 Helm 利用公布，在应用过程，发现 KubeSphere 一个比拟不敌对的体验，如果降级利用因 yaml 文件配置谬误导致利用降级失败，会无奈再次降级。在生产环境中，利用无奈降级是一个很蹩脚的问题，发现该 Bug 后，已提交了修复代码给社区并合并 fix: can not re-upgrade helm application in a failed state。

集群资源监控

KubeSphere 内置的监控零碎，满足运维人员日常对集群衰弱状态的巡检，同时 KubeSphere 提供了多个层面的监控，针对 namespace 和服务自身，团队应用频次较高的是服务监控，以便开发人员对本身公布的服务的资源应用状况有所理解。

将来布局

1. “文鼎创智能物联”作为公司摸索的新我的项目已全面完成容器化工作，运行在 KubeSphere 集群，将来打算将历史遗留的 TO B 我的项目进行容器化革新和迁徙到 KubeSphere 集群，晋升我的项目的可维护性和可用性。
2. 摸索 Service Mesh 计划，进一步晋升服务的安稳公布和可观测性。

本文由博客一文多发平台 OpenWrite 公布！