透過 Google Kubernetes Engine 使用 Google Cloud Platform 服務

本文件說明如何透過 Google Kubernetes Engine (GKE) 使用 Google Cloud Platform (GCP) 服務。當您透過在 GKE 中執行的應用程式使用 Cloud Storage、Cloud SQL 等 GCP 服務時,就必須針對所用的服務設定環境。本文件說明常見的架構模式及其相關工作,並提供介紹範例設定的說明文件連結。

目標

  • 設定服務帳戶與密鑰以使用 GCP 服務。
  • 設定 Cloud SQL Proxy Docker 映像檔以使用 Cloud SQL 資料庫。
  • 設定內部負載平衡功能,以使用在 Compute Engine VM 上執行的自訂服務。
  • 設定 NAT 閘道以使用需要固定 IP 位址的外部服務。
  • 使用 Stackdriver Logging 來進行應用程式記錄。

認識常見工作

下圖顯示的是透過 GKE 使用其他服務的常見架構模式。

透過 GKE 使用 GCP 服務的常見架構模式圖

您可以執行下列工作來進行設定:

  • 如要透過 Cloud API 使用 GCP 服務 (例如 Cloud Storage),您要為服務帳戶指派適當的角色,並使用 Kubernetes secret 物件為您的應用程式提供相關聯的密鑰。
  • 如要使用 Cloud SQL,您要為服務帳戶指派適當的角色,並使用補充 pod 模式替 pod 新增 Cloud SQL Proxy。
  • 如要以可擴充的方式使用在 Compute Engine VM 上執行的自訂服務,請設定內部負載平衡功能。
  • 如要使用需有固定 IP 位址的外部服務,您須設定 NAT 閘道。
  • 如要使用 Logging 來進行應用程式記錄,您須讓應用程式將記錄訊息寫入標準輸出 (stdout) 及標準錯誤 (stderr)。

下列各節提供介紹相關設定步驟的連結。

透過 Cloud API 使用 GCP 服務

您可透過 Cloud API,以服務帳戶和密鑰來使用 GCP 服務。如下圖所示,Kubernetes 提供的 secret 資源類型可將憑證儲存於叢集內,以及將憑證附加至應用程式的 Pod:

圖中顯示由多個 Pod 存取的 Kubernetes「secret」物件中的密鑰

如需透過範例瞭解如何以在 GKE 中執行的應用程式使用 Cloud Pub/Sub,請參閱使用服務帳戶通過 Cloud Platform 驗證一文。您可以採取相同的步驟來使用 Cloud Storage、BigQuery、Cloud Datastore、Cloud Spanner 等其他 GCP 服務,不過必須替服務帳戶及相關服務選擇適當的角色,而且可能需要針對各項服務執行特定步驟。

Cloud SQL 屬於例外情況。如要使用這項服務,您須採取不同的做法,因為 Cloud SQL 需要 Cloud SQL Proxy 用戶端才能安全地存取資料庫,相關做法將於下節說明。

透過 Cloud SQL Proxy 使用 Cloud SQL

如要透過在 GKE 中執行的應用程式存取 Cloud SQL 執行個體,您須使用 Cloud SQL Proxy Docker 映像檔。當您將映像檔附加至應用程式的 Pod 後,您的應用程式就能使用該 Pod 中的 Cloud SQL Proxy 用戶端。Cloud SQL Proxy 用戶端會以安全的方式在應用程式和 Cloud SQL 執行個體之間傳送資料,如下圖所示:

圖中顯示容器內的應用程式與 Cloud SQL Proxy 進行通訊,接著 Cloud SQL Proxy 以安全的連線與 Cloud SQL 進行通訊

要瞭解如何將 Cloud SQL Proxy 映像檔附加至應用程式的 Pod,請參閱 Cloud SQL:從 GKE 連線相關說明。

透過內部負載平衡功能使用外部服務

如要透過在 GKE 中執行的應用程式存取外部服務,您須使用內部或外部名稱服務以讓應用程式找到服務端點。如需設定名稱服務的三種方法說明,請參閱由叢集內部連線至外部服務一節。

如果外部服務是在 Compute Engine 執行個體上執行,您可能會想用內部負載平衡功能來讓外部服務具有備援與擴充能力。下圖說明了這項做法。

圖中顯示容器中的應用程式與 Cloud Load Balancing 進行通訊,接著 Cloud Load Balancing 與執行不同服務的多個 Compute Engine 執行個體進行通訊

要瞭解如何為執行 Compute Engine 執行實體的後端服務設定內部負載平衡功能,請參閱設定內部負載平衡相關說明。

透過 NAT 閘道使用外部服務

託管應用程式 Pod 的 VM 節點會從在 GKE 中執行的應用程式傳送輸出封包;這些 VM 節點的臨時 IP 位址會用做為輸出封包的來源 IP 位址。因此,應用程式的來源 IP 位址可能會隨著傳送封包的 VM 節點而改變。所以即使封包來自同一應用程式,外部服務仍會收到來自多個來源 IP 位址的封包。在一般情況下,這不會造成任何問題。不過,您可能會想從固定 IP 位址傳送封包,因為某些外部服務的設定是只能接受單一來源的封包。

在這種情況下,您可利用做為 NAT 閘道使用的 Compute Engine 執行個體。替 NAT 閘道建立自訂轉送規則後,您就能以固定 IP 位址傳送封包給外部服務,如下圖所示:

圖中顯示 GKE 使用自訂轉送功能與位於外部服務之前的 NAT 閘道進行通訊

如需進一步瞭解相關資訊,請參閱搭配 GKE 使用 NAT 閘道建構具有高可用性及高頻寬的 NAT 閘道的相關說明。這兩篇文章說明如何部署 NAT 閘道執行個體和建立自訂轉送規則。

如果您使用的是私人叢集,而且其中的 VM 節點僅有私人 IP 位址,您也可應用同樣的架構。在這種情況下,NAT 閘道會從私人子網路接收封包,再透過單一公開 IP 位址將封包傳送至外部服務。

將應用程式記錄傳送給 Stackdriver Logging

系統會依預設啟用 Stackdriver Logging,讓 GKE 自動收集和處理容器及系統記錄,並將記錄儲存在專屬的永久資料儲存庫中。GKE 會針對每個節點部署記錄代理程式,這個程式會從 Pod 中的 stdoutstderr 讀取記錄,如下圖所示:

圖中顯示多個應用程式 Pod 寫入「stdout」和「stderr」,內容會先寫入記錄代理程式,然後再寫入 Logging

因此,您必須讓應用程式將記錄訊息寫入至 stdoutstderr。要瞭解如何使用 Logging 收集、查詢並分析在 GKE 中執行的應用程式記錄,請參閱 GKE - Logging 頁面。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