了解 Kubernetes 中的狀態管理
在一般情況下談論應用程式時，您可能會經常聽到 應用程式狀態。 在此單元中，我們會檢閱狀態的定義和不同類型的狀態，讓您可以更妥善地準備應用程式來處理它們。
州/省
應用程式狀態是應用程式執行時，儲存在記憶體中的所有內容。 狀態可能涉及各種專案，但我們大多著重於用戶數據。
為了提供應用程式狀態的範例，請假設您開啟了音樂播放機。 此應用程式具有狀態。 應用程式知道您的身分、想要收聽的內容，以及所下載的音樂。 這項資訊都是應用程式狀態的一部分。
記憶體內部狀態即能提供這種資訊，因此應用程式不需要再從其他任何位置尋找。 磁碟狀態包含應用程式無法立即取得的資訊，因此需要從另一個資料來源取得。
狀態類型
有兩種類型的應用程式狀態。 第一種類型是 暫時狀態，一旦應用程式關閉，就不會持續且消失。
容器具有暫時性狀態。 刪除容器時，儲存在其中的所有數據都會立即遺失。 有些應用程式可單獨使用容器，因為這些應用程式可從其他來源重新產生狀態，而不需要將狀態儲存在本機。 這些應用程式稱為「stateless (無狀態) 應用程式」。
所有非暫時狀態的其餘狀態都稱為 持續性狀態。 容器生命週期之後，持續性狀態會持續存在。 我們使用的大部分容器技術都有磁碟區的概念，也就是狀態所在的磁碟內位置。 即使您移除容器，再將其重新開啟，狀態仍然會儲存在安全的位置，並可以再次使用。
依賴擷取外部狀態的應用程式則稱為「stateful (具狀態) 應用程式」。
狀態與 Kubernetes
Kubernetes 可以處理無狀態和具狀態應用程式。 無狀態應用程式更容易，因為我們只能專注於應用程式本身，而不是其狀態（因為它不存在）。
對大部分無狀態應用程式來說，具有 Pod 的簡單部署工作負載足以讓您擁有完全正常運作的系統，並可充分運用叢集。
處理具狀態應用程式則相反。 在這些情況下，您必須考慮應用程式及其狀態、儲存狀態的位置，以及如何安全地儲存狀態。
這就是為什麼 Kubernetes 還包含 PersistentVolumes (PV) 和 PersistentVolumeClaims (PVC) 概念的原因。
提示
本課程模組不會進一步討論記憶體概念，但您可以在摘要中參考 Azure Kubernetes Service 資源以深入瞭解。
PersistentVolumes 是配置於節點中的磁碟，用來儲存來自 Pod 容器的狀態。 因為 Kubernetes 最適合用於分散式應用程式，所以所有已建立磁碟區都位於「可用磁碟區」的集區中。 容器接著會自行宣告該空間。 您可使用 Pod 將 PersistentVolumeClaims 與 PersistentVolume 繫結，並使用其空間來儲存所需資料。
所有資料庫提供者都是具狀態應用程式。 如果您要在叢集中部署資料庫提供者，則需要 PV 和 PV，才能將資料庫資料儲存在安全的位置，並允許提供者擷取該數據，即使其容器已刪除也一樣。
狀態處理的最佳做法
狀態存在於大部分應用程式中。 不過，處理狀態的最佳做法就是完全不進行處理。
您可設計任何有效率的應用程式，目標是使其具有高可用性和可調整性。 狀態的發展方向則相反。 儘管記憶體提供者所提供的選項以及部署和使用方便，但狀態不會輕易調整。 且其可用性也不高。
高可用性狀態
應用程式必須隨時為上線狀態，才能視為高可用性。 高可用性是透過區域與地區複寫來實現。 Kubernetes 在其大部分的工作負載中，都會判別區域。 這表示可將多個應用程式的執行個體部署在不同區域中。 然而，磁碟並不會判別區域。
當您在 Kubernetes 上部署新的 PersistentVolume 物件時，它會系結至節點上的磁碟。 該磁碟也會繫結到特定地區中的特定區域。 搭配 PV 使用區域或區域複寫很複雜，而且需要大量維護，才能復寫和同步處理數據。
高度可調整狀態
若要具有高度擴充性，應用程式應將其輸送量與與其連線的用戶數目一起成長。 這對於狀態管理而言很複雜，因為任何外部狀態基本上都是磁碟，而磁碟的輸入與輸出速率相當有限。 輸送量管理可協助解決此問題。
資料庫解決方案提出了的概念 ReplicaSets，它會將整個資料庫複寫到多個實例。 復寫會增加狀態的磁碟 數目和 I/O。
每次資料庫變更時，都必須同步狀態，這讓所有磁碟能夠包含相同的資料。 這種同步處理也同樣很複雜。
將狀態外部化
Azure 具有平臺即服務 （PaaS） 解決方案，例如 Azure Cosmos DB，其高度可用且可調整，併為您解決大部分的狀態管理問題。
將狀態儲存在外部並移除維護的需求，可有助專注於應用程式，並降低在基礎結構中處理資料完整性的額外負荷。