Kubernetes是什么?

在過去的幾年中，Kubernetes一直是DevOps和Data Science社區(qū)中令人興奮的話題。 它已經(jīng)連續(xù)發(fā)展成為開發(fā)云原生應(yīng)用程序的首選平臺之一。 由Google作為開放源代碼平臺構(gòu)建的Kubernetes可以處理將容器調(diào)度到計(jì)算集群上的工作，并管理工作負(fù)載以確保它們按預(yù)期運(yùn)行。

[[334687]]

但是，有一個(gè)陷阱：這意味著什么? 當(dāng)然，有可能對Kubernetes進(jìn)行其他研究，但是假設(shè)大多數(shù)讀者已經(jīng)對技術(shù)基礎(chǔ)有所了解，那么Internet上的許多文章都是用專業(yè)術(shù)語和復(fù)雜術(shù)語充斥的高級概述。

在這篇文章中，我們試圖提供對Kubernetes架構(gòu)及其在大數(shù)據(jù)中的應(yīng)用的易于理解的解釋，同時(shí)澄清繁瑣的術(shù)語。 但是，我們假設(shè)我們的讀者已經(jīng)對應(yīng)用程序開發(fā)和編程領(lǐng)域有所了解。 我們希望到本文結(jié)尾時(shí)，您已經(jīng)對該主題有了更深入的了解，并準(zhǔn)備進(jìn)行更深入的研究。

什么是微服務(wù)?

為了了解Kubernetes的工作原理以及我們?yōu)槭裁葱枰?，我們需要研究微服?wù)。 對于微服務(wù)，尚無公認(rèn)的定義，但簡單地說，微服務(wù)是較小的，是執(zhí)行特定任務(wù)的較大應(yīng)用的分離組件。 這些組件通過REST API相互通信。 這種架構(gòu)使應(yīng)用程序可擴(kuò)展和可維護(hù)。 這也使開發(fā)團(tuán)隊(duì)的工作效率更高，因?yàn)槊總€(gè)團(tuán)隊(duì)都可以專注于自己的組件，而不會(huì)干擾應(yīng)用程序的其他部分。

由于每個(gè)組件或多或少地獨(dú)立于應(yīng)用程序的其他部分運(yùn)行，因此有必要擁有可以管理和集成所有這些組件的基礎(chǔ)架構(gòu)。 該基礎(chǔ)結(jié)構(gòu)將需要保證在生產(chǎn)中部署時(shí)所有組件都能正常工作。

容器與虛擬機(jī)(VM)

每個(gè)微服務(wù)都有其依賴性，并且需要其自己的環(huán)境或虛擬機(jī)(VM)來承載它們。 您可以將VM視為計(jì)算機(jī)中的一個(gè)"巨型"進(jìn)程，它的存儲(chǔ)量，進(jìn)程和網(wǎng)絡(luò)功能與計(jì)算機(jī)分開。 換句話說，VM是物理硬件之上的軟件加硬件抽象層，用于模擬完整的操作系統(tǒng)。

可以想象，虛擬機(jī)是一個(gè)消耗資源的過程，耗盡了計(jì)算機(jī)的CPU，內(nèi)存和存儲(chǔ)空間。 如果您的組件很小(很常見)，那么您的VM中會(huì)剩下大量未充分利用的資源。 這使得托管在VM上的大多數(shù)基于微服務(wù)的應(yīng)用程序維護(hù)起來既費(fèi)時(shí)又費(fèi)錢。

容器，就像現(xiàn)實(shí)生活中的容器一樣，將東西容納在里面。 容器打包了運(yùn)行微服務(wù)所需的代碼，系統(tǒng)庫和設(shè)置，從而使開發(fā)人員更容易知道他們的應(yīng)用程序?qū)⑦\(yùn)行，無論其部署在何處。 大多數(shù)可用于生產(chǎn)環(huán)境的應(yīng)用程序由多個(gè)容器組成，每個(gè)容器運(yùn)行應(yīng)用程序的單獨(dú)部分，同時(shí)共享操作系統(tǒng)(OS)內(nèi)核。 與VM不同，容器僅需最少的資源即可在生產(chǎn)中可靠運(yùn)行。 因此，與VM相比，容器被認(rèn)為是輕量級的，獨(dú)立的和可移植的。

深入Kubernetes

我們希望您仍然在旅途中! 經(jīng)歷了容器和微服務(wù)之后，了解Kubernetes應(yīng)該會(huì)更容易。 在生產(chǎn)環(huán)境中，您必須管理容器化應(yīng)用程序的生命周期，以確保沒有停機(jī)時(shí)間并有效利用系統(tǒng)資源。 Kubernetes提供了一個(gè)框架來自動(dòng)彈性地管理分布式系統(tǒng)中的所有這些操作。 簡而言之，它是集群的操作系統(tǒng)。 群集由網(wǎng)絡(luò)中連接在一起的多個(gè)虛擬機(jī)或真實(shí)機(jī)組成。 正式而言，這是在官方網(wǎng)站上定義Kubernetes的方式：

