Kubernetes（k8s）有狀態(tài)集群服務部署與管理

由于篇幅關系，第一部分Kubernetes相關概念略過不提，本文將結合分享內容， 對《Kubernetes有狀態(tài)服務部署與管理》之K8S存儲系統(tǒng)做重點闡述。

在K8S運行的服務，從簡單到復雜可以分成三類：無狀態(tài)服務、普通有狀態(tài)服務和有狀態(tài)集群服務。下面分別來看K8S是如何運行這三類服務的。

* 無狀態(tài)服務，K8S使用RC（或更新的Replica
Set）來保證一個服務的實例數(shù)量，如果說某個Pod實例由于某種原因Crash了，RC會立刻用這個Pod的模版新啟一個Pod來替代它，由于是無狀態(tài)的服務，新啟的Pod與原來健康狀態(tài)下的Pod一模一樣。在Pod被重建后它的IP地址可能發(fā)生變化，為了對外提供一個穩(wěn)定的訪問接口，K8S引入了Service的概念。一個Service后面可以掛多個Pod，實現(xiàn)服務的高可用。
* 普通有狀態(tài)服務，和無狀態(tài)服務相比，它多了狀態(tài)保存的需求。Kubernetes提供了以Volume和Persistent
Volume為基礎的存儲系統(tǒng)，可以實現(xiàn)服務的狀態(tài)保存。
* 有狀態(tài)集群服務，與普通有狀態(tài)服務相比，它多了集群管理的需求。K8S為此開發(fā)了一套以Pet
Set為核心的全新特性，方便了有狀態(tài)集群服務在K8S上的部署和管理。具體來說是通過Init Container來做集群的初始化工作，用 Headless
Service 來維持集群成員的穩(wěn)定關系，用動態(tài)存儲供給來方便集群擴容，最后用Pet Set來綜合管理整個集群。
要運行有狀態(tài)集群服務要解決的問題有兩個,一個是狀態(tài)保存，另一個是集群管理。 我們先來看如何解決第一個問題：狀態(tài)保存。Kubernetes
有一套以Volume插件為基礎的存儲系統(tǒng)，通過這套存儲系統(tǒng)可以實現(xiàn)應用和服務的狀態(tài)保存。

K8S的存儲系統(tǒng)從基礎到高級又大致分為三個層次：普通Volume，Persistent Volume 和動態(tài)存儲供應。

1.普通Volume

最簡單的普通Volume是單節(jié)點Volume。它和Docker的存儲卷類似，使用的是Pod所在K8S節(jié)點的本地目錄。

第二種類型是跨節(jié)點存儲卷，這種存儲卷不和某個具體的K8S節(jié)點綁定，而是獨立于K8S節(jié)點存在的，整個存儲集群和K8S集群是兩個集群，相互獨立。

跨節(jié)點的存儲卷在Kubernetes上用的比較多，如果已有的存儲不能滿足要求，還可以開發(fā)自己的Volume插件，只需要實現(xiàn)Volume.go
里定義的接口。如果你是一個存儲廠商，想要自己的存儲支持Kubernetes 上運行的容器，就可以去開發(fā)一個自己的Volume插件。

2.persistent volume

它和普通Volume的區(qū)別是什么呢？

普通Volume和使用它的Pod之間是一種靜態(tài)綁定關系，在定義Pod的文件里，同時定義了它使用的Volume。Volume
是Pod的附屬品，我們無法單獨創(chuàng)建一個Volume，因為它不是一個獨立的K8S資源對象。

而Persistent Volume 簡稱PV是一個K8S資源對象，所以我們可以單獨創(chuàng)建一個PV。它不和Pod直接發(fā)生關系，而是通過Persistent
Volume Claim，簡稱PVC來實現(xiàn)動態(tài)綁定。Pod定義里指定的是PVC，然后PVC會根據(jù)Pod的要求去自動綁定合適的PV給Pod使用。

PV的訪問模式有三種：

第一種，ReadWriteOnce：是最基本的方式，可讀可寫，但只支持被單個Pod掛載。

