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