本頁說明在 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 中的工作負載。
- 進一步探索永久磁碟區。