本文来自微信公众号“开源云中文社区”。
几年前，大多数技术文章会让你认为Linux容器和虚拟机是数据中心中截然相反的组件。当一项新技术被采用时，这是很自然的：炒作周期可以将这些创新推向行业的每一个角落，寻找战胜旧软件和旧硬件组合。
你可能还记得JavaScript何时将接管服务器端，或者虚拟现实何时将彻底改变教育。事实上，这些技术最终找到了舒适的使用领域，而不是取代其他想法。随着时间的推移，情况会稳定下来，很难判断某项技术最终会在哪里最有用，以及在哪里会被更好的选择所取代。
现在，Linux容器和虚拟机已经成为通用软件开发人员为各种场景考虑的工具。我们想提供一个指南，指导每种技术在当今的混合云环境中何时何地适用。
大还是小？
也许最简单的决策方法是根据应用程序的大小和复杂性。容器是一种应用程序打包技术。容器可以在没有Kubernetes的情况下直接部署到操作系统中，而且通常有非常好和有效的理由来使用它们。容器是一种简单、可复制的部署软件的方式，同时最大限度地减少漂移和移动部件。
还有其他类似和竞争的技术具有许多相同的功能，如unikernel、Wasm等。因此，虽然容器可能是当今部署应用程序的正确方式，但随着该模型的优化和采用新类型的部署模型，未来可能会有一些变化。
简单地说，有些应用程序太大太复杂，无法按原样放入容器中。我们通俗地称它们为单体。需要注意的是，这里没有技术限制：没有CPU/内存阈值，你会越过，最终被取消资格。相反，这是基于投资的价值。例如，一个安装程序将数据库加中间件加$thing1和$thing2等部署到一个服务器上，按原样进行容器化可能很有挑战性。可能需要对应用程序进行“现代化”，以解耦组件和/或采用对容器化更友好的应用程序框架和/或运行时。其中一个例子是将Java应用程序从SpringBoot移动到Quarkus。
对于开发人员
开发人员和管理员，无论他们是否采用了新颖的云原生架构和/或DevSecOps方法，都应该接受容器，原因有很多。应用程序容器化的好处包括速度、安全性、可移植性和简单性。然而，这并不意味着将虚拟机彻底抛弃。
真正的问题是，“我想把容器化应用程序部署到Kubernetes还是直接部署到（虚拟化的）操作系统？”这里有很多因素需要考虑。
一个是应用程序的要求。应用程序是否需要作为一个单独的节点持续运行而不中断？Kubernetes不会在节点之间无中断地迁移应用程序组件。它们被终止并重新启动。如果你的应用程序不能容忍这种行为，那么Kubernetes就不适合了。
考虑应用程序的各种组件的状态也很重要。如果有问题的应用程序依赖于第三方组件，那么这些组件可能会限制容器的使用。许多第三方供应商，尤其是在以虚拟机为中心的行业，在创建Kubernetes就绪/兼容版本的软件方面进展缓慢。这意味着你既可以部署虚拟机，也可以自己承担在Kubernetes中支持其软件的责任。
在评估这些选项之前，认真审视一下组织内部可用的技能也是很重要的。团队是否具备处理Linux容器的技能和能力？是否拥有或愿意为Kubernetes构建和获取必要的专业知识？这扩展到API驱动的消费和配置。应用程序和开发团队是否需要/想要使用API消费和配置平台的能力？
这在所有“私有云”、公共云和Kubernetes中都是可能的，但通常更复杂、更难预处理，需要专业自动化团队的大量粘合。当涉及到公共云时，团队需要在其使用的每个公共云中拥有特定的专业知识，从而增加了另一层需要管理的复杂性。这是一个Kubernetes可以同质化并进一步实现可移植性的领域。
基础设施效率
在许多/大多数情况下，一个拥有数万到数千个实例的“网络规模”应用程序在Kubernetes集群上运行的效率要比在虚拟机中运行的效率高得多。这是因为容器化组件被打包到可用资源中，并且需要管理和维护的操作系统实例更少。
此外，Kubernetes可以更无缝、更轻松地扩展和缩小应用程序。虽然可以创建新的虚拟机来扩展应用程序组件或服务的新实例，但这通常比Kubernetes慢得多，也更难。Kubernetes专注于在应用层实现自动化，而不是在虚拟化层，尽管KubeVirtualt也可以实现自动化。
基础设施效率也意味着成本影响。这对每个组织来说都是不同的，但对一些组织来说，减少虚拟机的数量将影响他们向操作系统供应商、系统管理程序供应商和硬件供应商支付的许可费。然而，这可能会也可能不会被Kubernetes的成本和管理它所需的人才所抵消。
在安全方面还有其他考虑因素。Kubernetes是一个共享的内核模型，其中许多容器表示许多应用程序在同一节点上运行。这并不是说它们不安全——Red Hat OpenShift和部署到Red Hat操作系统的容器利用了SELinux和其他安全功能。
然而，有时这还不足以满足安全需求和合规性需求。这留下了几个进一步隔离的选项：部署许多Kubernetes集群（很多人都这样做）、使用Kata容器等专门技术或使用完整的虚拟机。
无论组织有什么要求，也无论为应用程序选择容器还是虚拟机，在企业软件世界中始终有一条基本规则在发挥作用：变革是困难的。有时，如果某个东西正在工作，就没有理由移动、更新或迁移它。如果应用程序在虚拟机上可靠地运行，并且没有公司推动将其迁移到其他地方，那么只要它能得到可靠的支持，也许它就可以在原地运行。
有时，组织内部变革的最佳场所并不在遗留应用程序的堆栈中，而是在新想法不断增长的绿色领域。但即使是那些绿色的田野也必须以某种方式与旧谷仓相连。
然而，实际使用的技术并不一定会在这些绿色领域中有所建树。这样，找到一种在环境中同时支持容器和虚拟机的方法是很重要的——你可能犯的唯一错误是完全忽略其中一种技术。
