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

2024-06-25 17:04 由 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 集群节点界面截图：

部署架构示意图：

存储与网络

存储

因为是公有云环境，我们选择了阿里云 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 发布！

热门相关：锦绣田园：医女嫁贤夫明尊恐怖复苏 99次离婚：厉少，请低调别吃那个鬼

背景