本文來自微信公眾號“開源云中文社區(qū)”。
幾年前，大多數技術文章會讓你認為Linux容器和虛擬機是數據中心中截然相反的組件。當一項新技術被采用時，這是很自然的：炒作周期可以將這些創(chuàng)新推向行業(yè)的每一個角落，尋找戰(zhàn)勝舊軟件和舊硬件組合。
你可能還記得JavaScript何時將接管服務器端，或者虛擬現實何時將徹底改變教育。事實上，這些技術最終找到了舒適的使用領域，而不是取代其他想法。隨著時間的推移，情況會穩(wěn)定下來，很難判斷某項技術最終會在哪里最有用，以及在哪里會被更好的選擇所取代。
現在，Linux容器和虛擬機已經成為通用軟件開發(fā)人員為各種場景考慮的工具。我們想提供一個指南，指導每種技術在當今的混合云環(huán)境中何時何地適用。
大還是??？
也許最簡單的決策方法是根據應用程序的大小和復雜性。容器是一種應用程序打包技術。容器可以在沒有Kubernetes的情況下直接部署到操作系統(tǒng)中，而且通常有非常好和有效的理由來使用它們。容器是一種簡單、可復制的部署軟件的方式，同時最大限度地減少漂移和移動部件。
還有其他類似和競爭的技術具有許多相同的功能，如unikernel、Wasm等。因此，雖然容器可能是當今部署應用程序的正確方式，但隨著該模型的優(yōu)化和采用新類型的部署模型，未來可能會有一些變化。
簡單地說，有些應用程序太大太復雜，無法按原樣放入容器中。我們通俗地稱它們?yōu)閱误w。需要注意的是，這里沒有技術限制：沒有CPU/內存閾值，你會越過，最終被取消資格。相反，這是基于投資的價值。例如，一個安裝程序將數據庫加中間件加$thing1和$thing2等部署到一個服務器上，按原樣進行容器化可能很有挑戰(zhàn)性。可能需要對應用程序進行“現代化”，以解耦組件和/或采用對容器化更友好的應用程序框架和/或運行時。其中一個例子是將Java應用程序從SpringBoot移動到Quarkus。
對于開發(fā)人員
開發(fā)人員和管理員，無論他們是否采用了新穎的云原生架構和/或DevSecOps方法，都應該接受容器，原因有很多。應用程序容器化的好處包括速度、安全性、可移植性和簡單性。然而，這并不意味著將虛擬機徹底拋棄。
真正的問題是，“我想把容器化應用程序部署到Kubernetes還是直接部署到（虛擬化的）操作系統(tǒng)？”這里有很多因素需要考慮。
一個是應用程序的要求。應用程序是否需要作為一個單獨的節(jié)點持續(xù)運行而不中斷？Kubernetes不會在節(jié)點之間無中斷地遷移應用程序組件。它們被終止并重新啟動。如果你的應用程序不能容忍這種行為，那么Kubernetes就不適合了。
考慮應用程序的各種組件的狀態(tài)也很重要。如果有問題的應用程序依賴于第三方組件，那么這些組件可能會限制容器的使用。許多第三方供應商，尤其是在以虛擬機為中心的行業(yè)，在創(chuàng)建Kubernetes就緒/兼容版本的軟件方面進展緩慢。這意味著你既可以部署虛擬機，也可以自己承擔在Kubernetes中支持其軟件的責任。
在評估這些選項之前，認真審視一下組織內部可用的技能也是很重要的。團隊是否具備處理Linux容器的技能和能力？是否擁有或愿意為Kubernetes構建和獲取必要的專業(yè)知識？這擴展到API驅動的消費和配置。應用程序和開發(fā)團隊是否需要/想要使用API消費和配置平臺的能力？
這在所有“私有云”、公共云和Kubernetes中都是可能的，但通常更復雜、更難預處理，需要專業(yè)自動化團隊的大量粘合。當涉及到公共云時，團隊需要在其使用的每個公共云中擁有特定的專業(yè)知識，從而增加了另一層需要管理的復雜性。這是一個Kubernetes可以同質化并進一步實現可移植性的領域。
基礎設施效率
在許多/大多數情況下，一個擁有數萬到數千個實例的“網絡規(guī)模”應用程序在Kubernetes集群上運行的效率要比在虛擬機中運行的效率高得多。這是因為容器化組件被打包到可用資源中，并且需要管理和維護的操作系統(tǒng)實例更少。
此外，Kubernetes可以更無縫、更輕松地擴展和縮小應用程序。雖然可以創(chuàng)建新的虛擬機來擴展應用程序組件或服務的新實例，但這通常比Kubernetes慢得多，也更難。Kubernetes專注于在應用層實現自動化，而不是在虛擬化層，盡管KubeVirtualt也可以實現自動化。
基礎設施效率也意味著成本影響。這對每個組織來說都是不同的，但對一些組織來說，減少虛擬機的數量將影響他們向操作系統(tǒng)供應商、系統(tǒng)管理程序供應商和硬件供應商支付的許可費。然而，這可能會也可能不會被Kubernetes的成本和管理它所需的人才所抵消。
在安全方面還有其他考慮因素。Kubernetes是一個共享的內核模型，其中許多容器表示許多應用程序在同一節(jié)點上運行。這并不是說它們不安全——Red Hat OpenShift和部署到Red Hat操作系統(tǒng)的容器利用了SELinux和其他安全功能。
然而，有時這還不足以滿足安全需求和合規(guī)性需求。這留下了幾個進一步隔離的選項：部署許多Kubernetes集群（很多人都這樣做）、使用Kata容器等專門技術或使用完整的虛擬機。
無論組織有什么要求，也無論為應用程序選擇容器還是虛擬機，在企業(yè)軟件世界中始終有一條基本規(guī)則在發(fā)揮作用：變革是困難的。有時，如果某個東西正在工作，就沒有理由移動、更新或遷移它。如果應用程序在虛擬機上可靠地運行，并且沒有公司推動將其遷移到其他地方，那么只要它能得到可靠的支持，也許它就可以在原地運行。
有時，組織內部變革的最佳場所并不在遺留應用程序的堆棧中，而是在新想法不斷增長的綠色領域。但即使是那些綠色的田野也必須以某種方式與舊谷倉相連。
然而，實際使用的技術并不一定會在這些綠色領域中有所建樹。這樣，找到一種在環(huán)境中同時支持容器和虛擬機的方法是很重要的——你可能犯的唯一錯誤是完全忽略其中一種技術。
