關於服務探索

本文說明 Google Kubernetes Engine (GKE) 中的服務探索如何簡化應用程式管理，以及如何使用 Cloud DNS 範圍、多叢集服務 (MCS) 和 Service Directory，將服務探索擴展到單一叢集以外。

本文件適用於 GKE 使用者、開發人員、管理員和架構師。如要進一步瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。

閱讀本文前，請務必瞭解下列概念：

總覽

服務探索機制可讓服務和應用程式動態尋找彼此並進行通訊，不必將 IP 位址或端點設定硬式編碼。服務探索可確保應用程式隨時都能存取最新的 Pod IP 位址，即使 Pod 重新排程或新增 Pod 也是如此。GKE 提供多種服務探索實作方式，包括 kube-dns、自訂 kube-dns 部署作業和 Cloud DNS。您可以進一步使用 NodeLocal DNSCache 最佳化 DNS 效能。

服務探索的優點

服務探索功能有下列優點：

  • 簡化應用程式管理作業：服務探索功能可免除在應用程式設定中硬式編碼 IP 位址的需求。應用程式會使用邏輯服務名稱進行通訊，這些名稱會自動解析為正確的 Pod IP 位址。這種做法可簡化設定，尤其是在動態環境中，Pod IP 位址可能會因擴縮或重新排程而變更。
  • 簡化擴充和復原程序：服務探索會將服務消費者與 Pod IP 位址分離，簡化擴充程序，因為 Pod IP 位址經常變更。應用程式擴充時，或 Pod 發生故障並遭到取代時，Kubernetes 會自動更新可接收特定服務流量的 Pod。服務探索功能可確保對穩定服務名稱的要求只會導向健康狀態良好的 Pod，讓應用程式擴充或從故障中復原時，不必手動介入或重新設定用戶端。
  • 高可用性：GKE 會搭配服務探索功能使用負載平衡，確保應用程式的高可用性，並提升回應速度，即使在負載量大的情況下也不例外。

透過服務探索進行負載平衡

GKE 會結合不同層級的負載平衡與服務探索，確保應用程式的高可用性。

  • 內部服務：如果服務只能在叢集內存取，GKE 的資料平面 (kube-proxy 或 Cilium) 會做為負載平衡器。將傳入流量平均分配到多個正常的 Pod，避免過載並確保高可用性。
  • 外部服務：如要讓叢集外部存取服務，GKE 會佈建 Google Cloud 負載平衡器。這些負載平衡器包括用於公用網際網路存取的外部 Google Cloud 負載平衡器，以及用於虛擬私有雲網路內存取的內部 Google Cloud 負載平衡器。這些負載平衡器會將流量分配到叢集中的節點。每個節點上的資料平面會進一步將流量轉送至適當的 Pod。

無論是內部或外部情境，服務探索都會持續更新每個服務可用的 Pod 清單。持續更新可確保資料平面 (適用於內部服務) 和 Google Cloud 負載平衡器 (適用於外部服務) 只會將流量導向至運作正常的執行個體。

服務探索的用途

以下是服務探索的常見用途：

  • 微服務架構：在微服務架構中，應用程式通常由許多需要互動的獨立小型服務組成。服務探索功能可讓這些應用程式互相尋找及交換資訊，即使叢集擴充也沒問題。
  • 啟用零停機時間部署作業並提升韌性：服務探索功能可協助您為應用程式進行零停機時間更新，包括控管推出作業和初期測試版部署作業。這項功能會自動探索新版服務，並將流量轉移至新版服務，有助於減少部署期間的停機時間，確保使用者順利轉換。服務探索也能提升韌性。如果 Pod 在 GKE 中發生故障，系統會部署新的 Pod，而服務探索功能會註冊新的 Pod 並將流量重新導向至該 Pod，有助於盡量減少應用程式停機時間。

服務探索的運作方式

在 GKE 中，應用程式通常由多個 Pod 組成，這些 Pod 需要互相尋找並通訊。服務探索功能會使用網域名稱系統 (DNS) 提供這項功能。就像您使用 DNS 在網路上尋找網站一樣，GKE 叢集中的 Pod 會使用 DNS，透過服務名稱尋找及連線至服務。無論 Pod 在叢集中的哪個位置執行，都能有效互動，應用程式也能使用一致的服務名稱 (而非不穩定的 IP 位址) 通訊。

Pod 如何執行 DNS 解析

GKE 叢集中的 Pod 會使用自動產生的 DNS 記錄和本機 DNS 設定，解析服務和其他 Pod 的 DNS 名稱。

服務 DNS 名稱