" Kubernetes是一個(gè)可移植的，可擴(kuò)展的開源平臺，用于管理容器化的工作負(fù)載和服務(wù)，可促進(jìn)聲明性配置和自動(dòng)化。 它擁有一個(gè)龐大且快速增長的生態(tài)系統(tǒng)。 Kubernetes的服務(wù)，支持和工具廣泛可用。"

Kubernetes是一個(gè)可擴(kuò)展的系統(tǒng)。 它通過利用模塊化架構(gòu)來實(shí)現(xiàn)可伸縮性。 這意味著您的應(yīng)用程序的每個(gè)服務(wù)都由定義的API和負(fù)載平衡器分隔。 負(fù)載平衡器是一種機(jī)制，系統(tǒng)可以確保每個(gè)組件(無論是服務(wù)器還是服務(wù))都在利用最大可用容量來執(zhí)行其操作。 擴(kuò)展應(yīng)用程序僅僅是更改配置文件中復(fù)制容器的數(shù)量的問題，或者您可以簡單地啟用自動(dòng)擴(kuò)展功能。 這特別方便，因?yàn)閷⑾到y(tǒng)擴(kuò)展的復(fù)雜性委托給Kubernetes。 自動(dòng)擴(kuò)展是通過諸如內(nèi)存消耗，CPU負(fù)載等實(shí)時(shí)指標(biāo)來完成的。在用戶端，Kubernetes會(huì)自動(dòng)在群集中的復(fù)制容器之間平均分配流量，從而保持部署的穩(wěn)定。

Kubernetes可以實(shí)現(xiàn)更好的硬件利用率。 生產(chǎn)就緒型應(yīng)用程序通常依賴于必須在多臺服務(wù)器之間部署，配置和管理的大量組件。 如上所述，Kubernetes大大簡化了根據(jù)資源可用性標(biāo)準(zhǔn)(處理器，內(nèi)存等)確定必須在其中部署某個(gè)組件的服務(wù)器的任務(wù)。

Kubernetes的另一個(gè)很棒的功能是它可以自我修復(fù)，這意味著它可以自動(dòng)從故障中恢復(fù)，例如重新生成崩潰的容器。 例如，如果容器由于某種原因而失敗，Kubernetes將自動(dòng)比較正在運(yùn)行的容器的數(shù)量與配置文件中定義的數(shù)量，并根據(jù)需要重新啟動(dòng)新的容器，以確保最小的停機(jī)時(shí)間。

現(xiàn)在我們已經(jīng)解決了這個(gè)問題，現(xiàn)在該看看構(gòu)成Kubernetes的主要元素了。 我們將首先解釋下層的Kubernetes Worker節(jié)點(diǎn)，然后解釋上層的Kubernetes Master。 工人節(jié)點(diǎn)是運(yùn)行容器的奴才，而主節(jié)點(diǎn)是監(jiān)督系統(tǒng)的總部。

Kubernetes工作節(jié)點(diǎn)組件

Kubernetes工作者節(jié)點(diǎn)(也稱為Kubernetes奴才)包含與Kubernetes Master(主要是kube-apiserver)通信并運(yùn)行容器化應(yīng)用程序的所有必需組件。

Docker容器運(yùn)行時(shí)Kubernetes需要一個(gè)容器運(yùn)行時(shí)才能進(jìn)行編排。 Docker是一個(gè)常見的選擇，但也可以使用其他替代方案，例如CRI-O和Frakti。 Docker是一個(gè)用于構(gòu)建，交付和運(yùn)行容器化應(yīng)用程序的平臺。 Docker在每個(gè)工作程序節(jié)點(diǎn)上運(yùn)行，并負(fù)責(zé)運(yùn)行容器，下載容器映像和管理容器環(huán)境。

PodA pod包含一個(gè)或多個(gè)緊密耦合的容器(例如，一個(gè)用于后端服務(wù)器的容器，另一個(gè)用于輔助服務(wù)的容器，例如上載文件，生成分析報(bào)告，收集數(shù)據(jù)等)。 這些容器共享相同的網(wǎng)絡(luò)IP地址，端口空間甚至卷(存儲(chǔ))。 此共享卷具有與容器相同的生命周期，這意味著如果除去容器，該卷將消失。 但是，Kubernetes用戶可以設(shè)置持久卷以將其與Pod分離。 然后，卸下吊艙后，已安裝的卷仍將存在。

