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