建立 Kubernetes Service 時，GKE 會自動為其指派 DNS 名稱。這個名稱採用可預測的格式，叢集中的任何 Pod 都能用來存取 Service：

<service-name>.<namespace>.svc.cluster.local

叢集網域預設為 cluster.local，但您可以在建立叢集時自訂網域。舉例來說，預設命名空間中名為 my-web-app 的 Service，其 DNS 名稱為 my-web-app.default.svc.cluster.local。

/etc/resolv.conf 的角色

Pod 會依賴 /etc/resolv.conf 檔案解析這些 DNS 名稱。這個設定檔會告知 Pod 要將 DNS 查詢傳送至哪個名稱伺服器。這個檔案中列出的名稱伺服器 IP 位址，取決於 GKE 叢集上啟用的特定 DNS 功能。下表根據您的設定，列出 Pod 使用的名稱伺服器 IP：

Cloud DNS for GKE NodeLocal DNSCache `/etc/resolv.conf` 名稱伺服器值
已啟用 已啟用 `169.254.20.10`
已啟用 已停用 `169.254.169.254`
已停用 已啟用 `kube-dns` 服務 IP 位址
已停用 已停用 `kube-dns` 服務 IP 位址

這項設定可確保 Pod 的 DNS 查詢會導向正確的元件：

  • NodeLocal DNSCache：在節點上提供快速的本機查詢。
  • 中繼資料伺服器 IP (169.254.169.254)：啟用 GKE 適用的 Cloud DNS 時，如果未啟用 NodeLocal DNSCache，就會使用這個 IP。DNS 查詢會導向這個 IP 位址，Cloud DNS 會攔截並處理 DNS 要求。
  • kube-dns 服務 IP 位址：如果停用 GKE 適用的 Cloud DNS，系統會使用這個位址進行標準叢集內解析。

GKE 中的 DNS 架構

GKE 提供彈性的服務探索架構，主要透過 DNS 進行。下列元件會共同運作，在叢集內解析 DNS 查詢：

  • kube-dns：GKE Standard 叢集的預設叢集內 DNS 供應商。這項服務會在 kube-system 命名空間中以 Pod 的代管部署形式執行，並監控 Kubernetes API 中的新服務，以便建立必要的 DNS 記錄。
  • Cloud DNS： Google Cloud全代管 DNS 服務。Cloud DNS 是 kube-dns 的替代方案，具有高度擴充性和可靠性，也是 GKE Autopilot 叢集的預設 DNS 供應商。
  • NodeLocal DNSCache：可提升 DNS 查詢效能的 GKE 外掛程式。這項功能會在叢集中的每個節點上執行 DNS 快取，並與 kube-dns 或 Cloud DNS 搭配運作，在本機提供 DNS 查詢服務，藉此縮短延遲時間，並減輕叢集中央 DNS 供應商的負擔。如為 GKE Autopilot 叢集，NodeLocal DNSCache 預設為啟用，且無法覆寫。
  • 自訂 kube-dns 部署作業：可讓您部署及管理自己的 kube-dns 執行個體，進一步控管 kube-dns 設定和資源。

選擇 DNS 供應商

下表摘要列出 GKE 提供的 DNS 供應商，包括其功能和適用時機：

供應商 功能 選擇時機
`kube-dns` 服務和 Pod 的叢集內 DNS 解析。 所有需要標準網路的叢集。新版 `kube-dns` 適用於小型和大型叢集。
Cloud DNS 進階 DNS 功能 (私有區域、流量導向、全域負載平衡)，以及與其他 Google Cloud 服務的整合。 在外部公開服務、多叢集環境，或 DNS 查詢率 (QPS) 較高的叢集。
自訂 `kube-dns` 部署作業 可進一步控管設定、資源分配，以及使用替代 DNS 供應商的可能性。 大型叢集或特定 DNS 需求，需要更積極的資源調度或精細控管資源分配。

單一叢集外的服務探索

您可以使用下列方法，將服務探索範圍擴展到單一 GKE 叢集以外：

Cloud DNS 範圍

使用 Cloud DNS 做為叢集 DNS 的叢集，可在下列三種可用範圍中運作：

  • 叢集範圍：這是 Cloud DNS 的預設行為。在這個模式下，Cloud DNS 的功能與 kube-dns 相同，只為叢集內的資源提供 DNS 解析服務。DNS 記錄只能從叢集內解析，且符合標準 Kubernetes 服務結構定義：<svc>.<ns>.svc.cluster.local。
  • 附加虛擬私有雲範圍：這項選用功能可擴展叢集範圍，讓無標題服務可從同一虛擬私有雲網路中的其他資源解析，例如 Compute Engine VM 或使用 Cloud VPN 或 Cloud Interconnect 連線的內部部署用戶端。
  • 虛擬私有雲範圍：採用這項設定後，叢集服務的 DNS 記錄可在整個虛擬私有雲網路中解析。採用這種做法後，位於相同 VPC 或連線至該 VPC (透過 Cloud VPN 或 Cloud Interconnect) 的任何用戶端，都可以直接解析服務名稱。