kube-proxy kube-proxy負(fù)責(zé)路由每個(gè)節(jié)點(diǎn)上的傳入或傳出網(wǎng)絡(luò)流量。 kube-proxy還是一個(gè)負(fù)載均衡器，可跨容器分布傳入的網(wǎng)絡(luò)流量。

kubelet kubelet從kube-apiserver獲取一組pod配置，并確保定義的容器正常運(yùn)行。

Kubernetes主組件

Kubernetes Master管理Kubernetes集群并協(xié)調(diào)工作節(jié)點(diǎn)。 這是大多數(shù)管理任務(wù)的主要切入點(diǎn)。

etcd etcd是Kubernetes集群的重要組成部分。 它是一個(gè)鍵值存儲(chǔ)，用于共享和復(fù)制所有配置，狀態(tài)和其他群集數(shù)據(jù)。

kube-apiserver幾乎所有Kubernetes組件之間的通信以及控制集群的用戶命令都是使用REST API調(diào)用完成的。 kube-apiserver負(fù)責(zé)處理所有這些API調(diào)用。

kube-scheduler kube-scheduler是Kubernetes中的默認(rèn)調(diào)度程序，可為新創(chuàng)建的Pod查找最佳工作節(jié)點(diǎn)。 如果需要，您還可以創(chuàng)建自己的自定義計(jì)劃組件。

kubectl kubectl是一個(gè)客戶端命令行工具，用于通過kube-apiserver通信和控制Kubernetes集群。

kube-controller-manager kube-controller-manager是一個(gè)守護(hù)程序(后臺進(jìn)程)，它嵌入了一組Kubernetes核心功能控制器，例如端點(diǎn)，名稱空間，復(fù)制，服務(wù)帳戶等。

cloud-controller-managercloud-controller-manager運(yùn)行與基礎(chǔ)云服務(wù)提供商進(jìn)行交互的控制器。 這使云提供商可以將Kubernetes集成到他們正在開發(fā)的云基礎(chǔ)架構(gòu)中。 諸如Google Cloud，AWS和Azure之類的云提供商已經(jīng)提供了其Kubernetes服務(wù)版本。

Kubernetes大數(shù)據(jù)

開發(fā)大數(shù)據(jù)解決方案的主要挑戰(zhàn)之一是定義正確的體系結(jié)構(gòu)，以在生產(chǎn)系統(tǒng)中部署大數(shù)據(jù)軟件。 顧名思義，大數(shù)據(jù)系統(tǒng)是處理在線和批處理數(shù)據(jù)的指數(shù)級增長的大規(guī)模應(yīng)用程序。 因此，需要一個(gè)可靠，可擴(kuò)展，安全且易于管理的平臺來彌合要處理的大量數(shù)據(jù)，軟件應(yīng)用程序和底層基礎(chǔ)結(jié)構(gòu)(內(nèi)部部署或基于云)之間的差距。

Kubernetes是在大型基礎(chǔ)架構(gòu)中部署應(yīng)用程序的優(yōu)秀選擇之一。 使用Kubernetes，可以處理需要的所有在線和批處理工作負(fù)載，例如分析和機(jī)器學(xué)習(xí)應(yīng)用程序。

在大數(shù)據(jù)世界中，Apache Hadoop一直是用于部署可擴(kuò)展和分布式應(yīng)用程序的主導(dǎo)框架。 但是，云計(jì)算和云原生應(yīng)用程序的興起削弱了Hadoop的普及程度(盡管像AWS和Cloudera這樣的大多數(shù)云供應(yīng)商仍提供Hadoop服務(wù))。 Hadoop基本上提供了三個(gè)主要功能：資源管理器(YARN)，數(shù)據(jù)存儲(chǔ)層(HDFS)和計(jì)算范例(MapReduce)。 所有這三個(gè)組件都已被更現(xiàn)代的技術(shù)所取代，例如用于資源管理的Kubernetes，用于存儲(chǔ)的Amazon S3和用于分布式計(jì)算的Spark / Flink / Dask。 此外，大多數(shù)云供應(yīng)商都提供自己的專有計(jì)算解決方案。

我們首先需要澄清的是，Hadoop或大多數(shù)其他大數(shù)據(jù)堆棧與Kubernetes之間沒有"一對一"的關(guān)系。 實(shí)際上，人們可以在Kubernetes上部署Hadoop。 但是，Hadoop是在與當(dāng)今時(shí)代截然不同的環(huán)境中構(gòu)建和成熟的。 它是在網(wǎng)絡(luò)延遲成為主要問題的時(shí)代構(gòu)建的。 企業(yè)被迫擁有內(nèi)部數(shù)據(jù)中心，以避免為了數(shù)據(jù)科學(xué)和分析目的而不得不移動(dòng)大量數(shù)據(jù)。 話雖如此，希望擁有自己的數(shù)據(jù)中心的大型企業(yè)將繼續(xù)使用Hadoop，但是由于更好的替代方案，采用率可能仍然很低。

