Kubernetes與容器設(shè)計模式的示例分析

小編給大家分享一下Kubernetes與容器設(shè)計模式的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都做網(wǎng)站、成都網(wǎng)站設(shè)計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元龍泉驛做網(wǎng)站,已為上家服務(wù),為龍泉驛各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220

在程序設(shè)計領(lǐng)域，面向?qū)ο笤O(shè)計和面向?qū)ο笳Z言是大家最為熟悉和強(qiáng)大的工具，而面向?qū)ο蟪似鋸?qiáng)大的核心特性之外，還有人們通過實踐總結(jié)出來的一系列設(shè)計模式，可以用來解決實際應(yīng)用設(shè)計中的一些復(fù)雜問題。

云原生應(yīng)用運行的環(huán)境都是復(fù)雜的分布式環(huán)境，在這種情況下，一些有用的設(shè)計模式可以起到四兩撥千斤的作用，而K8s社區(qū)推出的容器設(shè)計模式，則是結(jié)合了K8s集群的微服務(wù)模型提出的一系列可重用的解決典型分布式系統(tǒng)問題的模式。目前K8s社區(qū)推出的容器設(shè)計模式主要分為三大類：

1)        單容器管理模式；

2)        單節(jié)點多容器模式；

3)        多節(jié)點多容器模式；

一、單容器管理模式

K8s的最大特色是支持多容器的微服務(wù)實例。當(dāng)然，單容器的模式也是支持的，只不過這種模式并不能突出K8s的特色和強(qiáng)大。很多人對K8s一直以來的印象是：功能強(qiáng)大，但入門較難。其實，單單就啟動一個單容器微服務(wù)實例，K8s的命令行操作跟Docker原生命令一樣簡單。

[root@demo-k8s ~]# kubectl run nginx --image=nginx
deployment "nginx" created
[root@demo-k8s ~]# kubectl get deployment
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     1         1         1            1           24s
[root@demo-k8s ~]# kubectl get rs
NAME               DESIRED   CURRENT   AGE
nginx-3137573019   1         1         1m

由上面的例子可以看到，K8s只要一個命令既可以啟動以nginx為鏡像的一個微服務(wù)實例。與此同時，K8s的強(qiáng)大之處在于，方便用戶用一個命令的同時，仍然保證了K8s應(yīng)用體系的完整性和規(guī)范性。也就是說，雖然用戶只運行了一個命令，但K8s為用戶自動創(chuàng)建了四種API對象，包括：Deployment，ReplicaSet(RS)，Pod和Container。要想擴(kuò)展伸縮同一服務(wù)的實例個數(shù)也非常簡單。

[root@demo-k8s ~]# kubectl scale deployment nginx --replicas=3
deployment "nginx" scaled
[root@demo-k8s ~]# kubectl get rs
NAME               DESIRED   CURRENT   AGE
nginx-3137573019   3         3         22m

依靠這種兼顧易用性和模型一致性的設(shè)計理念，K8s使自己既適合簡單場景也適合復(fù)雜場景。

二、單節(jié)點多容器模式

從單節(jié)點多容器模式開始的容器設(shè)計模式，是真正體現(xiàn)K8s設(shè)計特點的地方，也就是基于多容器微服務(wù)模型的分布式應(yīng)用模型。在K8s體系中，Pod是一個輕量級的節(jié)點，同一個Pod中的容器可以共享同一塊存儲空間和同一個網(wǎng)絡(luò)地址空間，這使得我們可以實現(xiàn)一些組合多個容器在同一節(jié)點工作的模式。既然Pod的特點是共享存儲空間和網(wǎng)絡(luò)地址，那么單節(jié)點多容器模式一定是利用這兩種特性的。

2.1 挎斗模式（Sidecar pattern）

第一種單節(jié)點多容器模式是挎斗模式。這種模式主要是利用在同一Pod中的容器可以共享存儲空間的能力。