第二種，ReadOnlyMany：可以以只讀的方式被多個Pod掛載。


第三種，ReadWriteMany：這種存儲可以以讀寫的方式被多個Pod共享。不是每一種存儲都支持這三種方式，像共享方式，目前支持的還比較少，比較常用的是NFS。在PVC綁定PV時通常根據(jù)兩個條件來綁定，一個是存儲的大小，另一個就是訪問模式。

剛才提到說PV與普通Volume的區(qū)別是動態(tài)綁定，我們來看一下這個過程是怎樣的。


這是PV的生命周期，首先是Provision，即創(chuàng)建PV，這里創(chuàng)建PV有兩種方式，靜態(tài)和動態(tài)。所謂靜態(tài)，是管理員手動創(chuàng)建一堆PV，組成一個PV池，供PVC來綁定。動態(tài)方式是通過一個叫
Storage Class的對象由存儲系統(tǒng)根據(jù)PVC的要求自動創(chuàng)建。

一個PV創(chuàng)建完后狀態(tài)會變成Available，等待被PVC綁定。

一旦被PVC邦定，PV的狀態(tài)會變成Bound，就可以被定義了相應PVC的Pod使用。

Pod使用完后會釋放PV，PV的狀態(tài)變成Released。

變成Released的PV會根據(jù)定義的回收策略做相應的回收工作。有三種回收策略，Retain、Delete 和
Recycle。Retain就是保留現(xiàn)場，K8S什么也不做，等待用戶手動去處理PV里的數(shù)據(jù)，處理完后，再手動刪除PV。Delete
策略，K8S會自動刪除該PV及里面的數(shù)據(jù)。Recycle方式，K8S會將PV里的數(shù)據(jù)刪除，然后把PV的狀態(tài)變成Available，又可以被新的PVC綁定使用。


在實際使用場景里，PV的創(chuàng)建和使用通常不是同一個人。這里有一個典型的應用場景：管理員創(chuàng)建一個PV池，開發(fā)人員創(chuàng)建Pod和PVC，PVC里定義了Pod所需存儲的大小和訪問模式，然后PVC會到PV池里自動匹配最合適的PV給Pod使用。

前面在介紹PV的生命周期時，提到PV的供給有兩種方式，靜態(tài)和動態(tài)。其中動態(tài)方式是通過StorageClass來完成的，這是一種新的存儲供應方式。


使用StorageClass有什么好處呢？除了由存儲系統(tǒng)動態(tài)創(chuàng)建，節(jié)省了管理員的時間，還有一個好處是可以封裝不同類型的存儲供PVC選用。在StorageClass出現(xiàn)以前，PVC綁定一個PV只能根據(jù)兩個條件，一個是存儲的大小，另一個是訪問模式。在StorageClass出現(xiàn)后，等于增加了一個綁定維度。


比如這里就有兩個StorageClass，它們都是用谷歌的存儲系統(tǒng)，但是一個使用的是普通磁盤，我們把這個StorageClass命名為slow。另一個使用的是SSD，我們把它命名為fast。

在PVC里除了常規(guī)的大小、訪問模式的要求外，還通過annotation指定了Storage
Class的名字為fast，這樣這個PVC就會綁定一個SSD，而不會綁定一個普通的磁盤。

到這里Kubernetes的整個存儲系統(tǒng)就都介紹完了?？偨Y一下，兩種存儲卷：普通Volume 和Persistent
Volume。普通Volume在定義Pod的時候直接定義，Persistent Volume通過Persistent Volume
Claim來動態(tài)綁定。PV可以手動創(chuàng)建,也可以通過StorageClass來動態(tài)創(chuàng)建。

下面重介紹Kubernetes與有狀態(tài)集群服務相關的兩個新特性：Init Container 和 Pet Set 。

什么是Init Container？

