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

作者 | Heather Joslyn & Lawrence E Hecht

策劃  | 云昭

幾年前，不少技術(shù)文章都會輸出這樣一種觀點：Linux容器和虛擬機是數(shù)據(jù)中心中兩個截然相反的組件。誠然，尤其當一項新技術(shù)被采用時，這種現(xiàn)象就會很明顯：在新技術(shù)的炒作周期中，新事物往往會被推向行業(yè)的每一個角落，并且尋找戰(zhàn)勝舊軟件、硬件組合的新的宣傳點。

你可能還記得JavaScript何時將接管服務(wù)器端，或者虛擬現(xiàn)實何時將徹底改變教育。事實上，這些技術(shù)最終只是找到了“舒適的”使用領(lǐng)域，而不是取代其他。然而，事實上，很難判斷某項技術(shù)最終會在哪里最有用，以及在哪里會被更好的選擇所取代。

現(xiàn)在，Linux容器和虛擬機不再是全新的，它們已經(jīng)成為通用軟件開發(fā)人員為各種場景考慮的工具。現(xiàn)在，我們想提供一個指南，指導(dǎo)每種技術(shù)在當今的混合云環(huán)境中何時何地適用。

1、容器？太大的用不了！

也許，最簡單的決策方法是根據(jù)應(yīng)用程序的大小和復(fù)雜性。容器是一種應(yīng)用程序打包技術(shù)。容器可以在沒有Kubernetes的情況下直接部署到操作系統(tǒng)中，而且通常有非常好和有效的理由來使用它們。這也是我們與Red Hat Enterprise Linux和Ansible的優(yōu)勢戰(zhàn)略的一部分：容器是一種簡單、可復(fù)制的部署軟件的方式，同時最大限度地減少遷移部件。

不少其他類似的或是競對的技術(shù)，具有許多相同的功能，如unikernel、Wasm等。因此，雖然容器可能是當今部署應(yīng)用程序的正確方式，但隨著該模型的優(yōu)化和采用新類型的部署模型，未來可能會有一些變化。

簡單地說，有些應(yīng)用程序太大、太復(fù)雜，無法按原樣放入容器中。我們通俗地稱它們?yōu)閱误w。需要注意的是，這里沒有技術(shù)限制：沒有CPU/內(nèi)存閾值，你會放棄容器。相反，這是基于代價的考量。

例如，一個安裝程序?qū)?shù)據(jù)庫加中間件加$thing1和$thing2等部署到一個服務(wù)器上，按原樣進行容器化可能會很困難。可能需要對應(yīng)用程序進行“現(xiàn)代化”，以解耦組件和/或采用對容器化更友好的應(yīng)用程序框架和/或運行時。其中一個例子是將Java應(yīng)用程序從SpringBoot移動到Quarkus。

2、不是所有的容器都要上K8s

開發(fā)者和管理者，無論他們是否采用了新興起的云原生架構(gòu)或DevSecOps方法，相信都會采納容器，原因有很多。應(yīng)用程序容器化的好處包括速度、安全性、可移植性和簡單性。然而，這并不意味著將虛擬機徹底拋棄。

真正的問題在于，“我想把容器化應(yīng)用程序部署到Kubernetes，還是直接部署到（虛擬化的）操作系統(tǒng)？”這里有很多因素需要考慮。

首先需要注意是應(yīng)用程序的要求。應(yīng)用程序是否需要作為一個單獨的節(jié)點持續(xù)運行而不中斷？Kubernetes不會在節(jié)點之間無中斷地遷移應(yīng)用程序組件。它們被終止并重新啟動。如果你的應(yīng)用程序不能容忍這種行為，那么Kubernetes就不適合了。

其次，考慮應(yīng)用程序的各種組件的狀態(tài)也很重要。如果有問題的應(yīng)用程序依賴于第三方組件，那么這些組件可能會限制容器的使用。許多第三方供應(yīng)商，尤其是在以虛擬機為中心的行業(yè)，在創(chuàng)建Kubernetes就緒/兼容版本的軟件方面進展緩慢。這意味著你既可以部署虛擬機，也可以自己承擔在Kubernetes中支持其軟件的責任。

