本頁說明在 GKE 容器中執行資料庫的最佳做法。您可以使用 Deployment 建立一組由 Kubernetes 管理的容器化資料庫執行個體。接著，您會建立 Service，獨立於任何特定 Pod 提供資料庫存取權。即使 Pod 移至其他節點，服務仍維持不變。
如要存取資料庫執行個體中的資料，請建立 PersistentVolumeClaim (PVC) 資源，並提供給工作負載。
資料庫會依賴本機磁碟來維持狀態。在 Kubernetes 叢集中，以 Service 形式執行的資料庫，以及 PersistentVolumeClaim 中的資料庫檔案，都會繫結至叢集的生命週期。如果刪除叢集，資料庫也會一併刪除。
如果您要建構或部署在 GKE 中執行的有狀態應用程式，請考慮使用下列其中一種資料庫執行個體部署選項：
- 全代管資料庫：Cloud SQL 或 Spanner 等代管資料庫可減少作業負擔，並針對 Google Cloud 基礎架構進行最佳化。與直接在 Kubernetes 中部署的資料庫相比，管理型資料庫的維護和運作工作量較少。
- Kubernetes 應用程式：您可以在 GKE 叢集上部署及執行資料庫執行個體 (例如 MySQL)。
在 GKE 部署資料庫的注意事項
考量到您的業務目標和限制，上述每個選項都有利弊。請參考下表，判斷在 GKE 上部署資料庫是否適合您。
| 考慮度 | 說明 |
|---|---|
| 資料庫獨立性 | PersistentVolumeClaim 的生命週期與對應的 GKE 叢集相關聯。如果您不希望資料庫生命週期取決於特定 GKE 叢集，建議將資料庫分開管理，例如使用受管理資料庫或 VM 執行個體。 |
| 使用 GKE 調度資源 | 垂直調度：您可以設定 Pod 要求，自動調度資源。 不過，您必須確保資料庫應用程式能承受 Pod 透過垂直自動調度 Pod 資源功能擴充時造成的中斷。 水平擴充：資料庫可透過新增副本，水平擴充讀取或寫入作業。資料庫是否支援水平擴充，取決於資料庫是採用單一寫入器還是多重寫入器架構。如要使用水平資源調度，除了增加副本數量外，可能還需要更新資料庫設定。 |
| GKE 負擔 | 在 Autopilot 叢集上，系統不會針對預留資源收費，只會針對資源要求收費。 在 Standard 叢集中，GKE 會 保留資源供自身作業使用。Standard 叢集上的資料庫不會自動調度資源，因此小型 Pod 的負擔可能較高。 |
| 資料庫執行個體數量 | 在 Kubernetes 中，每個資料庫執行個體都會在自己的 Pod 中執行，並有自己的 PersistentVolumeClaim。如果執行大量執行個體，就必須運作及管理大量 Pod、節點和磁碟區聲明。建議改用代管資料庫。 |
| GKE 中的資料庫備份 | PersistentVolumeClaim 的範圍限定為 GKE 叢集。 這表示刪除 GKE 叢集時，系統也會刪除磁碟區聲明。叢集中的所有資料庫檔案也會一併刪除。 為防範資料庫檔案意外遺失，建議您進行複製或頻繁備份。 您可以使用 GKE 備份，定期為應用程式設定和磁碟區資料建立快照。GKE 備份服務可處理磁碟區備份的排程、管理備份生命週期，以及將備份還原至叢集。 |
| Kubernetes 專屬的復原行為 | 如果 Kubernetes 中的 Pod 發生故障，系統會重新建立該 Pod。從資料庫執行個體的角度來看，這表示重新建立 Pod 時，系統也會重新建立資料庫中或 Pod 外部穩定儲存空間內的所有非永久性設定。 |
| 資料庫架構 | 如果資料庫設定為使用主動-被動架構，請務必確保只有一個副本設定為主要副本。許多關聯式資料庫都提供主動/被動容錯移轉選項，如果主要資料庫發生故障，次要資料庫可以升級為主要資料庫。 |
| 資料庫遷移 | 如要將現有資料庫系統遷移至 GKE，請參閱「 資料庫遷移：概念與原則 (第 1 部分)」和「 資料庫遷移：概念與原則 (第 2 部分)」。 |
| 使用者重新訓練 | 如果您從自行管理或供應商管理的部署作業，改為 Kubernetes 資料庫部署作業，您需要重新訓練資料庫管理員，讓他們在新環境中運作時，能像在目前環境中一樣可靠。應用程式開發人員可能也必須瞭解差異，但程度較輕微。 |
上表討論了資料庫部署作業的一些注意事項。不過，這份表格並未列出所有可能的考量事項。您也需要考慮災難復原、連線集區和監控。
後續步驟
- 瞭解如何在 GKE 上部署高可用性 MySQL 拓撲。
- 瞭解如何在 GKE 上部署高可用性 PostgreSQL 執行個體。
- 進一步瞭解 GKE 備份，這項服務可備份及還原 GKE 中的工作負載。
- 進一步探索永久磁碟區。