本篇文章為大家展示了Kubernetes是如何工作的，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

在廣豐等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站開發(fā),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站制作,廣豐網(wǎng)站建設(shè)費(fèi)用合理。

過去幾年來，運(yùn)行容器化應(yīng)用程序的流行度呈爆炸式增長，這已經(jīng)不是什么秘密了。能夠通過代碼提供應(yīng)用程序的依賴項(xiàng)來迭代和發(fā)布應(yīng)用程序是一個(gè)巨大的勝利。Gartner表示，到2022年，“超過75%的全球組織將在生產(chǎn)中運(yùn)行容器化應(yīng)用程序”。

對于大規(guī)模運(yùn)行的組織來說，一個(gè)Linux容器實(shí)例不足以滿足其應(yīng)用程序的所有需求。對于足夠復(fù)雜的應(yīng)用程序，例如通過微服務(wù)進(jìn)行通信的應(yīng)用程序，需要多個(gè)相互通信的Linux容器并不少見。該體系結(jié)構(gòu)引入了一個(gè)新的擴(kuò)展問題：如何管理所有這些單獨(dú)的容器？開發(fā)者仍然需要安排容器在特定機(jī)器上的部署，管理它們之間的網(wǎng)絡(luò)，增加在高負(fù)載下分配的資源等等。

來到Kubernetes，一個(gè)容器編排系統(tǒng) - 一種管理容器化應(yīng)用程序生命周期的方法。它是一種元過程，允許同時(shí)自動部署和擴(kuò)展多個(gè)容器。運(yùn)行相同應(yīng)用程序的幾個(gè)容器被分組在一起。這些容器充當(dāng)副本（replica），并用于負(fù)載平衡傳入的請求。然后，容器編排器監(jiān)督這些組，確保它們正確地運(yùn)行。

容器編排器本質(zhì)上是負(fù)責(zé)操作一組容器化應(yīng)用程序的管理員。如果需要重新啟動容器或獲取更多資源，則由編排器為你處理。

這是對大多數(shù)容器編排器工作原理的一個(gè)相當(dāng)廣泛的概述。讓我們更深入地研究一下Kubernetes的所有組成部分。

Kubernetes術(shù)語和架構(gòu)

Kubernetes引入了許多詞匯來描述應(yīng)用程序的組織方式。我們將從最小的一層開始。

Pod

Kubernetes pod是一組容器，是Kubernetes管理的最小單元。Pod有一個(gè)單獨(dú)的IP地址，應(yīng)用于pod中的每個(gè)容器。Pod中的容器共享相同的資源，比如內(nèi)存和存儲。這允許將pod內(nèi)的單個(gè)Linux容器作為單個(gè)應(yīng)用程序一起處理，就好像在更傳統(tǒng)的工作負(fù)載中，所有容器化的進(jìn)程都在同一主機(jī)上運(yùn)行一樣。當(dāng)應(yīng)用程序或服務(wù)是需要運(yùn)行的單個(gè)進(jìn)程時(shí)，只有一個(gè)容器的pod是很常見的。但是，當(dāng)事情變得更加復(fù)雜，并且多個(gè)進(jìn)程需要使用相同的共享數(shù)據(jù)卷共同工作以實(shí)現(xiàn)正確的操作時(shí)，與單獨(dú)在容器之間設(shè)置共享資源相比，多容器pod簡化了部署配置。

例如，如果你正在處理創(chuàng)建gif的圖像處理服務(wù)，一個(gè)pod可能有多個(gè)容器一起工作來調(diào)整圖像的大小。主容器可能運(yùn)行接收請求的非阻塞微服務(wù)應(yīng)用程序，然后運(yùn)行一個(gè)或多個(gè)輔助（側(cè)車）容器，運(yùn)行批處理后臺進(jìn)程或清理存儲卷中的數(shù)據(jù)構(gòu)件，作為管理整體應(yīng)用程序性能的一部分。

Deployment

Kubernetes deployment（部署）允許你設(shè)置希望如何在Kubernetes節(jié)點(diǎn)上復(fù)制pod的詳細(xì)信息，從而定義希望運(yùn)行應(yīng)用程序的規(guī)模。Deployment描述所需運(yùn)行的相同pod副本的數(shù)量，以及更新部署時(shí)使用的首選更新策略。Kubernetes將跟蹤pod的健康狀況，并根據(jù)需要刪除或添加pod，使應(yīng)用程序部署達(dá)到所需的狀態(tài)。

