首席信息官需要解决的混合云挑战

企业的IT团队需要采用一种标准化的应用程序开发方法，才能真正从混合云中获益。而容器和Kubernetes可能是实现这一目标的关键。

首席信息官在寻求部署混合云时面临着真正的挑战。他们需要创建应用程序模型，以解决其数据中心、安全性和合规性规则的问题，同时还要充分利用公共云的弹性。

云计算的最大好处是敏捷性——能够替换损坏的组件或扩展过载的组件。但首席信息官们发现，当将云计算前端整合到混合云架构中时，其弹性比预期的要低。这是因为这些应用程序后端的数据中心部分不能以同样的敏捷性来响应问题。事实上，可扩展的云计算前端可能会导致内部部署、遗留应用程序过载，并抵消公共云的好处。

第三方供应商和云计算提供商已经增加了更多的容器和Kubernetes服务来应对这些混合云挑战，但是内部部署和公共云模型之间的这种脱节仍然是当今首席信息官的主要障碍之一。

为什么首席信息官会转向容器、Kubernetes和PaaS模型

容器化应用程序和Kubernetes部署的组合适用于各种场景，从传统的单片应用程序到基于微服务的云计算应用程序。该策略可以在混合云中统一部署和重新部署实践。而且，由于所有主要的公共云提供商都支持容器和Kubernetes，并提供托管的Kubernetes服务，因此多域Kubernetes方法还可以统一跨多个公共云的部署。

但是，容器/Kubernetes方法仍然不完善。考虑到云原生组件关系的复杂性，应用程序部署确实需要用于工作流连接和服务发现的完整模型。但是，为了实现这样的模型，企业需要一个开发框架。

企业需要在同一页面上使用其所有Kubernetes组件。

如今，PaaS正在为混合云和多云重新定义，因为编程仍然需要一种语言和一组API，这些API可以使应用程序访问硬件、软件和网络资源。API定义了平台、虚拟计算机和操作系统，在这种情况下代表了数据中心和公共云资源的组合。在明确定义新的PaaS模型之前，混合云用户将必须优化不断发展的附加组件集以构建自己的统一模型。

修改后的PaaS模型最直接的缺点是缺乏中间件一致性。企业需要一种标准化的方法来发现服务，将容器绑定到工作流中并监视条件以允许应用程序在负载下进行扩展。

在整个组织中发现依赖于不同工具和实践的不同应用程序并不少见。如果这些应用程序共享服务和微服务，则会增加总体运营成本和复杂性，并最终导致兼容性问题。

使用Kubernetes域集中化混合和多云控制

同步内部部署和基于云计算的资产的优秀方法是将企业的混合云计算基础设施视为一系列Kubernetes“域”——Kubernetes集群，其组件通常会在一个域中进行扩展和重新部署，因此如果要跨多个云平台或在云平台和数据中心之间进行扩展，需要定义一组边界域。这些将包含企业将在公共云和私有云之间边界处使用的资源，用于处理主机扩展或弹性等方面。因此企业需要选择支持这种分离的工具。

在这种新兴的PaaS方法中，企业的运营团队通常面临着自己的挑战。用户在使用Kubernetes进行开发时不必定义特定的资源需求或合规风险，并且操作人员几乎不可能在事后对这些容器进行分类和测试。缺少完整的PaaS层意味着运营团队必须混合其策略控制。

域分离的集群可以开始解决这个问题，而为类似的容器化应用程序定义和实施资源策略更容易。如果企业的域中有具有唯一安全性或遵从性要求的容器，需要标记其节点并使用策略将Pod筛选到正确的节点，或者使用容忍度来强制实施规避策略。

建立一致的Kubernetes生态系统

托管的Kubernetes服务(例如Amazon Elastic Kubernetes Service或Google Kubernetes Engine)是吸引人的工具，可作为移动或Web现代化的一部分为内部部署的应用程序部署云计算前端。尽管这些服务都是围绕Kubernetes构建的，但是每个服务都提供了足够多的元素，因此很难跨平台集成应用程序。这为想要进行更多跨云备份或跨环境扩展的企业带来了问题。

为了解决此混合和多云挑战，需要执行以下步骤：

• 定义应用程序模型。
• 集中Kubernetes生态系统的组装。
• 监视应用程序、基础设施和Kubernetes生态系统的趋势。

企业的开发模型可能从某种程度上针对其环境的API开始，但是目标应该是创建一种跨越混合和多云框架的方法。通过根据应用程序的需求和规范定制流程，可以简化所有其他问题。

从那里集中Kubernetes工具包，以在企业所有域中部署应用程序。这应该包括企业计划使用的整套Kubernetes和与Kubernetes相关的工具。企业可以根据自己的需求，制定一个包含最广泛生态系统形式的Kubernetes的单一策略。