51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）

作者 | 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/