Kubernetes Pod 冗餘策略

做者：Harry Martland

翻譯：Bach（才雲）

校對：星空下的文仔（才雲）、bot（才雲）

分佈式系統會不可避免地發生些故障，咱們須要計劃好如何解決，其中有種方法是運行多個服務實例，這樣即使有一個故障了，其餘的能夠繼續接管。在本文中，咱們將探討一些在 Kubernetes 上實現此目標的不一樣方法。

K8sMeetup

None

冗餘（Redundancy）是有代價的，咱們在考慮彈性時就應想到這一點。固然，若是客戶能夠忍受少許中斷，而且對他們的體驗沒有太大影響，那麼這點就無所謂了。

在討論服務運行時間（uptime）時，一般以幾個 9 來評價，例如運行時間爲 99.9％，這意味着每 1000 個請求中，只有一個失敗。根據以往經驗，咱們每增長九個服務，須要花費約十倍的成本。

只要應用程序不是常常崩潰，咱們就能夠運行一個 Pod 並依靠 K8s 從新運行，不過這須要一個 Pod 來處理服務接收的負載。

K8sMeetup

N

隨着服務開始須要更多的 Pod 來處理負載，咱們能夠對其進行擴展。若是流量是隨時間變化的（例如中午高峯），那咱們要有足夠的 Pod 在高峯時間處理負載。這種策略在 Pod 接收的流量會明顯減小時，才能提供較好的彈性。

若是某個 Pod 在高峯時段發生故障，那麼請求（request）將分佈到其他 Pod 上，這樣可能會超過它們的容量。不過在流量較小的話，其他 Pod 可能會有足夠的容量來承受負載。

在討論伸縮時，你們可能聽過一些術語，例如 in、out、up 和 down。一般，up 和 down 意味着保持相同數量的實例，但增長或減小 CPU 或 Server 的內存。In 和 out 是增長或刪除服務實例，但保持資源不變。明白這些後，咱們能夠進一步實現伸縮，但要注意會受到可以使用的最大 CPU 或內存限制。

K8sMeetup

N+1

與 N 同樣，咱們要了解須要多少 Pod 來處理高峯流量，此次添加了一個額外 Pod 來爲咱們提供保護，以防止高峯期間出現 Pod 故障的狀況。這種策略的彈性成本就是一個 Pod，這是額外的成本，並只在故障狀況下才須要。這就是爲何即使有一個 Pod 能夠處理全部流量，但咱們仍要有一個額外 Pod。

K8sMeetup

伸縮

與其手動計算高峯時段所需的 Pod 數量，不如讓 K8s 代爲完成。有了伸縮指標（scaling metric），K8s 能夠根據當前需求伸縮服務，在需求較低時縮小規模，在須要時擴大規模，這樣就下降了成本。雖然伸縮自己並不能使 Pod 從故障中恢復過來，可是能夠應對激增的需求。控制好 Pod 的內存和 CPU 可使咱們更精確地擴展規模並下降成本。

擴展服務須要留出必定的空間，最好不要將 Pod 用到極限。Pod 須要一些時間才能啓動，它會自動計算自動伸縮指標。應用程序須要可以處理請求擴展與實際擴展之間的請求。另外，若是有不少 Pod，那麼總的空閒空間會縮小，由於它分佈在全部 Pod 中。

K8sMeetup

75% 伸縮

知道自動伸縮以及什麼時候伸縮服務時，咱們就能夠控制所需的彈性。將服務容量伸縮到 75％ 時，咱們會損失 25％ 的 Pod，擁有的 Pod 越多，損失的也就越多，同時咱們還要爲未利用的 Pod 支付大量費用。即使是這樣，當咱們運行着大量的 Pod 時，依舊要考慮下降彈性百分比，由於可能會出現大量 Pod 發生故障的狀況。

若是服務的流量特別麻煩，這項策略就會特別有用。尖峯流量（spike）會對自動伸縮產生很大影響，由於它們出現的時間很短，以致於自動伸縮器沒有時間作出反應。若是咱們大體知道峯值是多少，那麼就能夠將其規劃到服務的伸縮中。

K8sMeetup

伸縮 + N

若是想精確地控制冗餘而不是某個百分比，那麼能夠選擇擴展容量，再增長 N 中的額外 Pod。這樣即使 N 的 Pod 故障，咱們仍然有足夠的容量，來精確控制冗餘 Pod。

K8s Service 使用標籤（labels）來決定路由哪些 Pod 的請求。這樣咱們可使用不一樣配置部署同一 Service 的兩個副本集，一個副本集使用水平 Pod 自動伸縮器，而另外一副本集配置爲具備 N 的 Pod。兩個副本集使用相同的標籤標記容器，而且 Service 將路由到該標籤。該 Service 在全部 Pod 中平均分配流量，從而容許在擴展服務的同時維護 N 的冗餘 Pod。

K8sMeetup

多集羣

咱們還能夠將應用程序部署到兩個 K8s 集羣中，這樣即使整個集羣出現故障，都還能繼續維護服務。負載均衡器在集羣前面，並在集羣之間路由流量。

運行多個集羣時，自動伸縮也更具挑戰性，由於伸縮指標一般不會在集羣之間共享。若是集羣發生了故障，仍在工做的集羣將在幾乎沒有通知的狀況下，接收來自故障集羣的全部流量。有多種方法能夠應對這種忽然增長的負載，自動伸縮功能能迅速地作出反應並處理流量。

根據所需的冗餘程度，集羣能夠以「主動-被動」模式（active-passive mode）運行，這意味着集羣能夠接收全部請求，但除非在集羣之間共享伸縮指標，不然在此設置中，服務必須從零開始擴展。

K8sMeetup

數量與冗餘

擁有的 Pod 越多，單個 Pod 的故障對其餘 Pod 的影響就越小。假設咱們有十個能夠服務 100rps 的 Pod，若是以 90rps 的比例伸縮而且有一個 Pod 故障，那麼其他 Pod 要接收 100rps，並達到容量極限；若是咱們有 20 個 Pod，其中有一個 Pod 故障，其他的 Pod 僅需處理 95rps。這兩種狀況都是假定服務能準確接收請求。實際上，服務一般會收到比這少的流量，若是擴大規模，收到的流量會稍多一些。

K8sMeetup

總結

自動伸縮是一個複雜的問題，有不少選擇須要咱們考慮。經過本文，但願你們對此有更好的瞭解，而且可使用它來減小云帳單成本，同時保持服務的正常運行。

原文連接：https://medium.com/better-pro...