如今，在云存儲(chǔ)提供商和云原生解決方案的主導(dǎo)下，企業(yè)內(nèi)部進(jìn)行了大量的計(jì)算操作。 此外，許多公司選擇在內(nèi)部部署自己的私有云。 由于這些原因，Hadoop，HDFS和其他類似產(chǎn)品已經(jīng)失去了對更新，更靈活，最終更優(yōu)秀的技術(shù)(例如Kubernetes)的吸引力。

大數(shù)據(jù)應(yīng)用程序是使用Kubernetes架構(gòu)的良好候選者，因?yàn)镵ubernetes集群具有可伸縮性和可擴(kuò)展性。 最近發(fā)生了一些重大運(yùn)動(dòng)，將Kubernetes用于大數(shù)據(jù)。 例如，Apache Spark是處理大量數(shù)據(jù)的繁重運(yùn)算的"海報(bào)子"，它正在努力添加本機(jī)Kubernetes調(diào)度程序以運(yùn)行Spark作業(yè)。 谷歌最近宣布，他們將用Kubernetes替換YARN，以安排其Spark工作。 電子商務(wù)巨頭eBay已部署了數(shù)千個(gè)Kubernetes集群來管理其Hadoop AI / ML管道。

那么Kubernetes為什么適合大數(shù)據(jù)應(yīng)用呢? 以兩個(gè)Apache Spark作業(yè)A和B在計(jì)算機(jī)上進(jìn)行一些數(shù)據(jù)聚合為例，并說一個(gè)共享依賴項(xiàng)已從版本X更新到Y(jié)，但是作業(yè)A需要版本X，而作業(yè)B需要版本Y。 ，作業(yè)A將無法運(yùn)行。

在Kubernetes集群中，每個(gè)節(jié)點(diǎn)將在其各自的驅(qū)動(dòng)程序和執(zhí)行程序容器上運(yùn)行隔離的Spark作業(yè)。 這種設(shè)置將避免依賴項(xiàng)互相干擾，同時(shí)仍保持并行化。

在部署大數(shù)據(jù)堆棧時(shí)，Kubernetes仍然有一些主要的痛點(diǎn)。 例如，由于容器是為短壽命的無狀態(tài)應(yīng)用程序設(shè)計(jì)的，因此對于在Kubernetes上運(yùn)行的大數(shù)據(jù)應(yīng)用程序來說，缺乏可以在不同作業(yè)之間共享的持久性存儲(chǔ)是一個(gè)主要問題。 其他主要問題包括調(diào)度(Spark的上述實(shí)施仍處于試驗(yàn)階段)，安全性和網(wǎng)絡(luò)連接。

考慮以下情況：節(jié)點(diǎn)A運(yùn)行的作業(yè)需要讀取群集中位于節(jié)點(diǎn)B上的數(shù)據(jù)節(jié)點(diǎn)上HDFS中存儲(chǔ)的數(shù)據(jù)。 這將大大增加網(wǎng)絡(luò)延遲，因?yàn)楝F(xiàn)在不像YARN，而是通過此隔離系統(tǒng)的網(wǎng)絡(luò)發(fā)送數(shù)據(jù)以進(jìn)行計(jì)算。 盡管嘗試解決這些數(shù)據(jù)局部性問題，但Kubernetes仍然有很長的路要走，才能真正成為部署大數(shù)據(jù)應(yīng)用程序的可行和現(xiàn)實(shí)的選擇。

盡管如此，開源社區(qū)仍在不懈地致力于解決這些問題，以使Kubernetes成為部署大數(shù)據(jù)應(yīng)用程序的實(shí)用選擇。 每年，Kubernetes由于其固有的優(yōu)勢(如彈性，可伸縮性和資源利用率)，越來越接近成為分布式大數(shù)據(jù)應(yīng)用程序的實(shí)際平臺。

在本文中，我們僅介紹了Kubernetes的表面，功能和在大數(shù)據(jù)中的應(yīng)用。 作為一個(gè)不斷發(fā)展的平臺，Kubernetes將繼續(xù)發(fā)展成為一種應(yīng)用于眾多技術(shù)領(lǐng)域的技術(shù)，尤其是在大數(shù)據(jù)和機(jī)器學(xué)習(xí)中。 如果您想了解有關(guān)Kubernetes的更多信息，請?jiān)?quot;外部鏈接"部分下找到一些有關(guān)主題的建議。 我們希望您喜歡我們有關(guān)Kubernetes的文章，并且讀起來很有趣。