如要進一步瞭解虛擬私有雲範圍 DNS，請參閱「使用 GKE 適用的 Cloud DNS」。

多叢集 Service

多叢集服務 (MCS) 可在多個 GKE 叢集之間啟用服務探索和流量管理功能。MCS 可讓您建構跨叢集的應用程式，同時維持統一的服務體驗。

MCS 會利用以 DNS 為基礎的服務探索功能，連結各叢集中的服務。建立 MCS 執行個體時，系統會產生 <svc>.<ns>.svc.clusterset.local 格式的 DNS 記錄。這些記錄會解析為每個參與叢集中服務端點的 IP 位址。

當某個叢集的用戶端存取 MCS 時，要求會轉送至任何參與叢集中最近的可用端點。這項流量分配作業由每個節點上的 kube-proxy (或 GKE Dataplane V2 中的 Cilium) 管理，有助於確保叢集間的通訊效率和負載平衡。

Service Directory for GKE

GKE 適用的 Service Directory 提供統一的服務探索註冊資料庫，適用於 Kubernetes 和非 Kubernetes 部署作業。Service Directory 可在單一登錄中註冊 GKE 和非 GKE 服務。

如果您有下列任一需求，就很適合使用 Service Directory：

  • Kubernetes 和非 Kubernetes 應用程式可透過單一登錄檔互相探索。
  • 代管服務探索工具。
  • 可儲存服務相關中繼資料，供其他用戶端存取。
  • 可針對每個服務設定存取權限。 您可以使用 DNS、HTTP 和 gRPC 解析 Service Directory 服務。Service Directory 與 Cloud DNS 整合，可填入與 Service Directory 中服務相符的 Cloud DNS 記錄。

詳情請參閱「為 GKE 設定 Service Directory」。

提升 DNS 效能和最佳做法

為確保服務探索功能穩定有效，尤其是在大規模或高流量叢集中，請考慮採用下列最佳做法和最佳化策略。

使用 NodeLocal DNSCache 提升效能

如果叢集的 Pod 密度很高，或是應用程式會產生大量 DNS 查詢，您可以啟用 NodeLocal DNSCache，提升 DNS 查詢速度。NodeLocal DNSCache 是 GKE 外掛程式，可在叢集中的每個節點上執行 DNS 快取。當 Pod 發出 DNS 要求時，要求會傳送至同一節點上的快取。這種做法可減少延遲和網路流量。

如要進一步瞭解如何啟用及設定這項功能，請參閱「設定 NodeLocal DNSCache」一文。

擴大 DNS 供應商規模

如果您使用 kube-dns，且發生間歇性逾時問題 (尤其是在流量高峰期間)，可能需要擴充 kube-dns 副本數量。kube-dns-autoscaler 會根據叢集中的節點和核心數量調整副本數量，並可調整參數，以便更快部署更多副本。

如需詳細操作說明，請參閱「擴大 kube-dns」。

常見的最佳做法

  • 選取合適的 DNS 供應商：根據叢集需求選擇 DNS 供應商。建議您將 Cloud DNS 用於高 QPS 工作負載、多叢集環境，以及需要與更廣泛的 VPC 網路整合時。新版 kube-dns 適用於各種大小的叢集，可滿足標準叢集內服務探索需求。
  • 避免使用 Spot VM 或先占 VM 執行 kube-dns：請勿在 Spot VM 或先占 VM 上執行 kube-dns 等重要系統元件，確保叢集 DNS 服務的穩定性。節點意外終止可能會導致 DNS 解析問題。
  • 使用清楚且具描述性的服務名稱：為服務採用一致且有意義的命名慣例，方便您閱讀及維護應用程式設定。
  • 使用命名空間分門別類：使用 Kubernetes 命名空間將相關服務分組。這種做法有助於避免命名衝突，並改善叢集資源的組織方式。
  • 監控及驗證 DNS：定期監控 DNS 指標和記錄，在潛在問題影響應用程式前找出問題。請定期從 Pod 內部測試 DNS 解析，確保服務探索功能正常運作。

後續步驟