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