KubeSphere 在互联网电商行业的应用实践

来自社区用户（SRE运维手记）投稿

背景

在云原生的期间背景下，Kubernetes 已经成为了主流选择。然而，Kubernetes 的原生操作复杂性和学习曲线较高，往往让很多团队在使用和管理上遇到挑战。因此，市面上出现了许多对 Kubernetes 进行封装和优化的工具，此中 KubeSphere 是一个集成了多种开源工具、提供全方位解决方案的企业级容器管理平台。
我们团队早期在持续集成和持续交付（CI/CD）、微服务治理、多租户管理和 DevOps 自动化方面就遇到了不少挑战，如 Jenkins 的权限管理短板、开辟调试交互困难、多集群管理分散增加运维成本等。为了提升开辟服从和运维质量，我们决定评估和引入一个适合的 Kubernetes 平台工具。经过调研和比力，我们最终选择了 KubeSphere。
选型说明

我们选择了 KubeSphere 3.3.2 版本，在选型过程中，我们重要考量了以下几个因素：

• 易用性：平台是否提供直观的用户界面和简单易懂的操作流程，能够降低学习成本。
  
• 功能完备性：平台是否集成了 CI/CD、监控、日志管理、微服务治理等功能，能够满足我们现有和未来的需求。
  
• 扩展性：平台是否支持插件机制，能够方便地集成第三方工具和服务。
  
• 社区活跃度：平台的社区是否活跃，是否有实时的技术支持和丰富的文档资源。
  

在对比了几款主流的 Kubernetes 平台工具后，我们发现 KubeSphere 在上述几个方面表现得都非常出色。尤其是在易用性和功能完备性方面，KubeSphere 提供了用户友好的界面和全方位的功能集成，能够显著降低我们的运维难度和学习成本。
实践过程

基础设施与部署架构

我们使用的是公有云情况，划分了 3 个 VPC，分别为非生产网络、生产网络，以及运维网络，此中非生产和生产网络隔离，而运维网络与其他网络打通，我们在运维网络中部署了运维中控平台用于管理这 3 个 VPC 的资源，KubeSphere 则借助其联邦模式，以运维网络的集群为主，别的网络的集群为成员，实现多集群管理，为了方便运维中控平台的管理，服务器推行了标准化，保障规格和配置的一致性，统一接纳 32 核 128G 的配置，操作系统为 Centos7.9。
KubeSphere 集群节点界面截图：

部署架构示意图：

相干业务与 KubeSphere 的契合点

在选择和使用 KubeSphere 的过程中，我们发现它与我们现有的业务需求有着高度的契合，具体表现在以下几个方面：

• 持续集成与持续交付（CI/CD）：我们的开辟流程高度依赖于 CI/CD 流水线，以确保代码的快速构建、测试和部署。我们接纳的是 Jenkins pipeline 的技术方案，恰好 KubeSphere 也集成了 Jenkins，支持 pipeline 的流水线发布，使我们能够快速迁移和集成现有的 CI/CD 流程。
  
• 可观测性和日志管理：KubeSphere 集成了 Prometheus、Grafana 和 EFK（Elasticsearch、Fluentd、Kibana）等工具 ，与我们在用的运维技术框架非常相似，也方便我们快速迁移。
  
• 易用性和用户体验：Kubernetes 的原生操作复杂性较高，而 KubeSphere 提供了直观的用户界面和简单易懂的操作流程，使得我们的开辟和运维人员能够快速上手并高效使用。KubeSphere 的易用性大大降低了我们的学习成本，提升了团队的整体工作服从。
  

总的来说，KubeSphere 在多个方面与我们的业务需求高度契合，通过其全面的功能集成和优秀的用户体验，显著提升了我们的开辟和运维服从，确保了业务的持续稳定运行。
存储与网络