一個典型的挎斗應(yīng)用場景如圖所示：一個工具容器寫文件到共享的文件目錄，應(yīng)用主容器從共享的文件目錄讀文件。例如，我們可以用Nginx構(gòu)建一個代碼發(fā)布倉庫，簡單的將代碼放到某個本地目錄即可。為了保持同步，我們同時用一個裝有Git客戶端的容器定時到原始代碼倉庫同步下拉最新的代碼。這種模式的好處是，工具容器的鏡像，也就是打包有Git客戶端的鏡像可以重用，而不需要跟應(yīng)用的容器打包在一起。同樣的應(yīng)用，應(yīng)用主容器不用Nginx也可以用Apache Httpd，都可以跟工具容器組合起來形成微服務(wù)。

另一個典型的挎斗模式如圖所示：一個工具容器讀文件，應(yīng)用容器寫文件。例如：一個基于Nginx的Web應(yīng)用向系統(tǒng)文件系統(tǒng)寫入日志，而一個收集日志的容器從共享目錄讀出日志，并輸出到集群的日志系統(tǒng)。這一模式的好處在于，工具容器的鏡像是可以重用的，不需要在每次更新應(yīng)用容器打包的時候，把工具容器的執(zhí)行文件打包進(jìn)去。

2.2 外交官模式(Ambassador pattern)

第二種單節(jié)點多容器模式是外交官模式。這種模式主要利用同一Pod中的容器可以共享網(wǎng)絡(luò)地址空間的特性。如圖所示，在一個Pod中給應(yīng)用容器搭配一個工具容器作為代理服務(wù)器。工具容器幫助應(yīng)用容器訪問外部服務(wù)，使得應(yīng)用容器訪問服務(wù)時不需要使用外網(wǎng)的IP地址，而只需要用localhost訪問本地服務(wù)。在這種模式下，作為代理服務(wù)器的工具容器好像外部服務(wù)派駐在Pod中的“外交官”，使得應(yīng)用容器辦理業(yè)務(wù)時只需要跟本Pod的外交官打交道，而不需要出國了，因此而得名。

2.2.1基于外交官模式的redis訪問案例

2.3 適配器模式（Adapter pattern）

第三種單節(jié)點多容器模式是適配器模式。這種模式對于監(jiān)控和管理分布式系統(tǒng)尤為重要。對分布式系統(tǒng)的一種理想設(shè)計目標(biāo)，就是能夠?qū)崿F(xiàn)“分布地執(zhí)行和存儲，統(tǒng)一的監(jiān)控和管理”。要想實現(xiàn)“統(tǒng)一的監(jiān)控和管理”，應(yīng)用和監(jiān)控管理交互的接口需要是統(tǒng)一的，而且其接口是依照“統(tǒng)一的監(jiān)控服務(wù)”的接口模式來實現(xiàn)。這和面向?qū)ο笤O(shè)計模式中的“適配器模式”也非常相似。

一個典型的可以采用適配器模式的系統(tǒng)，是利用Prometheus作為監(jiān)控服務(wù)的分布式系統(tǒng)。在Prometheus周邊項目中，有諸多適用于不同應(yīng)用系統(tǒng)的監(jiān)控數(shù)據(jù)輸出器（Exporter），負(fù)責(zé)收集跟特定應(yīng)用相關(guān)的監(jiān)控數(shù)據(jù)，使得Prometheus服務(wù)可以以統(tǒng)一的數(shù)據(jù)模式收集不同應(yīng)用系統(tǒng)的監(jiān)控數(shù)據(jù)，每個Exporter同時也都是一個適配器模式的實現(xiàn)。

三、多節(jié)點組合模式

3.1 多節(jié)點選舉模式

多節(jié)點選舉在分布式系統(tǒng)中是一種重要的模式，特別是對有狀態(tài)服務(wù)來說。在分布式系統(tǒng)中，一般來說，無狀態(tài)服務(wù)，可以隨意的水平伸縮，只要把運行業(yè)務(wù)邏輯的實例復(fù)制出去運行就可以，這也就是K8s里ReplicationController和ReplicaSet所做的事情。