甚至在評估這些選項之前，認真審視一下組織內(nèi)部可用的技能也是很重要的。你的團隊是否具備處理Linux容器的技能和能力？你是否擁有或愿意為Kubernetes構(gòu)建和獲取必要的專業(yè)知識？這擴展到API驅(qū)動的消費和配置。你的應(yīng)用程序和開發(fā)團隊是否需要/想要使用API消費和配置平臺的能力？

這在不管是私有云，還是公共云和Kubernetes中都是可能的，但通常更復(fù)雜、更難預(yù)處理，需要專業(yè)自動化團隊的大量協(xié)作。當涉及到公共云時，團隊需要在其使用的每個公共云中擁有特定的專業(yè)知識，從而增加了另一層需要管理的復(fù)雜性。這是一個Kubernetes可以同質(zhì)化并進一步實現(xiàn)可移植性的領(lǐng)域。

3、基礎(chǔ)設(shè)施效率

在大多數(shù)情況下，一個擁有數(shù)萬到數(shù)千個實例的規(guī)模的應(yīng)用程序在Kubernetes集群上運行的效率要比在虛擬機中運行的效率高得多。這是因為容器化組件被打包到可用資源中，并且需要管理和維護的操作系統(tǒng)實例更少。

此外，Kubernetes可以更無縫、更輕松地擴展和縮小應(yīng)用程序。雖然可以創(chuàng)建新的虛擬機來擴展應(yīng)用程序組件或服務(wù)的新實例，但這通常比Kubernetes慢得多，也更難。Kubernetes專注于在應(yīng)用層實現(xiàn)自動化，而不是在虛擬化層，盡管KubeVirtualt也可以實現(xiàn)自動化。

基礎(chǔ)設(shè)施效率也意味著成本影響。這對每個組織來說都是不同的，但對一些組織來說，減少虛擬機的數(shù)量將影響他們向操作系統(tǒng)供應(yīng)商、系統(tǒng)管理程序供應(yīng)商和硬件供應(yīng)商支付的許可費。然而，這可能會也可能不會被Kubernetes的成本和管理它所需的人才所抵消。

在安全方面還有其他考慮因素。Kubernetes是一個共享的內(nèi)核模型，其中許多容器表示許多應(yīng)用程序在同一節(jié)點上運行。這并不是說它們不安全——Red Hat OpenShift和部署到Red Hat操作系統(tǒng)的容器利用了SELinux和其他安全功能。

然而，有時這還不足以滿足安全需求和合規(guī)性需求。這留下了幾個進一步隔離的選項：部署許多Kubernetes集群（很多人都這樣做）、使用Kata容器等專門技術(shù)或使用完整的虛擬機。

4、寫在最后：別輕易更改

無論你的組織有什么要求，也不管你為應(yīng)用程序選擇容器還是虛擬機，在企業(yè)軟件世界中始終有一條基本規(guī)則在發(fā)揮作用：變革是困難的。有時，如果某個東西正在運行，就沒有理由移動、更新或遷移它。如果你的應(yīng)用程序在虛擬機上可靠地運行，并且公司沒有推動將其遷移到其他地方，那么只要它能得到可靠的支持，也許它就可以在原地運行。

有時，組織內(nèi)部變革的最佳場所并不在遺留應(yīng)用程序的堆棧中，而是在新想法不斷增長的綠地之中。但即使是那些綠色的田野，也必須以某種方式與舊谷倉相連。

然而，實際使用的技術(shù)并不一定會在這些綠地中有所建樹。這樣，找到一種在環(huán)境中同時支持容器和虛擬機的方法是很重要的，因為你可能犯的唯一真正錯誤是：完全忽略其中一種技術(shù)。

原文鏈接：https://thenewstack.io/container-or-vm-how-to-choose-the-right-option-in-2023/