Service

單個(gè)pod的壽命不能被依賴；從它們的IP地址到它們的存在，一切都有可能發(fā)生變化。事實(shí)上，在DevOps社區(qū)中，有一個(gè)概念是將服務(wù)器視為“寵物”（pets）或“?！保╟attle）。寵物是你需要特別照顧的東西，而牛則被認(rèn)為是更值得犧牲的東西。同樣，Kubernetes也沒有將它的pods視為惟一的長時(shí)間運(yùn)行的實(shí)例；如果pod遇到問題而死亡，Kubernetes的工作就是替換它，這樣應(yīng)用程序就不會經(jīng)歷任何停機(jī)時(shí)間。

Service是對pods的抽象，本質(zhì)上是各種應(yīng)用程序使用者交互的惟一接口。當(dāng)pod被替換時(shí)，它們的內(nèi)部名稱和IP可能會發(fā)生變化。Service將單個(gè)機(jī)器名稱或IP地址映射到其基礎(chǔ)名稱和編號可以是不可靠的pod。Service確保在外部網(wǎng)絡(luò)中，一切看起來都是不變的。

Node

Kubernetes node（節(jié)點(diǎn)）管理和運(yùn)行pod；是執(zhí)行給定工作的機(jī)器（無論是虛擬的還是物理的）。就像pod收集一起操作的單個(gè)容器一樣，node收集一起工作的整個(gè)pod。當(dāng)你進(jìn)行大規(guī)模操作時(shí)，你希望能夠?qū)⒐ぷ饕平唤o一個(gè)node，該node的pod可以接收工作。

Master server

這是管理員和用戶管理各種節(jié)點(diǎn)的主要入口。操作通過HTTP調(diào)用，或連接到機(jī)器并運(yùn)行命令行腳本發(fā)送給它。

Cluster

Cluster（集群）是將上述所有組件作為一個(gè)單元組合在一起。

Kubernetes組件

對于Kubernetes是如何組裝的有了一個(gè)大致的概念，現(xiàn)在就來看看確保一切順利運(yùn)行的各種軟件組件。主服務(wù)器和單個(gè)工作節(jié)點(diǎn)都有三個(gè)主要組件。

Master server組件

API Server

API服務(wù)器向Kubernetes集群暴露一個(gè)REST接口。所有針對pod、service等的操作都是通過與它提供的端點(diǎn)通信以編程方式執(zhí)行的。

Scheduler

調(diào)度程序負(fù)責(zé)將工作分配給各個(gè)節(jié)點(diǎn)。它監(jiān)視資源容量，并確保工作節(jié)點(diǎn)（Worker node）的性能處于適當(dāng)?shù)拈撝抵畠?nèi)。

Controller-manager

controller-manager負(fù)責(zé)確保集群的共享狀態(tài)按預(yù)期運(yùn)行。更準(zhǔn)確地說，控制器管理器監(jiān)視響應(yīng)事件的各種控制器（例如，如果節(jié)點(diǎn)發(fā)生故障）。

Worker node組件

Kubelet

Kubelet跟蹤pod的狀態(tài)，以確保所有容器都在運(yùn)行。它每隔幾秒鐘向主服務(wù)器（Master server）提供一條心跳消息。如果復(fù)制控制器（replication controller）沒有接收到該消息，則節(jié)點(diǎn)被標(biāo)記為不健康。

Kube proxy

Kube代理發(fā)送從服務(wù)進(jìn)入節(jié)點(diǎn)的流量。它將工作請求轉(zhuǎn)發(fā)到正確的容器。

etcd

etcd是一個(gè)分布式鍵值存儲，Kubernetes使用它來共享關(guān)于集群總體狀態(tài)的信息。此外，節(jié)點(diǎn)可以引用存儲在那里的全局配置數(shù)據(jù)，以便在重新生成它們時(shí)設(shè)置它們自己。

上述內(nèi)容就是Kubernetes是如何工作的，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。