從名字來看就是做初始化工作的容器?？梢杂幸粋€或多個，如果有多個，這些 Init Container 按照定義的順序依次執(zhí)行，只有所有的Init
Container 執(zhí)行完后，主容器才啟動。由于一個Pod里的存儲卷是共享的，所以 Init Container 里產(chǎn)生的數(shù)據(jù)可以被主容器使用到。

Init Container可以在多種 K8S 資源里被使用到如 Deployment、Daemon Set, Pet Set,
Job等，但歸根結底都是在Pod啟動時，在主容器啟動前執(zhí)行，做初始化工作。

我們在什么地方會用到 Init Container呢？

第一種場景是等待其它模塊Ready，比如我們有一個應用里面有兩個容器化的服務，一個是Web Server，另一個是數(shù)據(jù)庫。其中Web
Server需要訪問數(shù)據(jù)庫。但是當我們啟動這個應用的時候，并不能保證數(shù)據(jù)庫服務先啟動起來，所以可能出現(xiàn)在一段時間內Web
Server有數(shù)據(jù)庫連接錯誤。為了解決這個問題，我們可以在運行Web Server服務的Pod里使用一個Init
Container，去檢查數(shù)據(jù)庫是否準備好，直到數(shù)據(jù)庫可以連接，Init Container才結束退出，然后Web
Server容器被啟動，發(fā)起正式的數(shù)據(jù)庫連接請求。

第二種場景是做初始化配置，比如集群里檢測所有已經(jīng)存在的成員節(jié)點，為主容器準備好集群的配置信息，這樣主容器起來后就能用這個配置信息加入集群。

還有其它使用場景，如將pod注冊到一個中央數(shù)據(jù)庫、下載應用依賴等。


這些東西能夠放到主容器里嗎？從技術上來說能，但從設計上來說，可能不是一個好的設計。首先不符合單一職責原則，其次這些操作是只執(zhí)行一次的，如果放到主容器里，還需要特殊的檢查來避免被執(zhí)行多次。

這是Init Container的一個使用樣例


這個例子創(chuàng)建一個Pod，這個Pod里跑的是一個nginx容器，Pod里有一個叫workdir的存儲卷，訪問nginx容器服務的時候，就會顯示這個存儲卷里的index.html
文件。

而這個index.html 文件是如何獲得的呢？是由一個Init Container從網(wǎng)絡上下載的。這個Init Container
使用一個busybox鏡像，起來后，執(zhí)行一條wget命令，獲取index.html文件，然后結束退出。

由于Init Container和nginx容器共享一個存儲卷（這里這個存儲卷的名字叫workdir），所以在Init
container里下載的index.html文件可以在nginx容器里被訪問到。

可以看到 Init Container 是在 annotation里定義的。Annotation
是K8S新特性的實驗場，通常一個新的Feature出來一般會先在Annotation 里指定，等成熟穩(wěn)定了，再給它一個正式的屬性名或資源對象名。

介紹完Init Container，千呼萬喚始出來，主角Pet Set該出場了。

什么是Pet Set？

在數(shù)據(jù)結構里Set是集合的意思，所以顧名思義Pet
Set就是Pet的集合，那什么是Pet呢？我們提到過Cattle和Pet的概念，Cattle代表無狀態(tài)服務，而Pet代表有狀態(tài)服務。具體在K8S資源對象里，Pet是一種需要特殊照顧的Pod。它有狀態(tài)、有身份、當然也比普通的Pod要復雜一些。

具體來說，一個Pet有三個特征。

一是有穩(wěn)定的存儲，這是通過我們前面介紹的PV/PVC 來實現(xiàn)的。

二是穩(wěn)定的網(wǎng)絡身份，這是通過一種叫 Headless Service 的特殊Service來實現(xiàn)的。要理解Headless
Service是如何工作的，需要先了解Service是如何工作。我們提到過Service可以為多個Pod實例提供一個穩(wěn)定的對外訪問接口。這個穩(wěn)定的接口是如何實現(xiàn)的的呢，是通過Cluster
IP來實現(xiàn)的，Cluster IP是一個虛擬IP，不是真正的IP，所以穩(wěn)定。K8S會在每個節(jié)點上創(chuàng)建一系列的IPTables規(guī)則，實現(xiàn)從Cluster
IP到實際Pod IP的轉發(fā)。同時還會監(jiān)控這些Pod的IP地址變化，如果變了，會更新IP Tables規(guī)則，使轉發(fā)路徑保持正確。所以即使Pod
IP有變化，外部照樣能通過Service的ClusterIP訪問到后面的Pod。

