Kubernetes 扩容方案选择:谈谈成本及多集群应用

阅读数:1 2020 年 5 月 16 日 17:18

Kubernetes扩容方案选择:谈谈成本及多集群应用

Kubernetes 有许多受用户喜爱的功能。它提供了一种在大型资源池上部署和运行应用程序的最佳方式。

凭借其易于使用的 UI 和开箱即用的 RBAC、监控、审计、日志等功能,Rancher 可以轻松地管理企业级 Kubernetes。

使用 Rancher,IT 运维人员可以轻松连接他们的云提供商(阿里云、腾讯云、华为云、百度智能云、平安云、AWS、GCP、Azure 等)或者数据中心,只需简单点击几下就可以创建集群。

随着企业对 Kubernetes 需求的增长,IT 运维人员可以有两种选择:

  • Scale Up:团队在相关项目上一起工作,不需要通过添加更多节点来扩大现有集群的规模。
  • Scale Out:由于安全问题、资源回收或其他原因,团队需要高度隔离,可以通过添加更多集群来 scale out Kubernetes 环境。Rancher 均支持这两种选择。

要如何做到无论选择 scale up 还是 scale out,都能够确保企业级 Kubernetes 管理的工作量和成本都控制在一个比较低的水平呢?

支持多集群应用程序就是实现这一目标的其中一步。尽管名称上仿佛表示该功能仅适用于多个集群,但其实它也适用于同一集群中的多个项目。

Scale up 场景

随着对高可靠性、高可用性或更大规模集群的需求增长,集群管理员可能会向现有集群添加更多节点。为了实现某种程度的隔离,管理员可以为每个团队提供他们自己的项目。Rancher 中的“Project(项目)”的概念比命名空间更高一级,可以使用 RBAC 进行限制。

使用相同集群的团队仍然可以在自己的项目中工作,而不需要查看其他项目。出于公司的需求或者不同的团队可能使用相同的应用程序,因此必须将该应用程序的副本 push 到多个项目中。例如,由内部开发人员组成的项目团队可能必须与外包团队协作。因为他们必须在相同的应用程序上工作,而需要有自己的独立实例,因此两个项目中都应该有应用程序的副本。

Kubernetes扩容方案选择:谈谈成本及多集群应用

Scale out 场景

随着 Kubernetes 在企业中的应用越来越多,我们经常发现客户会构建多个集群,以在不同的团队之间获得最高级别的隔离。在这种情况下,企业需求(例如需要在每个集群中部署安全工具)要求集群管理员将相同应用程序的副本 push 到每个集群。

在客户可能拥有数百(甚至数千)个集群的 边缘计算场景 中,这种问题的复杂度是指数级的。

为何多集群应用程序如此重要

在这两种情况下,将应用程序副本部署到多个目标的场景都算是较小的问题。更难的地方是,如果没有复杂的脚本和高度熟练的支持团队,想要升级和维护这些应用程序的同步几乎是不可能的。

这就是对于多集群应用程序的支持变得如此重要的原因。想象一下在同一(或多)集群上的多个项目内针对应用程序的 Helm charts,我们需要提供配置的值,覆盖项目 / 集群具体的设置,然后单击一个按钮部署应用程序。

为这些应用程序选择升级策略(滚动或同步更新)的能力,进一步简化了应用程序保持最新版本的方式。

可以说,无论是那些支持具有多个集群的企业级 Kubernetes 用户,还是那些职场时具有多个项目、单个集群的用户,多集群应用程序都拥有着强大的能力。

总结

百闻不如一见,试着用用它吧。你可能会发现,采用 Kubernetes 作为你的企业策略并不会像有些人说的那样复杂!

一切开源,欢迎在 GitHub 中下载:

https://github.com/rancher/rancher/releases

如果有任何需要反馈的内容,请进入 Github 中的 issue,或者直接加入我们的论坛或者扫描文末二维码,加小助手进技术群,与同道中人一起交流。

Issue 反馈:

https://github.com/rancher/rancher/issues

论坛链接:

https://github.com/rancher/rancher/issues

评论

发布
暂无评论