一文解读2019年容器基础设施最新趋势与进展
Kubernetes的崛起令人惊叹。在短短几年时间内，它已经从一个由一群云原生开发者倡导的开源项目转变为由云服务提供商推广的标准运维平台。
由于应用程序工作负载从VM转移到容器，Kubernetes已成为自动化和扩展容器部署的流行选择。但是，到目前为止，Kubernetes的开发主要集中在基础设施内部，而不是关于简化应用程序开发和部署的更广泛问题。幸运的是，这种孤立性正在逐渐消退，因为几个PaaS堆栈正在将Kubernetes集群添加为支持的运行时目标，比如Pivotal Cloud Foundry，该公司将Cloud Foundry与Kubernetes集成的举措代表着将容器编排平台演变为企业友好环境的大趋势。
正如我们之前所讨论的，企业通过采用PaaS堆栈和开发方法来利用软件抽象的力量，这有着令人信服的业务和技术原因。Cloud Foundry因为产品上市早，和基于技术优势所提供的满足开发人员和IT专业人员需求的完整系统而成为最受欢迎的选择。Cloud Foundry长期以来一直使用容器作为应用程序运行时环境，但作为一个自包含的系统，容器由名为Garden的内部模块管理。商业Pivotal Cloud Foundry版本的用户很快将有另一种选择——Kubernetes，并且有一系列增强功能——这些增强功能解决了阻碍企业采用Kubernetes的缺点。
Pivotal拥抱Kubernetes、服务网格
Pivotal通过提供集成的、受支持的软件和服务，使Cloud Foundry成为企业PaaS。在最近的OSCON开发者大会上，该公司承认了Kubernetes作为容器管理系统的蓬勃发展，宣布其核心产品Pivotal Application Service的有限预览版本在Kubernetes上运行。
“PAS on Kubernetes旨在将PAS的开发经验带到Kubernetes之上。alpha版本是概念验证，支持PAS最重要的功能，例如`cf push`用于许多基于buildpack的应用程序，同时在Kubernetes上运行PAS app实例。下图总结了alpha版本中的内容。”
Pivotal还实现了以下功能：
- Cloud Foundry应用程序实例运行Kubernetes pod，其中包含一个translator，可将PAS应用程序转换为OCI(Open Container Initiative)镜像和Kubernetes pod配置。然后，Kubernetes控制器管理应用程序的部署和扩展。
- 与PAS HTTP路由器集成，将客户端请求的流量定向到Kubernetes上运行的应用程序。
- 应用程序和pod日志与PAS日志记录系统(Loggregator)的集成。
- 最多支持50个应用程序实例。
alpha版本需要vSphere、NSX-T和Pivotal企业容器服务PKS，但该公司计划支持其他Kubernetes平台，特别是AWS、Azure和Google Cloud Kubernetes服务。
在过去几个月里，Pivotal还推出了其他几款Kubernetes产品，包括基于开源Buildpacks项目创建容器镜像的构建服务、对Spring Java Runtime环境和Kubernetes上RabbitMQ软件的支持以及基于Istio和Envoy(自动化客户端访问在Kubernetes集群上运行的应用程序)的容器服务网格。这些都显著增强了Kubernetes作为生产应用平台的实用性和可用性。此外，作为商业支持的产品，它们不需要安装、调整和调试开源软件所需的专业人士和专业知识。
IBM引领云原生应用程序开发
IBM还忙于为企业开发人员提供Kubernetes增强功能，宣布了几个旨在加速和简化容器化应用程序开发的开源项目。虽然尚未打包为商业软件，但以下项目将特别吸引刚接触云原生应用程序设计的开发人员：
Kabanero是容器化应用程序的体系结构和开发框架。它使用Kubernetes进行工作负载管理，满足架构师、Java开发人员和DevOps交付团队的需求。它建立在其他三个与Kubernetes相关的项目上：Knative(开发过程自动化和无服务器端点)、Istio(服务网格)和Tekton(CI / CD集成)。通过开发运行时和框架(Node.js、Java、Swift)，Kabanero将配置Kubernetes集群、安全性和网络的实践封装到预构建部署中。它还包含几个新项目，包括：
- Appsody通过捆绑多个流行编程环境的预配置开发框架和模板，简化了应用程序开发。
- Codewind是一个开源开发项目管理器，它为流行的IDE(包括Eclipse和Visual Studio)添加了容器支持。
- Razee是一个持续交付工具，支持针对Kubernetes部署的容器化微服务，其中包括可视化配置信息和部署的图形界面，以帮助进行故障排除。它通过内置模板简化了多集群部署，这些模板跨集群和云环境实施配置和安全策略。
来看看IBM的声明，“没有任何其他开源项目能够通过整个Kubernetes生产生命周期创建容器化云原生应用程序提供集成体验。”“通过使用Kabanero，你的开发团队能够构建可以部署到Kubernetes上的应用程序，而无需先成为容器和Kubernetes的专家。这降低了开发人员在企业从遗留基础设施转移到更现代化的基础设施的云化过程中的进入门槛。”
容器的强有力采用与警示性挑战并存
Pivotal(还有戴尔和VMware)和IBM(以及红帽)都意识到，企业开发人员和IT组织将容器视为比他们当前使用的VM服务器更高效、更灵活和更可扩展的应用程序环境。但是，企业用户仍然在努力应对不成熟的技术、挑战性的安全配置、陡峭的学习曲线以及无法轻松集成到其他系统中的复杂基础设施。
事实上，Diamanti最近的一项调查表明，容器的使用越来越多，而企业采用者面临着持续的挑战。容器已进入主流，调查发现IT和平台架构师负责大部分容器决策，而今年在容器技术上花费至少10万美元的组织增加了5.5个百分点，达到38.5%。此外，在容器上至少花费100000美元的组织中，有26%计划将大部分工作负载量转移到容器上。
企业努力应对的一个领域是找到足够的容器专业知识来实现其目标。那些认为缺乏容器技能的人才是“主要采用抑制因素”的人今年增加了一半，几乎占调查对象的四分之一。而认为没有影响的受访者是指只对花费最少的容器技术(少于50000美元)计划没有影响，即刚开始或测试最小容器安装的那些。实际上，近65%的人认为技能短缺是中度或主要的采用抑制因素。
至于在生产中运行容器，多年来什么是主要的挑战非常一致：与现有基础设施的集成、安全性和部署复杂性。这些抑制因素是Diamanti、PAS、Red Hat OpenShift等打包容器平台在企业IT和DevOps组织中如此受欢迎的关键原因。
笔者的看法
在一大堆服务器配置、网络管道和编程语法的神秘细节中，关于Kubernetes的讨论似乎无可救药地偏题了，这让业务和IT主管们质疑该技术如何满足他们对新应用程序的需求和实现更快的上市时间。对于这些非专业人士来说，他们并不多关心设计细节。相反，应用程序所有者、赞助商和业务主管希望了解Kubernetes如何为他们节省资金，提高应用程序性能并缩短开发时间。而通过专注于应用程序开发过程而不是交付系统，可以更好地实现这些目标。