規劃 GKE 中的資料庫部署作業


本頁說明在 GKE 容器中執行資料庫的最佳做法。您可以使用部署建立一組 Kubernetes 管理的容器化資料庫執行個體。接著,您會建立 Service,以便獨立於任何特定 Pod 提供資料庫存取權。即使 Pod 移至其他節點,服務仍維持不變。

如要存取資料庫執行個體中的資料,請建立 PersistentVolumeClaim (PVC) 資源,並提供給工作負載。

資料庫會依賴本機磁碟來維持資料常駐。在 Kubernetes 叢集中以服務形式執行的資料庫,以及 PersistentVolumeClaim 中的資料庫檔案,都會受到叢集生命週期的影響。如果刪除叢集,資料庫也會一併刪除。

如果您要建構或部署在 GKE 中執行的有狀態應用程式,請考慮使用下列其中一種資料庫執行個體部署選項:

  • 全代管資料庫:代管資料庫 (例如 Cloud SQLSpanner) 可減少作業管理負擔,並針對 Google Cloud 基礎架構進行最佳化。與直接在 Kubernetes 中部署的資料庫相比,管理型資料庫的維護和運作工作較少。
  • Kubernetes 應用程式:您可以在 GKE 叢集上部署及執行資料庫執行個體 (例如 MySQLPostgreSQL)。

在 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 資料庫部署作業,則需要重新訓練資料庫管理員,讓他們在新環境中運作時,能像在目前環境中一樣可靠。應用程式開發人員可能也必須瞭解差異,但程度較輕微。

上表討論了資料庫部署的一些考量。不過,這份表格並未列出所有可能的考量事項。您也需要考慮災難復原、連線共用和監控。

後續步驟