2019年指南：关于虚机与Kubernetes，我们应当思考些什么？

在2019年的Kubernetes社区的一份 指南 的纲要中，酝酿出了 关于Kubernetes和虚拟机的回归 的话题。虚拟机并没有取代容器，相反，虚拟机的使用正在跨Kubernetes堆栈的多个层发展。

近年来，容器已成为云原生应用程序架构的同义词。它们重新定义了我们打包，分发，部署和管理应用程序的方式。但是正如我们今天所知，容器本身就是现有 Linux 技术的再现，它们以一种新的，更有用的方式结合在一起。虽然许多组织正在将基于虚拟机的应用程序迁移到容器，但虚拟化在数据中心和公有云中仍普遍存在。我们还看到虚拟化技术以新的方式与容器和Kubernetes结合在一起，为新的问题集提供了创新的解决方案。换句话说，虚拟机也正在成为云原生架构的一部分，这就是容器原生虚拟化。

Kubernetes的基石仍然是作为Linux容器的编排和管理，以创建一个功能强大的分布式系统，用于跨混合云环境部署应用程序。Kubernetes通常运行在基于虚拟机的基础架构之上，而基于虚拟机的工作负载通常仍然是IT组合的重要组成部分。进入2019年，Kubernetes和虚拟化的交叉点有三个我们期待看到的主要趋势，下面将进一步研究：

1. Kubernetes编排微虚机，为非受信任工作负载提供更严格的多租户隔离。
2. Kubernetes编排和管理传统的基于虚拟机的工作负载（通过KubeVirt）以及基于容器的工作负载。
3. Kubernetes集群越来越多地部署在裸机服务器上，作为基于虚拟机环境的Kubernetes的替代品。

这些本身都不是新想法了，但在2019年我们期望看到这些趋势背后的势头成为现实。隔离使用的每项功能都能独立使用，但它们共同说明了Kubernetes如何继续发展并应用于过去，现在和将来更广泛的应用程序。

Kubernetes编排微虚机

采用Kubernetes和容器时的核心考虑因素之一是安全性以及如何确保容器在多租户环境中安全运行。容器在共享Linux主机上作为独立进程运行，并且你经常将多个容器化应用程序运行在由多个主机组成的Kubernetes集群中。从Linux主机级别到Kubernetes集群级别有多个容器安全性层级，可以保护应用程序不被侵占利用。其中包括Linux内核级功能，如cGroups，namespaces，seccomp和SELinux，它们确保容器无法利用底层Linux主机或其他容器。在Kubernetes集群级别，基于角色的访问控制（RBAC）等功能，命名空间租户隔离和pod安全策略使多个应用程序可以在同一个集群上安全地运行。如今，大多数用户对这些功能提供的安全性充满信心，因此，我们看到在关键型生产环境中运行Kubernetes的客户数量呈爆炸性增长。

对于某些用户而言，由于运行不受信任的工作负载，需要有更严格的安全要求或其他原因，他们可能需要更强大的多租户隔离。所以基于微虚机的方法，如 Kata Containers ， Firecracker 或 gVisor 开始崭露头角。微虚机与在VMWare，AWS或其他提供商上运行的传统虚拟机不同。相反，他们在应用程序容器的上下文中重新混合现有的硬件辅助虚拟化技术，如基于内核的虚拟机（KVM），以提供非常轻量级的虚拟机。这种方法不是像传统虚拟化那样尝试提供完整的“机器”，而是专注于提供足够的最小需求的虚拟机来成功执行应用程序容器或功能。因此，由于其功能差异和限制，你不能将传统虚拟机放到基于微虚机的容器中运行它。相反，微虚机旨在提供相对于标准Linux容器的硬隔离，同时最大限度地减少传统虚机在冷启动时间和性能方面的权衡。

虽然Firecracker，Kata和gVisor等技术引起了很多关注，但目前在用户采用方面还没有明确的领导者，每种方法都有其固有的权衡取舍。虽然我们预计Kubernetes编排的绝大部分工作负载仍将是标准的应用程序容器，但随着微虚机在2019年的不断发展，我们将持续关注这一趋势。

Kubernetes编排标准虚拟机

Kubernetes编排引擎为企业生产工作负载提供了更具可扩展性和灵活性的模型。起初，这本来有一个潜台词，生产工作负载将打包为应用程序容器。但是通过像 KubeVirt 这样的开源项目，我们看到同样强大的Kubernetes编排引擎也可以应用于管理通常在云或虚拟化平台上运行的标准虚拟机。

在2019年，我们预计这种趋势将持续下去并将会有更广泛的思维模式转变。以前在以虚拟机为中心和以容器为中心的基础设施之间的选择将没有实际意义。Kubernetes将开始为容器和虚拟机启用混合操作，甚至将可以在裸机环境中运行。

容器原生虚拟化这概念使虚拟机能够遵循与Kubernetes中基于容器的应用程序相同的工作流程。以前，虚拟化堆栈是与Kubernetes和云原生实现完全独立的孤岛，独立的工作流程，独立的工具，独立的团队等。但随着数字化转型的实施，统一这些不同的技术，流程和团队的需求变得至关重要。在使用KubeVirt进行容器原生虚拟化时，企业将能够更有效地集成其应用程序操作并保留现有的IT技能，同时拥抱基于Kubernetes构建的现代基础架构。

无需虚拟机，裸机上的Kubernetes

虽然虚拟机成为Kubernetes工作负载的重要组成部分，但我们也发现作为Kubernetes底层基础架构的一部分它们开始变得不那么流行了。虽然目前大多数Kubernetes平台都部署在基于虚机的基础架构上，但容器不依赖于虚机来运行。我们看到在裸机上运行Kubernetes和容器的关注与呼声持续增长。

在裸机上运行Kubernetes将使应用程序能够充分利用底层硬件，这很重要，客户能将更多机器以及性能敏感的应用程序带到Kubernetes上。在裸机上运行Kubernetes和容器还可以帮助组织减少虚机随意扩展并简化其操作。

为了避免锁定任何一个提供商或供应商，用户将重点放在Kubernetes上，它作为跨物理，虚拟，私有云和公共云环境运行的应用程序的通用抽象层。我们需要满足用户的需求。这意味着在开放的混合云中提供Kubernetes，包括本地和裸机上。

展望未来

虽然Kubernetes已经存在了好几年，但随着下一个时代的到来，创新仍在继续加速。作为最初项目启动的一部分，Red Hat于2014年首次参与Kubernetes，自2015年6月推出3.0版（基于Kubernetes 1.0）以来， 红帽OpenShift容器平台 一直提供企业Kubernetes 。随着我们在2019年的关注，我们发现这些趋势在社区生态系统和企业客户中发挥着重要作用。

原文链接： Guide for 2019: What to Consider About VMs and Kubernetes （翻译：fengxsong）