這篇文章給大家介紹如何理解StatefulSet中應(yīng)用編排工具Deployment，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供龍華網(wǎng)站建設(shè)、龍華做網(wǎng)站、龍華網(wǎng)站設(shè)計、龍華網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、龍華企業(yè)網(wǎng)站模板建站服務(wù)，10余年龍華做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
我們之前講到過 Deployment 作為一個應(yīng)用編排管理工具，它為我們提供了哪些功能？
如下圖所示：
首先它支持定義一組 Pod 的期望數(shù)量，Controller 會為我們維持 Pod 的數(shù)量在期望的版本以及期望的數(shù)量；
第二它支持配置 Pod 發(fā)布方式，配置完成后 Controller 會按照我們給出的策略來更新 Pod，同時在更新的過程中，也會保證不可用 Pod 數(shù)量在我們定義的范圍內(nèi)；
第三，如果我們在發(fā)布的過程中遇到問題，Deployment 也支持一鍵來回滾。
可以簡單地說，Deployment 認(rèn)為：它管理的所有相同版本的 Pod 都是一模一樣的副本。也就是說，在 Deployment Controller 看來，所有相同版本的 Pod，不管是里面部署的應(yīng)用還是行為，都是完全相同的。
這樣一種能力對于無狀態(tài)應(yīng)用是支持滿足的，如果我們遇到一些有狀態(tài)應(yīng)用呢？
比如下圖所示的一些需求：
以上的這些需求都是 Deployment 無法滿足的，因此 Kubernetes 社區(qū)為我們提供了一個叫 StatefluSet 的資源，用來管理有狀態(tài)應(yīng)用。
其實現(xiàn)在社區(qū)很多無狀態(tài)應(yīng)用也通過 StatefulSet 來管理，通過本文的學(xué)習(xí)，大家也會明白為什么我們將部分無狀態(tài)應(yīng)用也通過 StatefulSet 來管理。
如上圖右側(cè)所示，StatefulSet 中的 Pod 都是有序號的，從 0 開始一直到定義的 replica 數(shù)量減一。每個 Pod 都有獨立的網(wǎng)絡(luò)標(biāo)識：一個 hostname、一塊獨立的 pvc 以及 pv 存儲。這樣的話，同一個 StatefulSet 下不同的 Pod，有不同的網(wǎng)絡(luò)標(biāo)識、有自己獨享的存儲盤，這就能很好地滿足了絕大部分有狀態(tài)應(yīng)用的需求。
如上圖右側(cè)所示：
首先，每個 Pod 會有 Order 序號，會按照序號來創(chuàng)建，刪除和更新 Pod；
其次，通過配置一個 headless Service，使每個 Pod 有一個唯一的網(wǎng)絡(luò)標(biāo)識 (hostname)；
第三，通過配置 pvc 模板，就是 pvc template，使每個 Pod 有一塊或者多塊 pv 存儲盤；
最后，支持一定數(shù)量的灰度發(fā)布。比如現(xiàn)在有三個副本的 StatefulSet，我們可以指定只升級其中的一個或者兩個，更甚至是三個到新版本。通過這樣的方式，來達(dá)到灰度升級的目的。
上圖左側(cè)是一個 Service 的配置，我們通過配置 headless Service，其實想要達(dá)到的目標(biāo)是：期望 StatefulSet 里面的 Pod 有獨立的網(wǎng)絡(luò)標(biāo)識。這里的 Service name 叫 nginx。
上圖右側(cè)是一個 StatefulSet 的配置，在 spec 中有個 serviceName 也叫 nginx。通過這個 serviceName 來指定這個 StatefulSet 要對應(yīng)哪一個 Service。
這個 spec 中還有其它幾個很熟悉的字段，比如 selector 和 template。selector 是一個標(biāo)簽選擇器，selector 定義的標(biāo)簽選擇邏輯，必須匹配 template 中 metadata 中 labels 包含 app: nginx。在 template 中定義一個 nginx container，這個 container 用的 image 版本是 alpine 版本，對外暴露的 80 端口作為一個 web 服務(wù)。
最后，template.spec 里面定義了一個 volumeMounts，這個 volumeMounts 并不是來源于 spec 中的一個 Volumes，而是來自于 volumeClaimTemplates，也就是 pvc 模板。我們在 pvc 模板中定義了一個叫 www-storage 的 pvc 名稱。這個 pvc 名稱，我們也會寫到 volumeMounts 作為一個 volume name，掛載到 /usr/share/nginx/html 這個目錄下。通過這樣的方式來達(dá)到每個 Pod 都有獨立的一個 pvc，并且掛載到容器中對應(yīng)目錄的一個需求。
通過將上文中的兩個對象創(chuàng)建之后，我們可以通過 get 命令可以看到 Service nginx 資源已經(jīng)創(chuàng)建成功。
同時可以通過查看 endpoints 看到，這個后端已經(jīng)注冊了三個 IP 和端口，這三個 IP 對應(yīng)了 Pod 的 IP，端口對應(yīng)了之前 spec 中配置的 80 端口。
最后通過 get sts (StatefulSet 縮寫) nginx-web。從結(jié)果可以看到有一列叫做 READY，值為 3/3。分母 3 是 StatefulSet 中期望的數(shù)量，而分子 3 表示 Pod 已經(jīng)達(dá)到期望 READY 的狀態(tài)數(shù)量。
下圖中的 get pod 可以看到三個 Pod 的狀態(tài)都是 Running 狀態(tài)，并且已經(jīng) READY。它的 IP 就是前面看到的 endpoint 地址。
通過 get pvc 可以看到 NAME 那一列名稱，前綴為 www-storage，中間是 nginx-web，后綴是一個序號。通過分析可以知道 www-storage 是 volumeClaimTemplates 中定義的 name，中間為 StatefulSet 定義的 name，末尾的序號對應(yīng)著 Pod 的序號，也就是三個 PVC 分別被三個 Pod 綁定。通過這樣一種方式，達(dá)到不同的 Pod 享有不同的 PVC；PVC 也會綁定相應(yīng)的一個 PV， 來達(dá)到不同的 Pod 綁定不同 PV 的目的。
之前我們學(xué)到 Deployment 使用 ReplicaSet 來管理 Pod 的版本和所期望的 Pod 數(shù)量，但是在 StatefulSet 中，是由 StatefulSet Controller 來管理下屬的 Pod，因此 StatefulSet 通過 Pod 的 label 來標(biāo)識這個 Pod 所屬的版本，這里叫 controller-revision-hash。這個 label 標(biāo)識和 Deployment 以及 StatefulSet 在 Pod 中注入的 Pod template hash 是類似的。
如上圖所示，通過 get pod 查看到 controller-revision-hash，這里的 hash 就是第一次創(chuàng)建 Pod 對應(yīng)的 template 版本，可以看到后綴是 677759c9b8。這里先記錄一下，接下來會做 Pod 升級，再來看一下 controller-revision-hash 會不會發(fā)生改變。
通過執(zhí)行上圖的命令，可以看到上圖下方的 StatefulSet 配置中，已經(jīng)把 StatefulSet 中的 image 更新到了 mainline 新版本。
通過 get pod 命令查詢 Revision hash，可以看到三個 Pod 后面的 controller-revision-hash 都已經(jīng)升級到了新的 Revision hash，后面變成了 7c55499668。通過這三個 Pod 創(chuàng)建的時間可以發(fā)現(xiàn)：序號為 2 的 Pod 創(chuàng)建的是最早的，之后是序號是 1 和 0。這表示在升級的過程中，真實的升級順序為 2-1-0，通過這么一個倒序的順序來逐漸把 Pod 升級為新版本，并且我們升級的 Pod，還復(fù)用了之前 Pod 使用的 PVC。所以之前在 PV 存儲盤中的數(shù)據(jù)，仍然會掛載到新的 Pod 上。
上圖右上方是在 StatefulSet 的 status 中看到的數(shù)據(jù)，這里有幾個重要的字段：
currentReplica：表示當(dāng)前版本的數(shù)量
currentRevision：表示當(dāng)前版本號
updateReplicas：表示新版本的數(shù)量
updateRevision：表示當(dāng)前要更新的版本號
當(dāng)然這里也能看到 currentReplica 和 updateReplica，以及 currentRevision 和 updateRevision 都是一樣的，這就表示所有 Pod 已經(jīng)升級到了所需要的版本。
首先這里已經(jīng)連接到了阿里云的一個集群，集群中有三個節(jié)點。
現(xiàn)在開始創(chuàng)建一個 StatefulSet 和對應(yīng)的 Service，首先看一下對應(yīng)的編排文件。
如上圖中的例子所示，Service 對應(yīng)的 nginx 對外暴露的 80 端口。StatefulSet 配置中 metadata 定義了 name 為 nginx-web；template 中的 containers 定義了鏡像信息；最后定義了一個 volumeClaimTemplates 作為 PVC 模板。
執(zhí)行上面的命令后，我們就把 Service 和 StatefulSet 創(chuàng)建成功了。通過 get pod 可以看到首先創(chuàng)建的 Pod 序號為 0；通過 get pvc 可以看到序號為 0 的 PVC 已經(jīng)和 PV 進(jìn)行了綁定。
此時序號為 0 的 Pod 已經(jīng)開始創(chuàng)建了，狀態(tài)為 ContainerCreating。
當(dāng)序號為 0 的 Pod 創(chuàng)建完成后，開始創(chuàng)建序號為 1 的 Pod，然后看到新的 PVC 也已經(jīng)創(chuàng)建成功，緊接著是序號為 2 的 Pod。
可以看到每一個 Pod 創(chuàng)建之前，會先創(chuàng)建 PVC。PVC 創(chuàng)建完成后，Pod 從 Pending 狀態(tài)和 PV 進(jìn)行綁定，然后變成了 ContainerCreating，最后達(dá)到 Running。
然后通過 kubectl get sts nginx-web -o yaml 查看 StatefulSet 的狀態(tài)。
如上圖所示，期望的 replicas 數(shù)量為 3 個，當(dāng)前可用數(shù)量為 3 個，并且達(dá)到最新的版本。
接著來看一下 Service 和 endpoints，可以看到 Service 的 Port 為 80，endpoint 有三個對應(yīng)的 IP 地址。
再來 get pod ，可以看到三個 Pod 對應(yīng)了上面的 endpoints 的 IP 地址。
以上的操作結(jié)果為：三個 PVC 和三個 Pod 已經(jīng)達(dá)到了所期望的狀態(tài)，并且 StatefulSet 上報的 status 中，replicas 以及 currentReplicas 都為三個。
這里重復(fù)說一下，kubectl set image 為聲明鏡像的固定寫法；StatefulSet 表示自愿類型；nginx-web是資源名稱；nginx=nginx:mainline，等號前面的 nginx 是我們在 template 中定義的 container 名稱，后面的nginx:mainline是所期望更新的鏡像版本。
通過上面的命令，已經(jīng)成功的將 StatefulSet 中的鏡像更新為新的版本。
通過 get pod 看一下狀態(tài)，nginx-web-1,nginx-web-2 已經(jīng)進(jìn)入了 Running 狀態(tài)。對應(yīng)的 controller-revision-hash 已經(jīng)是新的版本。那么 nginx-web-0 這個 Pod，舊的 Pod 已經(jīng)被刪除了，新 Pod 還在 Createing 狀態(tài)。
再次查看一下狀態(tài)，所有的 Pod 都已經(jīng) Running 狀態(tài)了。
查看一下 StatefulSet 信息，目前 StatefulSet 中的 status 里定義的 currentRevision 已經(jīng)更新到了新的版本，表示 StatefulSet 已經(jīng)獲取到的三個 Pod 都已經(jīng)進(jìn)入了新版本。
如何查看這三個 Pod 是否還復(fù)用了之前的網(wǎng)絡(luò)標(biāo)識和存儲盤呢？
其實 headless Service 配置的 hostname 只是和 Pod name 掛鉤的，所以只要升級后的 Pod 名稱和舊的 Pod 名稱相同，那么就可以沿用之前 Pod 使用的網(wǎng)絡(luò)標(biāo)識。
關(guān)于存儲盤，由上圖可以看到 PVC 的狀態(tài)，它們的創(chuàng)建時間一直沒有改變，還是第一次創(chuàng)建 Pod 時的時間，所以現(xiàn)在升級后的 Pod 使用的還是舊 Pod 中使用的 PVC。
比如可以查看其中的某一個 Pod，這個 Pod 里面同樣有個聲明的 volumes，這個 persistentVolumeClaim 里的名稱 www-storage-nginx-web-0，對應(yīng)著 PVC 列表中看到的序號為 0 的 PVC，之前是被舊的 Pod 所使用。升級過程中 Controller 刪除舊 Pod，并且創(chuàng)建了一個同名的新 Pod，新的 Pod 仍然復(fù)用了舊 Pod 所使用的 PVC。
通過這種方式來達(dá)到升級前后，網(wǎng)絡(luò)存儲都能復(fù)用的目的。
StatefulSet 可能會創(chuàng)建三種類型的資源。
第一種資源：ControllerRevision
通過這個資源，StatefulSet 可以很方便地管理不同版本的 template 模板。
舉個例子：比如上文中提到的 nginx，在創(chuàng)建之初擁有的第一個 template 版本，會創(chuàng)建一個對應(yīng)的 ControllerRevision。而當(dāng)修改了 image 版本之后，StatefulSet Controller 會創(chuàng)建一個新的 ControllerRevision，大家可以理解為每一個 ControllerRevision 對應(yīng)了每一個版本的 Template，也對應(yīng)了每一個版本的 ControllerRevision hash。其實在 Pod label 中定義的 ControllerRevision hash，就是 ControllerRevision 的名字。通過這個資源 StatefulSet Controller 來管理不同版本的 template 資源。
第二個資源：PVC
如果在 StatefulSet 中定義了 volumeClaimTemplates，StatefulSet 會在創(chuàng)建 Pod 之前，先根據(jù)這個模板創(chuàng)建 PVC，并把 PVC 加到 Pod volume 中。
如果用戶在 spec 的 pvc 模板中定義了 volumeClaimTemplates，StatefulSet 在創(chuàng)建 Pod 之前，根據(jù)模板創(chuàng)建 PVC，并加到 Pod 對應(yīng)的 volume 中。當(dāng)然也可以在 spec 中不定義 pvc template，那么所創(chuàng)建出來的 Pod 就不會掛載單獨的一個 pv。
第三個資源：Pod
StatefulSet 按照順序創(chuàng)建、刪除、更新 Pod，每個 Pod 有唯一的序號。
如上圖所示，StatefulSet Controller 是 Owned 三個資源：ControllerRevision、Pod、PVC。
這里不同的地方在于，當(dāng)前版本的 StatefulSet 只會在 ControllerRevision 和 Pod 中添加 OwnerReference，而不會在 PVC 中添加 OwnerReference。之前的系列文章中提到過，擁有 OwnerReference 的資源，在管理的這個資源進(jìn)行刪除的默認(rèn)情況下，會關(guān)聯(lián)級聯(lián)刪除下屬資源。因此默認(rèn)情況下刪除 StatefulSet 之后，StatefulSet 創(chuàng)建的 ControllerRevision 和 Pod 都會被刪除，但是 PVC 因為沒有寫入 OwnerReference，PVC 并不會被級聯(lián)刪除。
上圖為 StatefulSet 控制器的工作流程，下面來簡單介紹一下整個工作處理流程。
首先通過注冊 Informer 的 Event Handler(事件處理)，來處理 StatefulSet 和 Pod 的變化。在 Controller 邏輯中，每一次收到 StatefulSet 或者是 Pod 的變化，都會找到對應(yīng)的 StatefulSet 放到隊列。緊接著從隊列取出來處理后，先做的操作是 Update Revision，也就是先查看當(dāng)前拿到的 StatefulSet 中的 template，有沒有對應(yīng)的 ControllerRevision。如果沒有，說明 template 已經(jīng)更新過，Controller 就會創(chuàng)建一個新版本的 Revision，也就有了一個新的 ControllerRevision hash 版本號。
然后 Controller 會把所有版本號拿出來，并且按照序號整理一遍。這個整理的過程中，如果發(fā)現(xiàn)有缺少的 Pod，它就會按照序號去創(chuàng)建，如果發(fā)現(xiàn)有多余的 Pod，就會按照序號去刪除。當(dāng)保證了 Pod 數(shù)量和 Pod 序號滿足 Replica 數(shù)量之后，Controller 會去查看是否需要更新 Pod。也就是說這兩步的區(qū)別在于，Manger pods in order 去查看所有的 Pod 是否滿足序號；而后者 Update in order 查看 Pod 期望的版本是否符合要求，并且通過序號來更新。
Update in order 其更新過程如上圖所示，其實這個過程比較簡單，就是刪除 Pod。刪除 Pod 之后，其實是在下一次觸發(fā)事件，Controller 拿到這個 success 之后會發(fā)現(xiàn)缺少 Pod，然后再從前一個步驟 Manger pod in order 中把新的 Pod 創(chuàng)建出來。在這之后 Controller 會做一次 Update status，也就是之前通過命令行看到的 status 信息。
通過整個這樣的一個流程，StatefulSet 達(dá)到了管理有狀態(tài)應(yīng)用的能力。
假設(shè) StatefulSet 初始配置 replicas 為 1，有一個 Pod0。那么將 replicas 從 1 修改到 3 之后，其實我們是先創(chuàng)建 Pod1，默認(rèn)情況是等待 Pod1 狀態(tài) READY 之后，再創(chuàng)建 Pod2。
通過上圖可以看到每個 StatefulSet 下面的 Pod 都是從序號 0 開始創(chuàng)建的。因此一個 replicas 為 N 的 StatefulSet，它創(chuàng)建出來的 Pod 序號為 [0,N)，0 是開曲線，N 是閉曲線，也就是當(dāng) N>0 的時候，序號為 0 到 N-1。
可能有的同學(xué)會有疑問：如果我不想按照序號創(chuàng)建和刪除，那 StatefulSet 也支持其它的創(chuàng)建和刪除的邏輯，這也就是為什么社區(qū)有些人把無狀態(tài)應(yīng)用也通過 StatefulSet 來管理。它的好處是它能擁有唯一的網(wǎng)絡(luò)標(biāo)識以及網(wǎng)絡(luò)存儲，同時也能通過并發(fā)的方式進(jìn)行擴縮容。
StatefulSet.spec 中有個字段叫 podMangementPolicy 字段，這個字段的可選策略為 OrderedReady 和 Parallel，默認(rèn)情況下為前者。
如我們剛才創(chuàng)建的例子，沒有在 spec 中定義 podMangementPolicy。那么 Controller 默認(rèn) OrderedReady 作為策略，然后在 OrderedReady 情況下，擴縮容就嚴(yán)格按照 Order 順序來執(zhí)行，必須要等前面的 Pod 狀態(tài)為 Ready 之后，才能擴容下一個 Pod。在縮容的時候，倒序刪除，序號從大到小進(jìn)行刪除。
舉個例子，上圖右側(cè)中，從 Pod0 擴容到 Pod0、Pod1、Pod2 的時候，必須先創(chuàng)建 Pod1，等 Pod1 Ready 之后再創(chuàng)建 Pod2。其實還存在一種可能性：比如在創(chuàng)建 Pod1 的時候，Pod0 因為某些原因，可能是宿主機的原因或者是應(yīng)用本身的原因，Pod0 變成 NotReady 狀態(tài)。這時 Controller 也不會創(chuàng)建 Pod2，所以不只是我們所創(chuàng)建 Pod 的前一個 Pod 要 Ready，而是前面所有的 Pod 都要 Ready 之后，才會創(chuàng)建下一個 Pod。上圖中的例子，如果要創(chuàng)建 Pod2，那么 Pod0、Pod1 都要 ready。
另一種策略叫做 Parallel，顧名思義就是并行擴縮容，不需要等前面的 Pod 都 Ready 或者刪除后再處理下一個。
假設(shè)這里的 StatefulSet template1 對應(yīng)邏輯上的 Revision1，這時 StatefulSet 下面的三個 Pod 都屬于 Revision1 版本。在我們修改了 template，比如修改了鏡像之后，Controller 是通過倒序的方式逐一升級 Pod。上圖中可以看到 Controller 先創(chuàng)建了一個 Revision2，對應(yīng)的就是創(chuàng)建了 ControllerRevision2 這么一個資源，并且將 ControllerRevision2 這個資源的 name 作為一個新的 Revision hash。在把 Pod2 升級為新版本后，逐一刪除 Pod0、Pod1，再去創(chuàng)建 Pod0、Pod1。
它的邏輯其實很簡單，在升級過程中 Controller 會把序號最大并且符合條件的 Pod 刪除掉，那么刪除之后在下一次 Controller 在做 reconcile 的時候，它會發(fā)現(xiàn)缺少這個序號的 Pod，然后再按照新版本把 Pod 創(chuàng)建出來。
首先來看一下 spec 中前幾個字段，Replica 和 Selector 都是我們比較熟悉的字段。
Replica 主要是期望的數(shù)量；
Selector 是事件選擇器，必須匹配 spec.template.metadata.labels 中定義的條件；
Template：Pod 模板，定義了所要創(chuàng)建的 Pod 的基礎(chǔ)信息模板；
VolumeClaimTemplates：PVC 模板列表，如果在 spec 中定義了這個，PVC 會先于 Pod 模板 Template 進(jìn)行創(chuàng)建。在 PVC 創(chuàng)建完成后，把創(chuàng)建出來的 PVC name 作為一個 volume 注入到根據(jù) Template 創(chuàng)建出來的 Pod 中。
ServiceName：對應(yīng) Headless Service 的名字。當(dāng)然如果有人不需要這個功能的時候，會給 Service 定一個不存在的 value，Controller 也不會去做校驗，所以可以寫一個 fake 的 ServiceName。但是這里推薦每一個 Service 都要配置一個 Headless Service，不管 StatefulSet 下面的 Pod 是否需要網(wǎng)絡(luò)標(biāo)識；
PodMangementPolicy：Pod 管理策略。前面提到過這個字段的可選策略為 OrderedReady 和 Parallel，默認(rèn)情況下為前者；
UpdataStrategy：Pod 升級策略。這是一個結(jié)構(gòu)體，下面再詳細(xì)介紹；
RevisionHistoryLimit：保留歷史 ControllerRevision 的數(shù)量限制(默認(rèn)為 10)。需要注意的一點是，這里清楚的版本，必須沒有相關(guān)的 Pod 對應(yīng)這些版本，如果有 Pod 還在這個版本中，這個 ControllerRevision 是不能被刪除的。
在上圖右側(cè)可以看到 StatefulSetUpdateStrategy 有個 type 字段，這個 type 定義了兩個類型：一個是 RollingUpdate；一個是OnDelete。
RollingUpdate 其實跟 Deployment 中的升級是有點類似的，就是根據(jù)滾動升級的方式來升級；
OnDelete 是在刪除的時候升級，叫做禁止主動升級，Controller 并不會把存活的 Pod 做主動升級，而是通過 OnDelete 的方式。比如說當(dāng)前有三個舊版本的 Pod，但是升級策略是 OnDelete，所以當(dāng)更新 spec 中鏡像的時候，Controller 并不會把三個 Pod 逐一升級為新版本，而是當(dāng)我們縮小 Replica 的時候，Controller 會先把 Pod 刪除掉，當(dāng)我們下一次再進(jìn)行擴容的時候，Controller 才會擴容出來新版本的 Pod。
在 RollingUpdateStatefulSetSetStrategy 中，可以看到有個字段叫 Partition。這個 Partition 表示滾動升級時，保留舊版本 Pod 的數(shù)量。很多剛結(jié)束 StatefulSet 的同學(xué)可能會認(rèn)為這個是灰度新版本的數(shù)量，這是錯誤的。
舉個例子：假設(shè)當(dāng)前有個 replicas 為 10 的 StatefulSet，當(dāng)我們更新版本的時候，如果 Partition 是 8，并不是表示要把 8 個 Pod 更新為新版本，而是表示需要保留 8 個 Pod 為舊版本，只更新 2 個新版本作為灰度。當(dāng) Replica 為 10 的時候，下面的 Pod 序號為 [0,9)，因此當(dāng)我們配置 Partition 為 8 的時候，其實還是保留 [0,7) 這 8個 Pod 為舊版本，只有 [8,9) 進(jìn)入新版本。
總結(jié)一下，假設(shè) replicas=N，Partition=M (M < N) ，則最終舊版本 Pod 為 [0，M) ,新版本 Pod 為 [M,N)。通過這樣一個 Partition 的方式來達(dá)到灰度升級的目的，這是目前 Deployment 所不支持的。
StatefulSet 是 Kubernetes 中常見的一種 Workload，其初始目標(biāo)是面向有狀態(tài)應(yīng)用部署，但也支持部署無狀態(tài)應(yīng)用；
與 Deployment 不同，StatefulSet 是直接操作 Pod 來做擴縮容/發(fā)布，并沒有通過類似 ReplicaSet 的其他 workload 來管控；
StatefulSet 的特點是：支持每個 Pod 獨享 PVC、有一個唯一網(wǎng)絡(luò)標(biāo)識，且在升級發(fā)布后還能復(fù)用 PVC 和網(wǎng)絡(luò)標(biāo)識；
關(guān)于如何理解StatefulSet中應(yīng)用編排工具Deployment就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
