关于云计算:私有云与公共云Kubernetes-如何改变平衡

37次阅读

共计 3459 个字符,预计需要花费 9 分钟才能阅读完成。

当今企业大部分都会成为混合云用户。2021 年 Statista 对 750 家企业的考察发现,82% 的企业采纳了混合云计算策略。

然而,这种混合采纳统计数据并不意味着公有云与公共云的问题是通过采纳两种云格调的混合来奇妙地决定的。相同,这意味着部署架构很简单,倒退迅速,以“一次性”的形式决定云架构是没有意义的。

事实上,当初云技术堆栈中正在产生的事件正在开释新的后劲。通过多年寰球采纳公共云的趋势,这些新的能源正在扭转云经济,重振公有云的理念,为治理公共云提供新的策略抉择,并启用新的裸机模型,如边缘、物联网和“裸机云”产品。

1、云经济学:v1.0

采纳云计算的开始是因为本地数据中心的构建和保护老本很高。服务器价格昂贵并且曾经过期。他们须要来自多个服务提供商的设施、电力、冷却、外部网络、广域网连贯和骨干连贯。数据中心有架构师来隔离故障域并调配冗余资源,从而实现弹性。

工作人员保护、操作和爱护它们。全职管理人员在优化它们之前剖析它们的性能、应用效率和其余个性,通常是迟缓而低廉的。企业依然被锁定在特定的地位,并且可能陷入弹性悖论——为未应用的容量付费,但无奈疾速扩大以满足意外需要。

这只是一个开始。为了实现低水平的经营效率,许多用户持续应用许可的操作系统施行“规范”数据中心堆栈,增加用于服务器配置和许可证治理的工具,并最终锁定本人进入该解决方案集。

而后,为了进步速度并实现开发人员和业务部门的自助服务,他们增加了一个相似设计的、基于老本的公有云基础架构即服务解决方案。这进步了效率,但也进步了技能的新要求,减少了新的锁定因素和许多新老本。

与此相比,私有云看起来也是不错的抉择。一切都是经营收入,没有物理设施,也没有运行物理数据中心所需的间接开销或员工老本。企业永远不用与运营商打交道,能够从小处着手,而后疾速发展壮大,或者依据须要频繁更改规模。

企业能够将工作负载搁置在提供商所在区域的任何地位,并且能够应用一组 Web UI 和 / 或 API 来配置和配置任何想要的货色。这就像跳过整个“物理基础设施”步骤的复杂性和限度,间接进入“弹性计算云即服务”局部。

(1)提醒云复杂性

每个应用公共云的公司都会受到简单账单的困扰。云定价的复杂性也会使制订和施行老本升高策略变得艰难。

同时,很少有企业在不采纳一些传统思维的状况下进入公共云。为了取得敏捷性和弹性,企业往往会就义一致性。他们多年来始终在外部构建以 VMware 为核心的基础设施即代码,当初他们延聘了业余人员来为 AWS 环境创立和保护新的代码库。

这样做的老本是微小且继续的。它会引入安全漏洞,为人为谬误提供新的机会,并使所有变得更加艰难。

在其余状况下,企业可能会尝试通过加倍努力来放弃一致性,当他们冒险进入公共云时,采纳他们的“规范操作系统”和“规范 IaaS”操作模型,放弃传统的老本构造。

或者,他们可能会转向相同的方向,购买由公共云 Web UI 和 API 驱动的公有云解决方案,取得一致性并缩小对各种技能的需要,但代价是更大的锁定。

2、云经济学:2.0 版

然而,将 Kubernetes 放入这种组合中,它会扭转一些事件:

1)Kubernetes 并不关注 Linux 内核之外的事件。 现在,调整任何实在或虚构的盒子和 Linux 变体来运行设计良好的 Kubernetes,通常只须要适当的资源配置(盒子须要足够的内核 /RAM/ 存储 / 网络 + 安全性能力平安地实现工作)。

2)统一的 Kubernetes 实现了基本的工作负载和配置可移植性。 除非工作负载对硬件有特定要求(大多数状况下没有),否则企业会冀望在 Linux Spin X 上开发的工作负载能够在任何中央的任何 Linux X 机器上运行。

部署在逻辑上自类似的 Kubernetes 集群上的容器和配置也是如此。事实并非如此,因为人们构建或获取了不同的集群,而后尝试将它们编织到更大的架构中以减速软件交付,应用 CI 自动化和其余工具,或者做手工劳动,以覆盖增量。

3)除非在极其状况下,Kubernetes 能够让简单而辣手的应用程序顺利运行,而无需继续的人工关注。 毕竟,这就是它的设计目标。企业还能够在堆栈中的所有内容上运行滚动更新,而无需使应用程序或操作脱机。

