Kubernetes資源類型的示例分析

這篇文章給大家分享的是有關(guān)Kubernetes資源類型的示例分析的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

Kubernetes是一個(gè)開(kāi)源的容器管理平臺(tái)，用于部署和管理容器化的工作負(fù)載。在生產(chǎn)環(huán)境中運(yùn)行容器時(shí)，您將擁有幾十個(gè)、甚至數(shù)千個(gè)容器。

這些容器需要部署、管理和連接，這很難手動(dòng)完成。這就是Kubernetes的作用?？梢园阉胂蟪梢粋€(gè)容器調(diào)度程序。

Kubernetes被設(shè)計(jì)成與Docker一起工作，Docker是一個(gè)容器化平臺(tái)，它將應(yīng)用程序和所有依賴項(xiàng)打包成一個(gè)容器。

舉例:Docker用于隔離、打包和以容器的形式運(yùn)輸應(yīng)用程序。Kubernetes是用于部署和擴(kuò)展應(yīng)用程序的容器調(diào)度器。

關(guān)于Kubernetes，我們可以:

• 在不停機(jī)的情況下部署服務(wù)和推出新版本

• 在私有或公共云上運(yùn)行

• 在最合適的服務(wù)器上放置和縮放服務(wù)的副本

• 驗(yàn)證服務(wù)的運(yùn)行狀況

• 有狀態(tài)應(yīng)用程序的掛載卷

現(xiàn)在我們已經(jīng)復(fù)習(xí)了Kubernetes，讓我們跳到它的一些資源并討論何時(shí)使用它們。從pods開(kāi)始。

Pods是什么?

pod是Kubernetes中應(yīng)用程序的最低或更原子的單元。需要注意的是，在Docker世界中，pod并不等于容器。一個(gè)pod可以由多個(gè)容器組成。如果您有純Docker背景，這可能很難理解。

可以將其看作Kubernetes抽象，它表示一組容器和它們的共享資源。例如，Pod可以包括一個(gè)帶有Node.js應(yīng)用程序的容器和另一個(gè)向web服務(wù)器提供數(shù)據(jù)的容器。

pod是表示集群中正在運(yùn)行的進(jìn)程的一種方法。

如果一個(gè)pod可以有多個(gè)容器，它是如何工作的?我們需要注意一些限制。pod有以下內(nèi)容:

• 單一IP地址

• 共享主機(jī)

• 共享的IPC空間

• 共享網(wǎng)絡(luò)端口范圍

• 共享卷

pod中的容器通過(guò)本地主機(jī)相互通信，而pod-to-pod的通信是通過(guò)服務(wù)完成的。從圖中可以看到，pod中的容器共享一個(gè)IP地址。

pod是部署應(yīng)用程序的好方法，但是pod資源類型有一些限制。pod是單個(gè)實(shí)體，如果它失敗了，它就不能重新啟動(dòng)自己。這并不適合大多數(shù)用例，因?yàn)槲覀兿Ｍ麘?yīng)用程序具有高可用性。

但是Kubernetes已經(jīng)解決了這個(gè)問(wèn)題，我們將在文章中進(jìn)一步研究如何處理高可用性。

在Kubernetes中，pod總是在節(jié)點(diǎn)上運(yùn)行?？梢詫⒐?jié)點(diǎn)看作由主服務(wù)器管理的工作機(jī)器。一個(gè)節(jié)點(diǎn)可以有多個(gè)pods，主節(jié)點(diǎn)會(huì)自動(dòng)在一個(gè)節(jié)點(diǎn)上安排這些pods。

Pods原理

Pods被設(shè)計(jì)成一個(gè)運(yùn)行多個(gè)進(jìn)程的內(nèi)聚單元。這些進(jìn)程被包裝在容器中。組成pod的所有容器都運(yùn)行在同一臺(tái)機(jī)器上，不能跨多個(gè)節(jié)點(diǎn)拆分。

Pod中的所有進(jìn)程(或容器)共享相同的資源(例如存儲(chǔ))，它們可以通過(guò)本地主機(jī)彼此通信。卷就像具有可共享數(shù)據(jù)的目錄。所有容器都可以訪問(wèn)它們并共享相同的數(shù)據(jù)。

Replication controller