對于有狀態(tài)服務(wù)，人們也希望能夠水平的擴(kuò)展，但因為每個實例有自己的持久化狀態(tài)，而這個持久化狀態(tài)必須要延續(xù)它的生命，因此，有狀態(tài)服務(wù)的水平伸縮模式就是狀態(tài)的分片，其中機(jī)制跟數(shù)據(jù)庫的分片是一致的。那么對于一個原生為分布式系統(tǒng)設(shè)計的有狀態(tài)服務(wù)，每個實例與分片數(shù)據(jù)的對應(yīng)關(guān)系，就成為這個有狀態(tài)服務(wù)的全局信息。對于任何服務(wù)，多個實例的全局信息都需要一個保存的地方。

一個簡單的辦法是保存在外部的一個代理服務(wù)器上，這也就是MariaDB的Galera解決方案的做法，也是所以代理服務(wù)器為后端服務(wù)器所做的事情。但這種方式的問題在于，系統(tǒng)要依賴外部代理服務(wù)器，而代理服務(wù)器本身的高可用和水平伸縮還是沒有解決的問題。

所以對于要原生自己解決高可用和水平伸縮問題的系統(tǒng)，例如Etcd和ElasticSearch，一定要有原生的主控節(jié)點選舉機(jī)制。這樣這個分布式系統(tǒng)就不需要依賴外部的系統(tǒng)來維護(hù)自己的狀態(tài)了。對于一個分布式系統(tǒng)，最主要的系統(tǒng)全局信息，就是集群中有哪些節(jié)點，Master節(jié)點是哪個，每個節(jié)點對應(yīng)哪個分片。主控節(jié)點的任務(wù)，就是保存和分發(fā)這些信息。

 　　在K8s集群中，一個微服務(wù)實例Pod可以有多個容器。這一特性很好地提高了多節(jié)點選舉機(jī)制的可重用性。它使得我們可以專門開發(fā)一個用于選舉的容器鏡像，在實際部署中，將選舉容器和普通應(yīng)用容器組合起來，應(yīng)用容器只需要從本地的選舉容器讀取狀態(tài)，就可以得到選舉結(jié)果。這樣，使得應(yīng)用容器可以只關(guān)注自身業(yè)務(wù)邏輯相關(guān)的代碼。

3.2工作隊列模式

分布式系統(tǒng)的一個重要作用是能夠充分利用多個物理計算資源的能力，特別是在動態(tài)按需調(diào)動計算資源完成計算任務(wù)。設(shè)想如果有大量的需要處理的任務(wù)隨機(jī)的到來，對計算資源需要的容量是不確定地；顯然，按照最大可能計算量和最小可能計算量設(shè)置計算節(jié)點都是不合理的。

這種情況下，可以把需要處理的任務(wù)放到一個待處理的隊列里，根據(jù)需要啟動計算節(jié)點從隊列讀取任務(wù)進(jìn)行處理。在容器技術(shù)廣泛應(yīng)用之前，也有諸多的分布式處理系統(tǒng)依靠隊列來處理大量計算任務(wù)，例如大數(shù)據(jù)處理系統(tǒng)Hadoop和Spark等。這些系統(tǒng)的一個限制是實現(xiàn)隊列處理模式大多要遵循特定的編程模式和特定的編程語言，同時搭建基礎(chǔ)設(shè)施也大多復(fù)雜而耗時。而基于容器和Kubernetes編排技術(shù)的工作隊列模式的好處在于，利用非常簡單的編排腳本就可以實現(xiàn)工作隊列模式，而用Pod作為輕量級處理節(jié)點的模式，使得動態(tài)的調(diào)度計算資源變得非常容易。在Kubernetes中應(yīng)用工作隊列模式的邏輯示意圖如下：

以上是“Kubernetes與容器設(shè)計模式的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

標(biāo)題名稱：Kubernetes與容器設(shè)計模式的示例分析
網(wǎng)站地址：http://muchs.cn/article40/jpiieo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設(shè)、企業(yè)建站、手機(jī)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計公司、建站公司、軟件開發(fā)

廣告

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