聊聊Kubernetes有狀態應用管理
?我們在《Kubernetes工作負載管理》中主要介紹了無狀態應用的管理，當時也有提到有狀態應用，但是由于那時候還沒有解釋數據如何持久化就沒有做深度的介紹，而在這章，我們會著重介紹如何進行有狀態應用的管理。
什么是有狀態應用
實例之間的不等關系以及實例對外數據有依賴關系的應用，就被稱為"有狀態應用"。
所謂實例之間的不等關系即對分布式應用來說，各實例，各應用之間往往有比較大的依賴關系，比如某個應用必須先于其他應用啟動，否則其他應用將不能啟動等。
對外數據有依賴關系的應用，最顯著的就是數據庫應用，對于數據庫應用，我們是需要持久化保存其數據的，如果是無狀態應用，在數據庫重啟數據和應用就失去了聯系，這顯然是違背我們的初衷，不能投入生產的。
所以，為了解決Kubernetes中有狀態應用的有效支持，Kubernetes使用StatefulSet來編排管理有狀態應用。 StatefulSet類似于ReplicaSet，不同之處在于它可以控制Pod的啟動順序，它為每個Pod設置唯一的標識。其具有一下功能：
- 穩定的，唯一的網絡標識符
- 穩定的，持久化存儲
- 有序的，優雅部署和縮放
- 有序的，自動滾動更新
StatefulSet的設計很容易理解，它把現實世界抽象為以下兩種情況：（1）、拓撲狀態。這就意味著應用之間是不對等關系，應用要按某種順序啟動，即使應用重啟，也必須按其規定的順序重啟，并且重啟后其網絡標識必須和原來的一樣，這樣才能保證原訪問者能通過同樣的方法訪問新的Pod；（2）、存儲狀態 。這就意味著應用綁定了存儲數據，不論什么時候，不論什么情況，對應用來說，只要存儲里的數據沒有變化，讀取到的數據應該是同一份；
所以StatefulSet的核心功能就是以某種方式記錄Pod的狀態，然后在Pod被重新創建時，通過某種方法恢復其狀態。
如何使用StatefulSet
在《Kubernetes應用訪問管理》中，我們介紹了Service，它是為一組Pod提供外部訪問的一種方式。通常，我們使用 Service訪問Pod有一下兩種方式：（1）、通過Cluster IP，這個Clustre IP就相當于VIP，我們訪問這個IP，就會將請求轉發到后端Pod上；（2）、通過DNS方式，通過這種方式首先得確保Kubernetes集群中有DNS服務。這個時候我們只要訪問"my-service.my-namespace.svc,cluster.local"，就可以訪問到名為my-service的Service所代理的后端Pod；
而對于第二種方式，有下面兩種處理方法：（1）、Normal Service，即解析域名，得到的是Cluster IP，然后再按照方式一訪問；（2）、Headless Service，即解析域名，得到的是后端某個Pod的IP地址，這樣就可以直接訪問；
而在使用StatefulSet的時候，主要用到Headless Service，還記得Headless Service怎么定義的嗎？
我們只需要把ClusterIP設置為None即可，如下：
了解了Headless Service，還需要了解PV、PVC是怎么使用的，如果忘記了，可以移步《Kubernetes數據持久化管理》回顧，這里就不再贅述了。
下面，我們開始使用StatefulSet。
首先，我們創建兩個個PV，因為準備為有狀態應用創建兩個副本，如下：
然后編寫StatefulSet需要的YAML文件，如下：
注意上面的 YAML 文件中和volumeMounts進行關聯的是一個新的屬性：volumeClaimTemplates，該屬性會自動聲明一個 pvc 對象和 pv 進行管理，而serviceName: "nginx"表示在執行控制循環的時候，用nginx這個Headless Service來保存Pod的可解析身份。
創建完成后，可以看到會起兩個Pod：
從這兩個Pod的命令可以看到，它們的名字不像Deployment那樣隨機生成的字符串，而是0，1這樣的序號。這是因為StatefulSet要保證每個Pod順序，確保每次重啟或者更新，每個Pod依然保持以前的數據，不會錯亂。所以StatefulSet會以[statefulset-name]-[index]規則進行命名，其中index從0開始。而且每個Pod的創建是有順序的，如上只有web-0進入running狀態后，web-1才創建。
當兩個Pod都進入running狀態后，就可以查看其各自的網絡身份了，我們通過kubectl exec來查看，如下：
可以看到這兩個pod的hostname和pod的名字是一致的，都被分配為對應的編號，接下來我們用DNS的方式來訪問Headless Service。
我們先啟動一個調試Pod，如下：
然后進入dnsutils容器進行解析，如下：
從nslookup的結果分析，在訪問web-0.nginx的時候解析的是web-0這個Pod的IP，另一個亦然。這表示，如果我們在應用中配置web-0.nginx，則只會調用web-0這個Pod，在配置有狀態應用，比如Zookeeper的時候，我們需要在配置文件里指定zkServer，這時候就可以指定類似：zk-0.zookeeper，zk-1.zookeeper。
如果我們現在更新StatefuleSet，起更新順序是怎么樣的呢？
首先，我們新開一個終端，輸入以下命令用以觀察：
然后使用以下命令更新應用的鏡像，如下：
然后觀察web應用的更新順序，如下：
從整個順序可以看到，起更新是從后往前進行更新的，也就是先更新web-1的pod，再更新web-0的pod。通過這種嚴格的對應規則，StatefulSet就保證了Pod的網絡標識的穩定性，通過這個方法，就可以把Pod的拓撲狀態按照Pod的名字+編號的方式固定起來。此外，Kubernetes還為每一個Pod提供了一個固定并且唯一的訪問入口，即這個Pod的DNS記錄。
由此，我們對StatefulSet梳理如下：（1）、StatefulSet直接管理的是Pod。這是因為StatefulSet里的Pod實例不像ReplicaSet中的Pod實例完全一樣，它們是有細微的區別，比如每個Pod的名字、hostname等是不同的，而且StatefulSet區分這些實例的方式就是為Pod加上編號；（2）、Kubernetes通過Headless Service為這個編號的Pod在DNS服務器中生成帶同樣編號的記錄。只要StatefulSet能保證這個Pod的編號不變，那么Service中類似于web-0.nginx.default.svc.cluster.local這樣的DNS記錄就不會變，而這條記錄所解析的Pod IP地址會隨著Pod的重新創建自動更新；（3）、StatefulSet還可以為每個Pod分配并創建一個和Pod同樣編號的PVC。這樣Kubernetes就可以通過Persitent Volume機制為這個PVC綁定對應的PV，從而保證每一個Pod都擁有獨立的Volume。這種情況下即使Pod被刪除，它所對應的PVC和PV依然會保留下來，所以當這個Pod被重新創建出來過后，Kubernetes會為它找到同樣編號的PVC，掛載這個PVC對應的Volume，從而獲取到以前Volume以前的數據；
總結
StatefulSet這個控制器的主要作用之一，就是使用Pod模板創建Pod的時候，對它們進行編號，并且按照編號順序完成作業，當StatefulSet的控制循環發現Pod的實際狀態和期望狀態不一致的時候，也會按著順序對Pod進行操作。
當然 StatefulSet 還擁有其他特性，在實際的項目中，我們還是很少回去直接通過 StatefulSet 來部署我們的有狀態服務的，除非你自己能夠完全能夠 hold 住，對于一些特定的服務，我們可能會使用更加高級的 Operator 來部署，比如 etcd-operator、prometheus-operator 等等，這些應用都能夠很好的來管理有狀態的服務，而不是單純的使用一個 StatefulSet 來部署一個 Pod就行，因為對于有狀態的應用最重要的還是數據恢復、故障轉移等等。?
