新技术的发展改变着各行业的商业环境，企业纷纷建立数字化转型的战略来适应新的市场。这个战略中一个显著的变化就是信息化部门逐步从支撑角色走到了业务前线，甚至成为体现企业能力差异化的核心竞争力。在这个转变的过程中信息化部门面临新的机遇和挑战，比如，如何通过新的应用提升和改变与最终用户的交互方式，创造出新的业务模式，从而增加营收；如何高效管理飞速增加的应用数量和由此带来的各种安全问题；如何更充分的利用蓬勃发展的各种云计算的创新服务。
在新的市场形式下，企业应用领域也在不断变革。
首先，企业应用的预算分配发生了变化。根据Gartner的分析，在企业数字化转型的过程中应用的类型逐步从记录型应用(system of record)向创新型应用(system of innovation)转变。
应用的进化
传统的SOR型应用相对稳定，一般都有专属的硬件运行环境，Capex占到总体预算的很大比重。所以企业在建设此类应用的时候会专门针对应用进行硬件采购。而新型的SOI应用更加敏捷，整体的生命周期很短，一般活跃期都在一年以内，有些极端的情况可能在线时间也就一两周。此类应用的Capex投入都很少，有些甚至没有Capex的预算。
其次，企业应用的数量发生了变化。随着5G，AI，IOT等技术的成熟，企业应用迎来了场景大爆发。无论是面向最终用户的场景，还是后台分析的场景，亦或是整合上下游产业链的场景，新的技术驱动了更多应用的上线。根据VMware的分析报告，未来五年全球新增的应用数量超过有史以来全部的应用的总和。这种数量级上的激增，导致现有运行环境和运维方式已经很难支撑新增的企业应用了。
与此同时，企业应用的架构也在不断演化。为了更快地将新业务推向市场，同时降低变更的成本，越来越多的新应用采用了微服务的架构方式。通过将一些通用的功能服务化，使得新应用的开发更加关注于业务逻辑的实现上，每个独立服务的变更也会更加敏捷。
应用变革的过程中，传统的IT 基础设施标准和管理方式已经不能满足应用的需求。在和客户的基础设施管理团队沟通中，我们发现基础设施在应用现代化的过程中主要面临以下的几个挑战。
- 基础设施的交付时间过长，拖累了应用的开发、测试和上线的速度。基础设施交付过程中存在大量的手动步骤，无法融入到现代化应用的自动化流程中。
- 基础设施团队和开发团队之间的交付界面过于单一，一般只有虚拟机的形态。开发团队拿到虚拟机后还需复杂的安装配置才能支持应用运行，某些情况下会导致开发团队直接转向自建或者公有云，形成影子IT。而运维团队很难了解应用运行环境的内部情况，无法合理的管理应用的稳定性和安全性。
- 新型工作负载（如Kubernetes）难于融入到现有的平台和管理方式中，如何集中统一管理这些新的技术框架对基础设施的使用。
在应对企业应用变革以及由此带来的基础设施的挑战的过程中，企业用户逐渐意识到一个现代化的应用平台必将成为非常关键的技术支撑。通过平台提供的运行环境，降低新应用的Capex；通过标准的运维工具和流程去支撑数量众多的新应用；通过将更多的通用服务平台化，使得微服务架构的应用能够更加迅速上线。
Kubernetes框架的出现为企业用户的这一思路提供了捷径。Kubernetes通过声明式API和 Reconciliation loop 的机制巧妙的解决了容器在大规模分布式系统的调度问题。它屏蔽了后端分布式系统的复杂性，用户只需要描述应用部署的期望状态和依赖的服务，平台会自动调度和调整资源，从而使应用的部署符合用户的预期。围绕着Kubernetes蓬勃发展的的生态，也为用户提供了广泛的配套工具选择。所以，很多企业用户都选择以Kubernetes为核心建设应用平台。
那么在企业环境中，Kubernetes技术的落地有哪些注意事项和最佳实践呢？
首先，Kubernetes需要基础设施的支持。有一种声音认为Kubernetes已经足够强大，可以代替Hypervisor或者其他基础设施管理软件，把应用层和基础设施层统一管理。真的是这样吗？在官网的Kubernetes项目规范中 What is Kubernetes? 可以看出，底层物理或者云资源（计算、网络、存储）的管理、集群和节点的生命周期管理、甚至是外部的负载均衡等功能都不在Kubernetes的设计范围内。Kubernetes通过标准的CNI来对接外部的网络控制器，通过标准的CSI来对接外部的存储控制器，通过 Cloud Provider 的扩展机制，让底层的资源管理方提供扩展能力（比如节点AZ的概念、自动配置负载均衡器等），使Kubernetes更好的与特定的云平台配合使用。
以上这些说明，在Kubernetes出现的时候，它并不是要取代Hypervisor或者公有云平台，而是假设这些技术已经存在，并且已经完美地解决了基础设施管理问题，当Kubernetes需要基础设施类资源的时候它可以直接去调用底层平台的API，因此Kubernetes是作为一种补充技术出现，而不是一个替代技术。这也是Kubernetes生态能够成功的原因之一，因为它在云平台的概念之上解决了另一个层面的问题，而不是尝试去替代。
Kubernetes需要基础设施的支撑
所以，无论是在公有云还是私有云运行Kubernetes，底层至少有一个能够管理物理或者云资源，并且对接Kubernetes的Cloud Provider。在企业环境中，这个Cloud Provider必须能够满足企业级的需求，比如说稳定性、成熟的网络存储服务、经过检验的运维方案、完善的硬件生态系统等。虽然Kubernetes也可以直接运行在物理机上，但是很多工作需要手动完成，比如搭建配置存储服务、对节点打标签、分配AZ、手动建立负载均衡等操作。对于企业用户来说用这种方式维护大规模的环境很困难，这种投入性价比并不高。更合理的方式是提供一个Kubernetes ready的基础设施管理平台，配合Kubernetes供给各种底层的资源。
其次，Kubernetes需要和现有的技术栈融合，同时支持传统应用和新应用。和大多数互联网公司不同，企业客户的应用现代化和容器化过程是渐进的，不会一步到位。现阶段企业环境中的现代化应用比例还比较低，在未来一段时间内传统应用和容器化的新应用会在企业中共存。所以基础设施不仅要满足现代化应用的需求，同时更重要的是维护现有应用的稳定运行。如果在现有的技术栈之外建立一个独立的Kubernetes环境，企业内部会出现多个孤岛系统，不同的技术栈、不同的人员技能、不同的运维流程，这些都会给企业IT增加新的工作量和风险，更何况这样的平台只能称为“现代化应用”的平台，因为它只能支持新型的应用，而无法将传统应用纳入一致的管理体系。
异构的技术栈
Kubernetes的声明式API在应用领域已经得到了广泛的使用，并且获得很好的效果，在开发者群体里很受欢迎。但是声明式API目前只能支持容器，应用以其他形态部署或者希望申请其他类型的基础设施（存储、安全策略等）的时候，仍然需要命令式的API或者手工的方式进行。举例来说，如果一个应用中即包含虚拟机又有容器，用户无法使用声明式API统一管理这些组件，从而无法获得一致性的开发和运维体验。如果能将声明式API引入基础设施领域，将它变成一个标准的交互方式，既可以提供容器也可以提供虚拟机的支持，开发人员就可以使用熟悉的Kubernetes API或者命令行自服务的驱动基础设施的资源。这种方式加快了基础设施向应用的供给效率，也可以被CICD的流水线更好的调用。
融合的技术栈
然后，Kubernetes平台的建设需要考虑一个可以扩展的服务目录，而不仅仅是容器运行环境，能够以声明式的API提供丰富的开源或者商业的服务给开发团队。很多开发人员喜欢使用公有云，因为公有云资源的申请简单、快速，随时可以获得虚拟机、数据库、大数据集群，甚至Kubernetes集群，更重要的是公有云不需要运维，开发人员不需要担心资源不够开不出虚拟机，或者数据库的磁盘满了不能服务等情况。Kubernetes Operator 的出现可能会改变开发人员对于私有云的印象。Operator是一个开源的、标准化的创建、配置和管理应用的框架。它可以将软件和它的运维的最佳实践打包到一起，同时部署在用户环境中。在安装软件的同时，也将运维的领域经验标准化的交付给客户。Operator是基于Kubernetes API扩展出来的，当平台的Kubernetes API可以支持容器和虚拟机的时候，Operator自然也可以支持应用以容器和虚拟机的形式部署。开发人员就可以选择以容器或者虚拟机的方式去运行应用所依赖的服务，比如mysql 集群。有了Operator的支持，运维团队可以标准化的形式引入开源或者商业的软件，开发人员通过Kubernetes API自服务的使用这些服务。从而基础设施团队和开发团队之间的交付界面会变的更加丰富和自动化。
Kubernetes API使用如此广泛，以至于未来Kubernetes管理的容器集群可能不存在了，但是Kubernetes的API会成为基础设施和云的主要消费方式，这个趋势会极大增强Kubernetes的影响力。目前AWS 、VMware和谷歌等一些公司都在这个方向进行尝试，陆续推出了相关的服务。
最后，统一管理众多的运行在不同环境的租户集群。随着容器化的新应用的增加，运维团队会收到来自不同业务部门提出的对Kubernetes集群的需求。按照Kubernetes使用的最佳实践，在企业环境中可以分配多个运行在不同环境中的集群给租户，这样不仅可以提供更好的租户隔离，满足租户对于Kubernetes集群规格的不同需求（比如运行环境、版本、GPU的支持、Windows的支持），同时可以降低Kubernetes集群的运维难度。但是企业内部的Kubernetes集群也会越来越多，运行在不同的云环境。如何管理这些Kubernetes集群的生命周期（创建、回收、升级补丁、扩缩容），如何进行统一的权限、策略以及运维管理，这些问题都是Kubernetes在企业落地需要解决的问题。
跨云的多集群管理
数字化转型过程中应用的转型带来了对基础设施的挑战，企业用户逐步开始建设基于Kubernetes的平台来应对，而Kubernetes在企业环境中的落地还有很多亟待解决的问题。VMware是如何看待这些问题，可以提供什么样的解决方案呢？ 3月11号VMware全球发布会带来全新的应用和基础设施现代化的战略和更多的产品细节，敬请关注VMware官微的最新消息。
