什么时候选Cloud Foundry而不是Kubernetes

什么时候选Cloud Foundry而不是Kubernetes

Kubernetes（K8s）是一项迷人的技术。它可以运行各种不同的工作负载。然而，它并不是唯一的选择。

仔细观察Cloud Foundry（CF）你会发现，对于一些用例，Cloud Foundry环境可能比Kubernetes更受欢迎。本文重点介绍了CloudFoundry for VMs（BOSH），与值得专门比较的CF-4-K8s形成对比。

Cloud Foundry

Kubernetes的想法是作为构建平台的平台，而CloudFoundry的概念是提供一个交钥匙式的应用程序开发平台解决方案。

使用Cloud Foundry，可以在任何主要基础设施上建立平台环境，无论是公共基础设施还是内部基础设施。特别是当使用BOSH管理其生命周期时，Cloud Foundry显示了它的优势：在一个大型环境中为数百个租户运行数千个应用程序。

在这样一个Cloud Foundry环境中，操作系统的更新，只需更改几行YAML代码即可。然后，当使用基于BOSH的数据服务自动化时，更新将作为跨环境重构虚拟机的浪潮来执行。这些环境通常由数千个虚拟机组成，这些虚拟机托管来自不同租户的应用程序。CloudFoundry租户，也称为“组织”，通常用于表示组织单位，如内部业务单元。由于Cloud Foundry能够隔离租户，因此在维护集中化平台的同时，大型环境是可能的，这展现了显著的规模经济效应。

Cloud Foundry平台环境最初具有相对较大的基础设施占地面积。一般来说，Cloud Foundry环境的开销取决于冗余级别，从而取决于所生成平台的期望可用性。

一旦建立了Cloud Foundry环境，它将提供任何应用程序开发平台所需的若干关键服务，包括用户管理和身份验证服务（包括创建组织和“空间”的能力），以及跨集群调度工作负载的容器编排器，使用构建包或容器镜像以及中央服务市场部署代码的能力。

Cloud Foundry中的中心marketplace允许集成开放式Service Broker API兼容的服务代理。marketplace提供了可用服务的列表，使用户能够以按需自助方式管理数据服务实例。

假设有可用的服务代理列表，应用程序开发人员可以立即从本地代码部署应用程序，创建数据库实例（如PostgreSQL流式集群），并将应用程序绑定到数据库。开发人员的用户体验基于定义良好的API，可以使用CLI或应用YAML规范来描述工作负载。

简单地说，Cloud Foundry提供了企业级托管，实现了高度自动化，并能够实施组织策略。

构建包的使用是一个很好的例子，说明组织如何决定是否允许工程团队做出本地决策，或者通过允许任意构建包或将选择限制在经过良好测试、安全检查的构建包列表来强制使用有质量保证的资源调配自动化。

CF marketplace是中央治理的另一个例子。选择用于数据服务自动化和提供其他服务的服务代理可以对数据的处理方式进行细粒度控制。工程师不需要选择、安装和生命周期管理operator。他们所要做的就是选择一个数据服务，选择一个服务计划并创建一个服务实例。服务代理的工作是允许全面的生命周期管理，包括配置更改、版本升级、可伸缩性、日志和度量的处理等。

Kubernetes

Vanilla Kubernetes提供命名空间，这是一个用于分离Kubernetes集群内工作负载的概念。然而，命名空间并没有像Cloud Foundry组织那样孤立，Kubernetes也没有提供现成的用户管理和身份验证服务。

如果用作应用程序开发人员平台，Kubernetes环境往往与Cloud Foundry环境具有不同的结构。特别是，Kubernetes集群的数量远远多于Cloud Foundry实例的数量。虽然Cloud Foundry环境（staging或生产环境，通常包含单个Cloud Foundry安装），但Kubernetes环境通常由多个Kubernetes集群组成。虽然单个Kubernetes集群可能比单个Cloud Foundry更容易操作，但管理100个Kubernetes集群比管理单个Cloud Foundry要难几个数量级。这种情况可能看起来很极端，但它显示了潜在的问题。

管理大量Kubernetes集群会产生Cloud Foundry没有的复杂性。当然，必须承认，工作负载必须与Cloud Foundry兼容，Cloud Foundry比Kubernetes对12要素遵从性的要求更高。Kubernetes可以比Cloud Foundry定制得更多，因此可以接受Cloud Foundry无法接受的工作负载。需要指出的是：如果一个组织运行大量与Cloud Foundry兼容的工作负载，Cloud Foundry可能意味着更好的经济回报。

如果工作负载更加异构，Kubernetes胜出，而需要忍受运维复杂性的增加。

Cloud Foundry vs. Kubernetes

尽管Kubernetes可以进行配置、扩展和调整，以近似Cloud Foundry的行为，但Cloud Foundry在管理大型全局工作负载方面仍然是独一无二的。大规模云计算环境的经济回报非常好。对于主要运行12因素兼容应用程序的组织来说，它仍然是一个有效的选择，旨在为其开发人员提供最大程度的自动化。

Cloud Foundry最适合构建集中式应用程序开发平台。在它的经典变体中，使用BOSH和虚拟机自动化，创建拥有数百个租户和数千个应用程序的大型平台环境是一个很好的选择。CF推送体验和marketplace是Cloud Foundry如何帮助定义跨大型组织的统一开发人员体验的两个示例。当规模经济效应开始显现时，它最初的基础设施足迹将被遗忘，从而允许一个小型运维团队跨多个公共和内部基础设施处理大型平台环境。

特别是如果大型组织需要在具有同质用户体验的基础设施上开发和运行多个应用程序，那么应该考虑使用Cloud Foundry技术。

另一方面，Kubernetes已成为容器化工作负载的事实标准。只要高度的灵活性是必须，Kubernetes就是不二选择。

原文链接：

https://thenewstack.io/when-to-choose-cloud-foundry-over-kubernetes/