kubernetes（K8s）容器設計模式實踐案例 多節點選舉模式

《Kubernetes與云原生應用》專欄是InfoQ向輕元科技首席架構師王昕約稿的系列文章。本專欄包含8篇內容，將會從介紹和分析Kubernetes系統以及云原生應用 入手，逐步推出基于Kubernetes的容器設計模式實踐案例，希望對計劃應用Kubernetes的朋友有所幫助。本文是該專欄的第五篇。

1. Kubernetes系統架構與設計理念
2. 云原生應用的設計理念與挑戰
3.?Kubernetes與云原生應用的容器設計模式
4.?Kubernetes容器設計模式實踐案例-單節點多容器模式
5. Kubernetes容器設計模式實踐案例-多節點選舉模式
6. Kubernetes容器設計模式實踐案例-工作隊列模式
7. Kubernetes容器設計模式實踐案例-分散收集模式
8. 云原生應用的容器設計模式綜述與展望

K8s與容器設計模式

目前K8s社區推出的容器設計模式主要分為三大類：第一類，單容器管理模式；第二類，單節點多容器模式；第三類，多節點多容器模式；一類比一類更復雜。根據復雜性的不同，本系列文章給出不同篇幅的實踐案例介紹。本文將借助示例介紹多節點多容器模式中的多節點選舉模式。

多節點選舉模式

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

對于有狀態服務，人們也希望能夠水平的擴展，但因為每個實例有自己的持久化狀態，而這個持久化狀態必須要延續它的生命，因此，有狀態服務的水平伸縮模式就是狀態的分片，其中機制跟數據庫的分片是一致的。

那么對于一個原生為分布式系統設計的有狀態服務，每個實例與分片數據的對應關系，就成為這個有狀態服務的全局信息。對于任何服務，多個實例的全局信息都需要一個保存的地方。

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

例如Etcd和ElasticSearch，一定要有原生的主控節點選舉機制。

這樣這個分布式系統就不需要依賴外部的系統來維護自己的狀態了。對于一個分布式系統，最主要的系統全局信息，就是集群中有哪些節點，Master節點是哪個，每個節點對應哪個分片。主控節點的任務，就是保存和分發這些信息。

在K8s集群中，一個微服務實例Pod可以有多個容器。這一特性很好地提高了多節點選舉機制的可重用性。

它使得我們可以專門開發一個用于選舉的容器鏡像，在實際部署中，將選舉容器和普通應用容器組合起來，應用容器只需要從本地的選舉容器讀取狀態，就可以得到選舉結果。這樣，使得應用容器可以只關注自身業務邏輯相關的代碼。

選舉容器

選舉容器的代碼

本文中幾乎所有的代碼都來自于Kubernetes社區contrib項目election的事例代碼https://github.com/kubernetes/contrib/tree/master/election

本文作者只是做了少量的必要修改保證在中國地區運行方便，并且增加了一些yaml文件案例以提高案例的清晰度。由衷感謝原election事例的開發者。本文作者改動后的代碼在
https://github.com/xwangqingyuan/contrib/tree/master/election

啟動3個選舉容器觀察選舉

使用kubectl run啟動三個選舉容器觀察選舉。

使用kubectl logs 命令分別觀察三個pod的日志，可以發現它們只有一個獲得了leader的身份。

我們可以看到三個pod都匯報了election-1124968480-4ztqc。

刪除掉成為leader的pod觀察選舉對leader的更新

可以看到新的pod啟動代替了election-1124968480-4ztqc，仍然保證是3個pod。過一段時間后用kubectl log 觀察，可以看到3個pod都報告了新的leader是election-1124968480-khiy7。

實驗做完后，刪除這次實驗的deployment。

利用選舉容器的組合Pod

用來作為應用容器檢測選舉結果

用來作為應用容器檢測選舉結果的nodejs程序。

創建一個pod.yaml文件，定一個一個pod，包含一個主應用容器和一個選舉容器，pod.yaml的文件內容如下。

創建一個pod測試這個組合pod的工作

通過kubectl exec查詢這個pod的本地服務，得到Master節點。

啟動3個組合Pod觀察選舉

部署3個組合Pod的Deployment文件清單，在https://github.com/xwangqingyuan/contrib/blob/master/election/client/nodejs/election-sidecar.yaml
文件內容

用kubectl create創建3個pod。

用kubectl exec命令分別調用應用容器，察看選舉結果。

由此可以看到，對于3個Pod，通過其本地http://localhost:8080查詢到的leader都是demo-elector-nodejs-2834911605-0l22l。

刪除作為leader的Pod，觀察新選舉出來的Master Pod。

分別觀察各個Pod匯報的Master節點。

可以看到各個節點都匯報Master節點變為了demo-elector-nodejs-2834911605-191ts。

總結

本文主要介紹了K8s集群中，多節點容器模式中的多節點選舉模式。

多節點選舉模式，主要是為了原生分布式集群系統提供最基本的全局配置信息的保存。選舉的目的，是為了選出一個主控節點，保存全局信息，一般來說，主控節點負責全局信息的寫入，而這些全局信息會復制到其他節點作為備份。

一旦主控節點失效，新一輪選舉會被觸發，產生新的主控節點。這一機制是所有分布式系統的基礎。本文所介紹的多節點選舉模式，依靠K8s的Pod機制，成功地將選舉機制與應用業務邏輯相分離，提高了模塊的重用性，同時也避免了應用開發者去開發復雜的選舉邏輯。

文檔分享到此為止.

本文標題：kubernetes（K8s）容器設計模式實踐案例 多節點選舉模式

總結

以上是生活随笔為你收集整理的kubernetes（K8s）容器设计模式实践案例 多节点选举模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。