作者：Stephen Thorn 翻譯：劉玲玲 原文：https://www.percona.com/blog/2020/10/08/the-criticality-of-a-kubernetes-operator-for-databases/ 一些剛接觸 Kubernetes 的公司嘗試使用傳統環 ...
作者：Stephen Thorn
翻譯：劉玲玲
原文：https://www.percona.com/blog/2020/10/08/the-criticality-of-a-kubernetes-operator-for-databases/
一些剛接觸 Kubernetes 的公司嘗試使用傳統環境中運行資料庫的方法在 Kubernetes 中運行資料庫。但是，不建議這樣做。因為這可能會導致數據丟失，並且也不建議這樣管理生產工作負載。為什麼這樣做很危險？又如何解決這個問題？
適合 Kubernetes 的工作負載
在考慮將資料庫遷移到 Kubernetes 之前，請確保應用程式的其餘部分是雲原生的，並可以使用 Kubernetes。如果您已經開始對資料庫進行垂直彈性伸縮和水平彈性伸縮，並需要編排資料庫來控製成本，將其遷移至 Kubernetes 上就是個不錯的選擇。
將資料庫工作負載轉移到 Kubernetes 上有兩個理想的使用場景：微服務和統一抽象層。
龐大的單一數據集可能會阻礙發揮 Kubernetes 的一些優點：自修複和高可用性。這可能是一個問題，因為在加入資料庫集群時，需要耗費時間將數據物理傳輸到新 Pod 實例上。如果數據集太大，由於物理限制，這個過程會很慢，並影響性能和資料庫的可用性。而微服務就非常合適，因為它的數據集相對較小，使得 Kubernetes 能很好地進行自動化處理。
希望充分利用雲原生應用程式和資料庫的公司也非常適合 Kubernetes。如果想利用統一抽象層在任何地方部署和運行資料庫，Kubernetes 是一個很好的選擇。可以將資料庫移動到任何運行著 Kubernetes 的地方。
我們對大型非分片數據集以及 Kubernetes 在處理這些數據集時的局限性進行了討論，但我們還應該看看什麼樣的工作負載更適合傳統平臺。對吞吐量比較敏感的應用程式在 Kubernetes 上表現可能沒有那麼好，或者不是很划算。Kubernetes 基本是為容器編排而設計的，而不是為需要極低延遲的高性能資料庫而設計的。也許這能夠實現，但代價是什麼呢？對於高性能的分散式資料庫也同樣如此。
如何看待 Pod？
Pets 和 Cattle 是 DevOps 中的一對概念。Pets 表示在出現問題時需要關註單個伺服器的部署方式，Cattle 表示在出現問題時用副本替換伺服器的能力。在 Kubernetes 的運作方式中，當出現應用程式無法控制的因素時，可以在任何時候銷毀、創建或移動 Pod。Kubernetes 使用一個調度程式（scheduler），它可以銷毀和重建 Pod，以滿足您的 Kubernetes 集群配置需求。
這對於無狀態應用程式非常有用，因為應用程式中的任何失敗都將導致包含應用程式的 Pod 被銷毀和重新創建，而不需要人工交互，並極大地加快了問題的解決。這對於資料庫來說並不理想，因為我們不希望資料庫突然停止工作，並造成數據丟失或損壞。Kubernetes 可以使用 StatefulSet 提供持久標識符來幫助解決這個問題。這有利於管理有狀態工作負載，但是要如何發揮高可用性和利用 Kubernetes 的自動化優勢呢？
如何看待資料庫？
從設計上講，資料庫需要保持其身份、信息，最重要的是，數據在任何時候都是安全和可訪問的。資料庫是應用程式的支柱，因為它們是應用程式正常運行所依賴的真實數據來源。資料庫操作中的任何錯誤都將迅速導致應用程式無法運行。簡單來說，資料庫很重要。
我們如何在 Kubernetes 中安全地運行資料庫，並確保資料庫部署是高可用的？
通過使用 StatefulSet 和持久捲（Persistent Volume），可以保持數據的完整性，但是我們還需要另外的工具來承擔資料庫管理任務，例如確保故障轉移、恢複數據庫成員、重新加入高可用架構以及其他特定技術功能。幸運的是，Kubernetes 是可擴展的，並且擁有 Operator，用於自動執行管理服務的關鍵任務。
自動化，自動化，自動化
我們瞭解了在 Kubernetes 中安全運行資料庫的複雜性，以及一些用來幫助彌合自動化和傳統人工在功能之間差距的概念。在一些資料庫 Operator 的幫助下，我們可以按照預期的方式安全地運行資料庫。這些 Operator 能夠將一些通常由資料庫管理員完成的任務自動化執行，例如：
- 自動部署，嚴格的一致性，無單點故障
- 自動伸縮，通過更改 size 參數添加或刪除集群或 ReplicaSet 成員
- 自動備份和恢復
- 自動修複，從單個集群或 ReplicaSet 成員的故障中自動恢復
- 自動管理密碼輪換系統用戶
- 簡化更新
總結
由於運行資料庫環境的複雜性和對高可用的要求，以及動態 Kubernetes 環境帶來的風險，強烈建議在 Kubernetes 中部署資料庫時，使用 Operator 來實現。
歡迎使用 RadonDB MySQL Kubernetes 一款高可用 MySQL 集群 Operator！