存储
因为是公有云情况，我们选择了阿里云 NAS 作为 K8s 集群的存储，走的是 NFS 协议，我们根据存储的性能（通用型和极速型）定义了两个 StorageClass，此中有状态应用使用的是极速型存储，延迟在 0.3ms 左右。另外还安装了 csi-provisioner 插件，赋予集群自动创建和删除卷的能力，提升运维服从。
网络
cni 插件用的是阿里云的 Terway 独占 ENI 模式，为每个 Pod 分配一个独立的 ENI 和 IP 所在，每个 Pod 都拥有自己的网络接口，而且网络性能更接近于传统假造机。
平台和应用的日志、监控、APM

日志
为了保持业务埋点数据采集流程不受影响，我们接纳 Filebeat+Logstash+Elasticsearch+Kibana 的日志采集和分析方案，在 k8s 集群部署 filebeat deamonset 采集日志至外部 Logstash 集群，经过日志加工处理后存入 Elasticsearch 集群，Elasticsearch 集群接纳冷热分层存储，最近 14 天的日志数据会被存储在热节点，超过 14 天的日志数据会被转移到冷节点。

日志告警使用 elastalert2，根据自定义的规则实现日志告警，为了方便规则配置和管理，我们在运维平台开辟了 elastalert2 可视化管理界面

监控
使用 KubeSphere 平台集成的 Prometheus-operator+Grafana，多集群采集的监控指标数据通过 RemoteWrite 的方式传给 Thanos-Receive，再由 Alertmanager 根据计谋进行告警，告警的数据会经过我们自主开辟的 NotifyCenter 进行数据格式化、告警分组等，最终推送到电话大概谈天会话。

APM
前端使用 Sentry，后端使用 Skywalking，二者之间通过 RequestId 进行打通实现全链路监控，用于异常定位和性能分析。
CI/CD

在 KubeSphere 中，我们通过集成 DevOps 流水线功能和 Jenkins Shared Libraries 进步了 pipeline 的可管理性和代码的可复用性。Shared Libraries 的引入有效地解决了我们以往流水线杂乱和难以管理的局面，使得 CI/CD 流程更加高效和一致。
别的，为了进一步统一和管理 Kubernetes 配置，我们接纳了 Kustomize 来管理 K8s YAML 文件。Kustomize 允许我们通过不同的 overlay 轻松管理各种情况的配置差别，确保配置的一致性和可维护性。
这种整合使得我们在 KubeSphere 中只需创建一个简单而高效的流水线，Jenkinsfile 的复杂度也大大降低，示比方下：

有状态服务管理

我们已经将 Mysql、Redis、Clickhouse、Zookeeper、Etcd 等有状态服务部署到 K8s，使用有将近一年多，很是稳定，同时也避免了传统服务器部署的单点隐患。
使用结果

使用结果重要总结为以下五点：

• 稳定可靠：KubeSphere 在使用过程中表现出极高的稳定性，未出现任何异常。
  
• 服从提升：KubeSphere 的自动化部署和流水线管理功能显著提升了开辟和运维服从。通过集成 CI/CD 流程，淘汰了手动操作和人为错误，加速了代码发布和部署速度。
  
• 用户体验：KubeSphere 的直观用户界面简化了操作，降低了学习曲线。统一的管理平台使团队成员能够更高效地进行日常运维和监控管理，提升了整体工作体验。
  
• 安全管理：KubeSphere 提供了细粒度的权限控制和全面的审计日志功能，增强了系统的安全性。通过统一的安全计谋管理，我们能够更好地保护敏感数据和关键应用。
  
• 降低成本：通过 KubeSphere 的便捷可视化管理，运维可以将部分工作实现开辟人员自助化管理，有效降低了运维成本。
  

未来规划

随着 AI 智能范畴的崛起，出现了不少优秀的 AI Agent，也让我们不得不去思索和探索 AIOPS，我们希望未来的运维场景可以跟 AI 有更多的结合，如故障分析、告警自愈和预测分析等等，同时也希望 KubeSphere 有 AI 功能的出现，相信未来的运维会更加精彩。

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。