您正在查看 KubeSphere 版本的文档:v3.0.0

KubeSphere v3.0.0 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本

应用场景

KubeSphere 适用于多种场景,为企业提供容器化的环境,借助完善的管理和运维功能,让企业在数字化转型过程中从容应对各种挑战和各类业务场景,如多云多集群管理、敏捷软件开发、自动化运维、微服务治理、流量管理、高可用以及 DevOps 持续集成与交付等。

多集群部署

随着容器的普及和 Kubernetes 的日渐成熟,企业内部运行多个 Kubernetes 集群已变得颇为常见。概括起来,多个集群的使用场景主要有以下几种:

高可用

用户可以将应用负载部署在多个集群上,使用一个全局 VIP 或 DNS 域名将请求发送到对应的后端集群。当一个集群发生故障或无法处理请求时,将 VIP 或 DNS 记录切换至健康的集群。

高可用

低延迟

在多个地区部署集群时,可将用户请求转发至距离最近的集群处理,以此来最大限度减少网络带来的延迟。例如,在北京、上海和广州三地部署了三个 Kubernetes 集群,对于广东的用户就将请求转发至部署于广州的集群处理,这样可以减少地理距离带来的网络延迟,最大限度地实现各地一致的用户体验。

隔离

故障隔离:通常来说,多个小规模的集群比一个大规模的集群更容易隔离故障。当集群发生诸如服务中断、网络故障、资源不足引起的连锁反应等问题时,使用多个集群可以将故障隔离在特定的集群,不会向其他集群传播。

业务隔离:Kubernetes 通过命名空间来隔离应用,但这仅是逻辑上的隔离,不同命名空间之间网络互通,依旧存在资源抢占的问题。要想实现更进一步的隔离,需要额外设置诸如网络隔离策略、资源限额等。多集群可以在物理上实现彻底隔离,安全性和可靠性相比使用命名空间隔离更高。例如企业内部不同部门部署各自独立的集群、使用多个集群来分别部署开发、测试和生成环境等。

流水线

避免厂商锁定

Kubernetes 已经成为容器编排领域的事实标准,很多企业在不同云厂商上部署集群时都避免将鸡蛋都放在一个篮子,以便可以随时迁移业务,在不同集群间伸缩。缺点是成本增加,考虑到不同厂商提供的 Kubernetes 服务对应的存储、网络接口有差异,业务迁移也非易事。

为应对不同的使用场景,KubeSphere 提供统一的中央控制平面,由 Host 集群纳管 Member 集群,即多个异构的 Kubernetes 集群可以聚合在一起作为 Kubernetes 资源池。当用户部署应用程序时,可以选择应用的副本所要运行于的一个或多个 Kubernetes 集群。整个过程可以通过 KubeSphere 控制台进行管理,以可视化的方式帮助用户实现跨区域和跨集群的高可用性。

中央控制平面

有关更多信息,请参见多集群管理

多维度监控

可观测性是运维团队日常工作中的重要一环,随着企业部署在云厂商平台上业务量的不断增加,运维团队所面临的压力与挑战也与日俱增。对于将业务跨云夸集群部署的企业来说,运维团队需要处理海量的数据以对各个 Kubernetes 集群进行监控与分析。此外,如何满足企业对自定义监控指标的需求也是急需解决的问题之一。

多维度集群监控

当前,越来越多的企业和个人跨云部署多集群,然而,由于各个云厂商的环境不同,其所提供可观测性工具可能并不适用其他平台。从学习成本和监控的角度来说,进行跨集群管理和监控也并非易事。简而言之,运维团队急需一种统一的工具以对多集群上不同的指标实现多维度监控。

集群监控

日志、事件与审计查询

强大的可观测性系统需要由灵活的日志查询体系所支撑,帮助用户追踪集群内各类资源的完整信息,了解集群中的最新状况,例如告警消息、节点调度状态、应用部署情况以及网络策略变更等。由此,用户可对其业务做出相应的调整。

自定义监控

即使是在同一平台进行资源监控,云厂商所提供的工具也并非适用于所有场景。在某些情况下,用户需要建立其特有的可观测性标准,例如自定义监控指标和监控形式。此外,他们还需要手动将常用工具集成至云端,如用于 Kubernetes 监控的事实标准工具 Prometheus。换言之,自定义功能已成为行业上的必要需求,不仅需要各类云原生应用提供云上业务支撑,同时也需要细粒度全监控功能,以提前检测出任何可能对业务造成影响的问题。