4)Kubernetes 容许企业增加自定义性能来察看和保护简单的零碎状态,并将零碎交融到新状态以响应申明性配置的变动。 这些能力能够从 Kubernetes 驻留在堆栈中的地位向上和向下工作。

因而,Kubernetes 操作符和相似构造可用于管理应用程序(向上)和底层基础设施(向下),例如物理和虚拟主机、虚构网络和云服务。

5)Kubernetes 能够进行配置和扩大,为应用程序提供大量服务。 例如存储、DNS,无论应用程序须要什么,Kubernetes 都能够代表工作负载提供和编排服务,这就是它的设计目标。

6)Kubernetes 的扩大速度十分快。 不计算启动节点所需的工夫,古代 Kubernetes 发行版能够在几分钟内扩大到任意数量的节点。

7)Kubernetes 能够十分精密。 古代 Kubernetes 发行版应该让开发人员在单个桌面容器或一对 Raspberry Pi 上启动控制器和工作器。同一个发行版应该同样可能运行 50/100/500 节点的集群。

正如大多数长期用户所发现的那样,有机的“大量集群与一个微小的集群”模型成果最佳,起因有很多。然而,真正的益处只有在“许多小集群”都能够自洽并集中管理生命周期时能力产生。

Kubernetes 的超能力以重要形式扭转了游戏规则。如果企业能够部署、扩大和治理 Kubernetes 的生命周期,则能够应用它来铺平公共和公有云基础设施,踊跃优化老本和开销,并将 Kubernetes 下的所有内容视为商品。

1)升高云经营老本。 用户的晚期试验表明,这种办法能够疾速升高公有云经营的总成本。以 Kubernetes 为核心的基础设施很大水平上会思考本人,运营商会“向上”优化工作负载,“向下”来治理主机、操作系统和其余反对服务和层。这使得运行公有云,特地是当它们变得更大时,老本和危险要低得多。

2)升高主机 / 客户机操作系统许可和反对老本。 Kubernetes 对 Linux 内核和 CPU 有局部关注,但其余方面并不多。以 Kubernetes 为核心的基础设施并没有真正受害于底层低廉的“企业”Linux。

企业 Linux spin 提供的专用加密(例如 FIPS)等性能正在迅速回升到容器运行时和 Kubernetes 发行版中。能够启用 Kubernetes 自身来治理原始裸机基础设施,从而使服务器池治理解决方案变得不那么重要。

3)升高硬件老本。 例如,寰球转向更便宜的 ARM64 CPU 的状况正在减速,局部起因是容器和 Kubernetes 使转移和重建工作负载变得更加容易。

甚至在某些方面,以性能为导向(绝对于老本、能源或其余方面)的硬件倒退可能会停滞不前,尤其是在公共云中,因为“升高”硬件的经济性对规模供应商而言非常具备诱惑力。与此同时,能够说更重要的是出于监管、管辖和主权起因以及连接性的地位。

这对公有云运营商来说是个好消息。现在,构建集中式计算 / 存储 / 网络比以往任何时候都便宜。数据中心自身正在发生变化,变得更小,应用更少的电力和冷却,散布在更多的地位,向边缘挪动并进入微型设施群。

4)运行公有 IaaS 云的新的和更便宜的形式。 以 Kubernetes 为核心的基础架构非常适合以低经营老本持重、灵便地运行简单的要害软件。

例如,裸机服务器池能够在开源基础设施即服务 OpenStack 下将 Kubernetes 作为底层运行,而不会升高性能,从而提供更高的弹性、无缝更新和轻松扩大,同时为经典虚拟机、网络和存储提供弱小的反对。

5)升高自动化老本。 为开发、测试、暂存和交付应用程序到生产环境打造平安、牢靠、高性能的工具链对于让客户称心并升高业务危险至关重要。

如果企业的指标是统一的 Kubernetes 集群模型(绝对于不同的公有云和公共云基础设施),那么只须要这样做一次,而后花工夫改良与底线相干的内容。

3、统一的 Kubernetes 无处不在

应用 Kubernetes 作为“基础设施”的底线要求是企业须要可能在任何中央部署、察看和治理一个统一的 Kubernetes 集群模型的生命周期。

这使得以 Kubernetes 层为指标的应用程序、配置、CI/CD 和操作自动化可能以雷同的形式工作,无论是针对在服务器机房的刀片上运行的集群还是针对在 AWS 实例上运行的集群。

这意味着有人正在启用此性能并使 Kubernetes 可能顺利地被动治理各种底层基础设施。

正文完
 0