我們剛剛得知pods是會(huì)死的。如果他們死了，那就是他們的結(jié)局。但是，如果您希望運(yùn)行同一版本的三個(gè)pod以獲得高可用性，該怎么辦呢?那就是replication  controller的作用了。

replication controller的主要職責(zé)是防止失敗。它位于pod資源類型之上并對(duì)其進(jìn)行控制。

這個(gè)功能處理了pods的這個(gè)問(wèn)題。但是，需要注意的是，replication controller并不處理與pods相關(guān)的所有內(nèi)容，即生命周期。

假設(shè)我們想在不停機(jī)的情況下升級(jí)pod。replication controller將不負(fù)責(zé)此操作。

現(xiàn)在我們已經(jīng)了解了pods，讓我們進(jìn)入下一個(gè)Kubernetes資源: services。

什么是Services?

如果我們想要連接到pods，就需要?jiǎng)?chuàng)建一個(gè)Service。在Kubernetes中，Service是一組pods上的網(wǎng)絡(luò)抽象?？梢詫⑵淇醋髟诩荷线\(yùn)行的一組pods。Kubernetes服務(wù)通常用于支持微服務(wù)體系結(jié)構(gòu)。

Kubernetes為一組pods提供了它們自己的IP地址和單個(gè)DNS名稱，并可以在它們之間實(shí)現(xiàn)負(fù)載平衡。它們提供了標(biāo)準(zhǔn)化集群的特性，例如:

• 負(fù)載平衡

• 零宕機(jī)的部署

• 應(yīng)用程序之間的服務(wù)發(fā)現(xiàn)

它允許在出現(xiàn)故障時(shí)，對(duì)流量進(jìn)行負(fù)載平衡。一項(xiàng)服務(wù)允許Kubernetes為pods設(shè)置單一的DNS記錄。如前所述，每個(gè)pod都有一個(gè)單獨(dú)的IP地址。對(duì)于服務(wù)資源類型，你通常會(huì)像下面的例子一樣定義一個(gè)選擇器:

除此之外，kube-proxy還在集群中創(chuàng)建一個(gè)虛擬IP來(lái)訪問(wèn)服務(wù)。然后，這個(gè)虛擬IP路由到pod IP。如果pod  ip更改或部署了新的pods，service資源類型將跟蹤更改，并代表您更新內(nèi)部路由。

deployments是什么?

現(xiàn)在是拼圖的最后一部分:deployments。deployments資源類型位于一個(gè)副本集(ReplicaSet)之上，可以對(duì)其進(jìn)行操作。換句話說(shuō)，deployments為pods副本集提供更新。

為此，您需要在deployments中描述所需的狀態(tài)，然后部署控制器將以可控的速度更改為所需的狀態(tài)。這允許您運(yùn)行無(wú)狀態(tài)應(yīng)用程序。如果需要進(jìn)行升級(jí)，則需要替換副本集。此操作將導(dǎo)致應(yīng)用程序停機(jī)。

Kubernetes的主要優(yōu)點(diǎn)之一是高可用性。deployment使我們能夠在不停機(jī)的情況下進(jìn)行升級(jí)。與在復(fù)制集中所做的一樣，指定要運(yùn)行的pods數(shù)量。

一旦觸發(fā)更新，deployment將對(duì)pods執(zhí)行滾動(dòng)升級(jí)，同時(shí)確保每個(gè)pod的升級(jí)成功，然后再轉(zhuǎn)移到下一個(gè)。

讓我們看一個(gè)deployment示例，看看它們是如何創(chuàng)建的。

后一個(gè)命令的輸出如下所示。

那么，如果我們推出了一個(gè)新版本的應(yīng)用程序，但出現(xiàn)了錯(cuò)誤，會(huì)發(fā)生什么情況呢?deployment也有解決方法，我們可以很容易地回滾部署。

這里有一個(gè)警告:如果您正在使用pvc(持久卷聲明)并在聲明中寫(xiě)入了一些內(nèi)容。這是不會(huì)逆轉(zhuǎn)的。

Deployment控制ReplicaSet，而ReplicaSet控制Pods。因此，在使用Deployment資源類型時(shí)，您仍然需要一個(gè)Service來(lái)訪問(wèn)它。

感謝各位的閱讀！關(guān)于“Kubernetes資源類型的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！