普通Service的Cluster IP 是對外的，用于外部訪問多個Pod實例。而Headless
Service的作用是對內的，用于為一個集群內部的每個成員提供一個唯一的DNS名字，這樣集群成員之間就能相互通信了。所以Headless
Service沒有Cluster IP，這是它和普通Service的區(qū)別。

Headless Service為每個集群成員創(chuàng)建的DNS名字是什么樣的呢？右下角是一個例子，第一個部分是每個Pet自己的名字，后面foo是Headless
Service的名字，default是PetSet所在命名空間的名字，cluser.local是K8S集群的域名。對于同一個Pet
Set里的每個Pet，除了Pet自己的名字，后面幾部分都是一樣的。所以要有一個穩(wěn)定且唯一的DNS名字，就要求每個Pet的名字是穩(wěn)定且唯一的。


三是序號命名規(guī)則。Pet是一種特殊的Pod，那么Pet能不能用Pod的命名規(guī)則呢？答案是不能，因為Pod的名字是不穩(wěn)定的。Pod的命名規(guī)則是，如果一個Pod是由一個RC創(chuàng)建的，那么Pod的名字是RC的名字加上一個隨機字符串。為什么要加一個隨機字符串，是因為RC里指定的是Pod的模版，為了實現(xiàn)高可用，通常會從這個模版里創(chuàng)建多個一模一樣的Pod實例，如果沒有這個隨機字符串，同一個RC創(chuàng)建的Pod之間就會由名字沖突。


如果說某個Pod由于某種原因死掉了，RC會新建一個來代替它，但是這個新建里的Pod名字里的隨機字符串與原來死掉的Pod是不一樣的。所以Pod的名字跟它的IP一樣是不穩(wěn)定的。

為了解決名字不穩(wěn)定的問題，K8S對Pet的名字不再使用隨機字符串，而是為每個Pet分配一個唯一不變的序號，比如 Pet Set 的名字叫
mysql，那么第一個啟起來的Pet就叫 mysql-0，第二個叫 mysql-1，如此下去。

當一個Pet down 掉后，新創(chuàng)建的Pet
會被賦予跟原來Pet一樣的名字。由于Pet名字不變所以DNS名字也跟以前一樣，同時通過名字還能匹配到原來Pet用到的存儲，實現(xiàn)狀態(tài)保存。

這些是Pet Set 相關的一些操作：

* Peer discovery，這和我們上面的Headless Service有密切關系。通過Pet Set的 Headless
Service，可以查到該Service下所有的Pet 的 DNS 名字。這樣就能發(fā)現(xiàn)一個Pet Set
里所有的Pet。當一個新的Pet起來后，就可以通過Peer Discovery來找到集群里已經(jīng)存在的所有節(jié)點的DNS名字，然后用它們來加入集群。
* 更新Replicas的數(shù)目、實現(xiàn)擴容和縮容。
* 更新Pet Set里Pet的鏡像版本，實現(xiàn)升級。
* 刪除 Pet Set。刪除一個Pet Set 會先把這個Pet Set的Replicas數(shù)目縮減為0，等到所有的Pet都被刪除了，再刪除 Pet
Set本身。注意Pet用到的存儲不會被自動刪除。這樣用戶可以把數(shù)據(jù)拷貝走了，再手動刪除。 本文轉自中文社區(qū)-
Kubernetes（k8s）有狀態(tài)集群服務部署與管理
<https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwww.kubernetes.org.cn%2F930.html>

• ? 上一篇：通俗易懂設計模式解析——外觀模式
• ? 下一篇：FreeSql （十九）多表查詢