本篇內(nèi)容介紹了“如何理解Kubernetes在大數(shù)據(jù)的應(yīng)用”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(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)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到芒康省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

 Kubernetes是什么?

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

什么是微服務(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)槊總€團(tuán)隊(duì)都可以專注于自己的組件，而不會干擾應(yīng)用程序的其他部分。

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

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

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

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

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

深入Kubernetes

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

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

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

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

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

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

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

kube-proxy kube-proxy負(fù)責(zé)路由每個節(jié)點(diǎn)上的傳入或傳出網(wǎng)絡(luò)流量。  kube-proxy還是一個負(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集群的重要組成部分。 它是一個鍵值存儲，用于共享和復(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是一個客戶端命令行工具，用于通過kube-apiserver通信和控制Kubernetes集群。

kube-controller-manager  kube-controller-manager是一個守護(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)用程序。  因此，需要一個可靠，可擴(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基本上提供了三個主要功能：資源管理器(YARN)，數(shù)據(jù)存儲層(HDFS)和計(jì)算范例(MapReduce)。  所有這三個組件都已被更現(xiàn)代的技術(shù)所取代，例如用于資源管理的Kubernetes，用于存儲的Amazon S3和用于分布式計(jì)算的Spark / Flink /  Dask。 此外，大多數(shù)云供應(yīng)商都提供自己的專有計(jì)算解決方案。

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

如今，在云存儲提供商和云原生解決方案的主導(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)動，將Kubernetes用于大數(shù)據(jù)。 例如，Apache  Spark是處理大量數(shù)據(jù)的繁重運(yùn)算的"海報子"，它正在努力添加本機(jī)Kubernetes調(diào)度程序以運(yùn)行Spark作業(yè)。  谷歌最近宣布，他們將用Kubernetes替換YARN，以安排其Spark工作。 電子商務(wù)巨頭eBay已部署了數(shù)千個Kubernetes集群來管理其Hadoop  AI / ML管道。

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

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

在部署大數(shù)據(jù)堆棧時，Kubernetes仍然有一些主要的痛點(diǎn)。  例如，由于容器是為短壽命的無狀態(tài)應(yīng)用程序設(shè)計(jì)的，因此對于在Kubernetes上運(yùn)行的大數(shù)據(jù)應(yīng)用程序來說，缺乏可以在不同作業(yè)之間共享的持久性存儲是一個主要問題。  其他主要問題包括調(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中存儲的數(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)用”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

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

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

廣告

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