如前文所述,KubeSphere 提供统一的中央控制平面用于跨云多集群管理,极大降低了运维成本。与此同时,KubeSphere 还具备强大的可观测性功能(告警通知、审计日志与事件)以监控多集群资源,为用户提供多维度自定义监控面板,用户可自行选择以何种形式监控任意资源。此外,KubeSphere 还配有多指标的日志、事件与审计查询功能,以可视化的形式提供基于多租户的日志检索。

借助 KubeSphere,企业可以更多地专注于业务创新,从复杂的数据收集和分析流程中彻底解放。

微服务和云原生架构

在企业数字化转型过程中,推动应用迅速迭代的压力也与日俱增。具体来说,企业需要加快开发流程,缩短交付时间,提高更新频率。然而,现代化、云原生应用更多地以微服务的形式部署,而非从前的单体大型应用,这也给企业的应用研发与更新带来了更多的挑战。例如,微服务之间的频繁交付需要稳定、流畅的网络连接,网络延迟不仅影响系统问题性,更会降低用户体验。如何在不影响生产环境的同时进行版本更迭成为各个企业必须要解决的问题。为此,企业需要搭建一套完整的微服务架构以及时地检测并解决潜在问题。

KubeSphere 提供轻量级、扩展性强的微服务架构,为企业创造了充分的条件以开发云原生应用程序应对各类使用场景。基于 Istio,KubeSphere 以代码无侵入的模式提供可视化、灵活的微服务治理平台,包含各类微服务治理功能,支持熔断、灰度发布、流量管控、分布式链路追踪等,助力企业一步搭建微服务架构,实现应用云原生转型。

可视化

由于服务网格的微服务之间会频繁进行交互,如果能以可视化的方式查看微服务之间通信,用户也能更好地了解微服务的拓扑关系。此外,分布式链路追踪对每个服务来说同样重要,能让管理者了解服务网格中调度流向和服务依赖。

灰度策略

当企业引入服务新版本时,可以在 KubeSphere 中采取不同的灰度发布策略。

蓝绿发布提供零宕机部署,即在保留旧版本的同时部署新版本。在任何时候,只有其中一个版本处于活跃状态,接收所有流量,另一个版本保持空闲状态。如果运行出现问题,您可以快速回滚到旧版本。

金丝雀发布将实际流量引入新版本以测试性能和可靠性,在不影响系统稳定性的同时能够检测实际环境中存在的问题。

流量镜像是一种强大的、无风险的测试应用版本的方法,将实时流量的副本发送给被镜像的服务。采用这种方法,您可以搭建一个与原环境类似的环境以进行验收测试,从而提前发现问题。

灰度发布

DevOps 落地实践

DevOps 是一套重要的实践和方法,让开发和运维团队能够更高效地协同工作。软件的开发、测试和发布也得以更迅速、高效和可靠。KubeSphere 中的 CI/CD 流水线为企业提供敏捷开发功能和自动化运维。同时, KubeSphere 的微服务治理功能,帮助企业以一种细粒度的方式开发、测试和发布服务,有效推动企业 DevOps 落地。借助 KubeSphere 的 DevOps 系统,企业可以:

  • 以代码无侵入的模式通过错误注入测试服务健壮性;
  • 可视化端到端监控流程;
  • 以图形编辑面板创建流水线,无需编写 Jenkinsfile;
  • 为流水线轻松集成第三方程序,例如 SonarQube 用于代码质检。

sonarqube

裸机环境部署

有时,云端并非资源部署的最优环境。例如,当需要大量计算资源并要求硬盘高 I/O 速度时,使用专门的物理服务器可以实现更佳的性能。此外,对于一些难以迁移上云的特殊工作负载,可能还需要通过经认证的硬件运行,加以复杂的许可与支持协议,在这种情况下,企业更倾向于使用裸机环境部署应用。

借助新一代轻量级安装器 KubeKey,KubeSphere 帮助企业快速在裸机环境搭建容器化架构,并通过 PorterLB 实现流量的负载均衡。PorterLB 由 KubeSphere 社区开源,专为裸机环境下的负载均衡所设计,现已加入 CNCF Landscape,是为 CNCF 所认可的构建云原生最佳实践中的重要一环。

有关 KubeSphere 如何推动各行各业的发展并实现数字化转型,请参见用户案例学习