摘要：千呼萬喚始出來，有狀態集群服務部署與管理下將著重介紹與有狀態集群服務相關的兩個新特性和。把這些特性和有狀態集群服務關聯起來串一下，我們可以用來管理一個有狀態服務集群，里每個對應集群的一個成員，集群的初始化可以用來完成。

千呼萬喚始出來，《Kubernetes有狀態集群服務部署與管理（下）》將著重介紹Kubernetes與有狀態集群服務相關的兩個新特性：Init Container 和 Pet Set 。

Tips: 關注公眾號：tenxcloud2（時速云訂閱號）,回復 "1206"即可下載現場PPT。

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

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

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

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

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

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

這是Init Container的一個使用樣例

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

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

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

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

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

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

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

一是有穩定的存儲，這是通過我們前面介紹的PV/PVC 來實現的。

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

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

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

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

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

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

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

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

Peer discovery，這和我們上面的Headless Service有密切關系。通過Pet Set的 Headless Service，可以查到該Service下所有的Pet 的 DNS 名字。這樣就能發現一個Pet Set 里所有的Pet。當一個新的Pet起來后，就可以通過Peer Discovery來找到集群里已經存在的所有節點的DNS名字，然后用它們來加入集群。

更新Replicas的數目、實現擴容和縮容。

更新Pet Set里Pet的鏡像版本，實現升級。

刪除 Pet Set。刪除一個Pet Set 會先把這個Pet Set的Replicas數目縮減為0，等到所有的Pet都被刪除了，再刪除 Pet Set本身。注意Pet用到的存儲不會被自動刪除。這樣用戶可以把數據拷貝走了，再手動刪除。

以上，與有狀態服集群服務相關的K8S特性就介紹完了。

把這些特性和有狀態集群服務關聯起來串一下，我們可以用Pet Set來管理一個有狀態服務集群，Pet Set里每個Pet對應集群的一個成員，集群的初始化可以用 Init Container來完成。集群里每個成員的狀態由Volume, Persistent Volume來存儲，集群里每個Pet 唯一的DNS名字通過Headless Service來提供，集群里的成員之間就可以通過這個名字，相互通信。