共计 3656 个字符，预计需要花费 10 分钟才能阅读完成。
作者：肖念康，东莞怡合达智能制作供应链资深 Java 开发工程师，次要负责公司外部 DevOps、代码托管平台、工作需要治理平台的研发及其他我的项目的治理，云原生的钻研与开发工作。
公司简介
怡合达致力于自动化零部件研发、生产和销售，提供 FA 工厂自动化零部件一站式供给，怡合达深耕自动化设施行业，基于利用场景对自动化设施零部件进行标准化设计和分类选型，通过规范设定、产品开发、供应链治理、平台化经营，以信息和数字化为驱动，为自动化设施行业提供高品质、低成本、短交期的自动化零部件产品。
技术现状
- 在应用 Kubernetes 之前，公司始终是采纳超交融传统虚拟机的形式来部署上线我的项目，这就导致公司资源节约十分重大，每年单单在服务器的开销就大大增加。
- 我的项目在上线的过程中出错的几率十分大，并且难以排查，没有一套标准的流程，须要开发人员手动部署，导致人员耗费十分重大。
团队规模
目前公司领有 3000+ 的员工，其中研发团队（运维，开发，测试，产品等）超过 300 人，在苏州，湖北都有研发团队。
背景介绍
目前行业正在向自动化、云原生凑近，传统的互联网模式曾经无奈满足大公司的业务需要了，为了让开发人员将更多的精力放在业务上，自动化部署、我的项目的全方位监控就变得越来越重要。
目前公司云原生是刚刚起步，很多货色须要去摸索发现，所以技术上有很多欠缺，须要十分粗疏的了解各个组件的运行原理和模式。
拥抱云原生就意味着公司的 IT 层面将回升一个等级，原有的我的项目治理将齐全摒弃，将会以一套全新的形式来全方位地治理我的项目，应用 Kubernetes 和容器化技术将缩小服务的运维老本和我的项目的容错老本，为客户带来的应用体验也将晋升一个档次。
选型阐明
工具选型的过程
在应用 KubeSphere 之前，咱们也应用了很多其余的我的项目，如 KubeOperator，DaoCloud，Choerodon 等。然而在应用过程中发现，其余工具的性能并不是很欠缺，遇到问题很难排查，社区也不是很沉闷，这就导致咱们的应用老本和保护老本大大增加。
抉择 KubeSphere 的起因
我通过博客和论坛发现了 KubeSphere，Issue 的提出与解决十分的欠缺和及时。KubeSphere 官网有很多案例与解说，社区活跃度十分高。这不正是我想要的吗？
通过实际应用 KubeSphere 搭建的集群更加稳固，资源管控更加便捷，与同类云原生产品相比，KubeSphere 简直实现了咱们在生产环境会用到的所有性能。
于是咱们就开始在测试环境搭建并应用，随后缓缓地向生产环境迁徙。目前咱们公司有三分一的我的项目曾经迁徙到 KubeSphere 平台上，并且回收了之前的旧服务器，大大提高了资源使用率。
实际过程
基础设施与部署架构
Kubernetes 与 KubeSphere 的搭建也非常简单，依据官网文档先下载 KubeKey，应用 KubeKey 搭建就能够了。
目前咱们应用公有环境来搭建 Kubernetes 与 KubeSphere，因为是在咱们外部应用，所以不思考在云上进行搭建。
根底服务器采纳的是 Linux Centos 7，内核版本是 5.6。
在搭建 Kubernetes 集群时，我抉择应用 Keepalived 和 HAproxy 创立高可用 Kubernetes 集群，其中包含两个负载平衡入口。
而后是 3 个 Master 节点，3 个 Worker 节点，一个 Etcd 集群，因为是多集群，我会为公司每个我的项目创立一个集群，所有咱们单个集群调配的资源不是很多，当资源不够应用时须要进行申请。
平台的存储与网络
平台的长久化存储咱们应用的是第三方杉岩，这就须要对方来提供存储卷和创立存储系统空间，所以在这里就不做过多介绍。大家也能够应用开源的存储插件来做，KubeSphere 文档中提到了很多开源存储插件，应用起来也十分的不便。
在集群外部咱们采纳的是 Calico CNI 插件负责集群的外部通信，当咱们的服务部署至 Kubernetes 集群时会产生一个外部拜访地址，这个地址在咱们集群内是能够 ping 通和拜访的，但内部无法访问。
所以在内部网络通讯方面我做了两套计划：
- 思考到咱们之前的我的项目应用 APISIX 作为网关路由，所以咱们就在集群内搭建了 APISIX：
搭建形式也非常简单，创立一个 APISIX 模板，再创立一个利用就能够了：
创立实现之后集群内的我的项目就能够应用 APISIX 了，将 APISIX 开启对外拜访，作为集群的惟一入口，接下来在服务中创立路由，就会在 APISIX 中主动生成一条路由规定与上游服务：
- 第二种计划则是应用负载均衡器 OpenELB，OpenELB 官网提供了三种模式，咱们选用的是 Layer2 模式，因为 BGP 和 VIP 须要机器的反对，就临时没有搭建，后续会思考改用另外两种模式对外拜访。
官网文档：https://openelb.io/docs/getti…
装置和应用也很不便，能够间接在 KubeSphere 利用商店中抉择装置，也能够在集群中通过 yaml 进行装置：
然而须要留神的是，通过利用商店进行装置肯定要留神集群的内存空间是否短缺，否则会导致集群监控组件异样。
装置实现之后，咱们只须要开启 strictARP: true，并设置 EIP 池就能够了，而后咱们在部署服务时加上注解：
annotations:
lb.kubesphere.io/v1alpha1: openelb
protocol.openelb.kubesphere.io/v1alpha1: layer2
eip.openelb.kubesphere.io/v1alpha2: eip-layer2-pool
将 type 改为：LoadBalance，就会在咱们的 IP 池中获取一个对外拜访的 IP 调配给服务进行对外拜访了。
日志与监控
咱们搭建了一套 EFK 的日志零碎，通过 Filebeat 收集服务端的数据，再通过 Kafka 发送到 es 中，而后通过 Kibana 查问日志数据，另外咱们减少了一套 SkyWalking，它会给咱们生成一个链路 ID，这样咱们就能够依据这个链路 ID 间接查找以后申请下的所有日志。
在监控方面除了 KubeSphere 自带的监控之外，咱们还用了一套内部的监控零碎：
- 主机层面：Prometheus + General
- 服务层面：SkyWalking
- 包含服状态的监控以及所有的告警
CI/CD
咱们开启了 KubeSphere 的 DevOps 模块，外面集成了 Jenkins，流水线的构建，实现了我的项目从拉取代码，质量检查到我的项目部署一键化的流程。
在 DevOps 模块中用的是自定义 GitLab 仓库，如果是本人实际的话能够去 KubeSphere 利用商店中下载应用，在这里我就介绍一下自定义实现。
首先须要关上 KubeSphere 自带的 Jenkins，进入页面创立一个 GitLab 的凭证，而后在系统配置自定义 GitLab 的地址。
这里的凭据就是咱们刚刚创立的 GitLab 凭据，地址就间接填本人仓库的地址，而后就能够在 KubeSphere 中看到刚刚填写的地址了。
我是依据官网文档创立的流水线，其中有些中央须要本人指定。
在 Jenkins 中是提供一个 Maven，在这里我须要改成自定义的 Maven，不然我的项目构建的时候会失败，咱们只须要在 configMap 中批改 setting.xml 文件就能够了。
镜像仓库用的是自定义 Harbor 仓库，要在 Harbor 中先创立寄存镜像的地址，而后创立权限，在 KubeSphere 中增加凭证就能够应用了。
在应用流水线之前肯定要把 GitLab、Kubernetes、镜像仓库的凭证建好，前面间接应用就能够了。
一些前置的条件配置好之后就能够间接去创立流水线了。
运行后能够看到运行记录。
流水线跑完之后就能够在我的项目中看到之前部署的我的项目了。
包含服务和容器组，在外面就能够对我的项目进行治理了，包含负载平衡，网关，路由，扩容等一些操作。
应用成果
- 在应用 KubeSphere 之后，咱们所有的我的项目都集中在一起了，治理起来不便很多，服务器的资源也很大水平的缩小，在资金方面节俭了很多。
- 我的项目上线当初只须要创立执行流水线就能够了，再依据定时工作定时执行，并且我的项目能够主动减少正本，我的项目启动失败会主动回滚到之前的版本。
- 在业务方面，接口的申请工夫升高了，用户的应用体验也减少了不少，呈现 bug 可能疾速的定位并解决问题。
将来布局
将来咱们将把公司外部零碎与 KubeSphere 齐全买通，成立云原生小组来负责云原生的研发工作。
公司的服务器资源将齐全回收，将会以集群调配的形式治理我的项目，之后会自研一些插件和组件应用并进行开源。
对于 KubeSphere，咱们也有一些倡议：
- 心愿文档可能在具体一点，有一些插件的文档阐明只是大略的介绍了一下。
- 监控面板不是很粗疏，须要应用自定义的监控面板进行应用。
- 目前发现告警告诉方面只能在告诉聚到中配置钉钉一个地址，心愿的是在每一个我的项目中都可能配置告诉地址，这样每一个钉钉告警告诉群就可能做到互不烦扰。
心愿 KubeSphere 将来会倒退的越来越好！