私有云与公共云：Kubernetes 如何改变平衡？

当今企业大部分都会成为混合云用户。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 能够顺利地主动管理各种底层基础设施。