如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用

本篇內(nèi)容介紹了“如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用”的有關(guān)知識(shí),在實(shí)際案例的操作過程中,不少人都會(huì)遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括芒康網(wǎng)站建設(shè)、芒康網(wǎng)站制作、芒康網(wǎng)頁制作以及芒康網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,芒康網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到芒康省份的部分城市,未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!

 Kubernetes是什么?

在過去的幾年中,Kubernetes一直是DevOps和Data Science社區(qū)中令人興奮的話題。  它已經(jīng)連續(xù)發(fā)展成為開發(fā)云原生應(yīng)用程序的首選平臺(tái)之一。  由Google作為開放源代碼平臺(tái)構(gòu)建的Kubernetes可以處理將容器調(diào)度到計(jì)算集群上的工作,并管理工作負(fù)載以確保它們按預(yù)期運(yùn)行。但是,有一個(gè)陷阱:這意味著什么?  當(dāng)然,有可能對Kubernetes進(jìn)行其他研究,但是假設(shè)大多數(shù)讀者已經(jīng)對技術(shù)基礎(chǔ)有所了解,那么Internet上的許多文章都是用專業(yè)術(shù)語和復(fù)雜術(shù)語充斥的高級概述。

什么是微服務(wù)?

如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用

為了了解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)

如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用

每個(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)錢。

如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用

容器,就像現(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ò)展的開源平臺(tái),用于管理容器化的工作負(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)用程序通常依賴于必須在多臺(tái)服務(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在大數(shù)據(jù)的應(yī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)用程序的平臺(tái)。  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ù)程序(后臺(tái)進(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ù)

如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用

開發(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ò)展,安全且易于管理的平臺(tái)來彌合要處理的大量數(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ì)算解決方案。

如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用

我們首先需要澄清的是,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在大數(shù)據(jù)的應(yīng)用

在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í)際平臺(tái)。

“如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!

分享文章:如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用
轉(zhuǎn)載注明:http://bm7419.com/article36/ipogsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供關(guān)鍵詞優(yōu)化、商城網(wǎng)站品牌網(wǎng)站設(shè)計(jì)、微信公眾號(hào)企業(yè)建站、手機(jī)網(wǎng)站建設(shè)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)公司