提升 Kubernetes 效能的秘訣：開發完美執行環境

：資訊系統容錯性的重要性資訊系統的容錯性對於確保系統持續運作，並在裝置故障或失效時將資料遺失的可能性降至最低至關重要。對於業務關鍵型系統而言，這一點尤其重要。許多企業開始採用地理分散的叢集，以提升服務可靠性。本文將闡述我們使用的工具、遇到的挑戰以及最終的成果，著重於如何透過 Istio 多叢集佈署來提升 Kubernetes（K8s）叢集中業務關鍵應用程式的穩定性。

問題的起源：單一 K8s 叢集的潛在風險

在現代微服務架構中，服務通常執行在 K8s 叢集中，彼此高度整合，並且資料函式庫（Database as a Service，DBaaS），如 PostgreSQL、Kafka、MongoDB、Redis 等，以及其他團隊的應用程式互動。維持高服務等級指標（Service Level Indicator，SLI）至關重要，因為即使是短暫的服務中斷也可能造成巨大的業務損失。

儘管 K8s 透過副本控制器提供自動擴充套件和故障還原，但單一叢集仍然存在風險。想像一下，K8s 叢集就像一座現代化的摩天大樓，內部設施一應俱全，可以自給自足地執行。然而，如果大樓的某一層發生火災，可能會蔓延到其他樓層，甚至影響整個大樓的運作。同樣地，單一 K8s 叢集若發生意外，可能會導致服務中斷，影響整個業務。即使是大型雲端服務供應商，如 Yandex Cloud，也僅對雲端服務提供 99.9% 的服務等級協定（Service Level Agreement，SLA），這意味著每年最多可能會有數小時的停機時間。

Istio 多叢集整合：開發高用性 K8s 系統的解決方案

為瞭解決單一 K8s 叢集的潛在風險，我們開始研究 K8s 叢集的 Istio 多叢集整合技術。Istio 是一個開放原始碼的服務網格（Service Mesh），提供流量管理、安全性與可觀察性等功能，能夠有效地管理跨多個 K8s 叢集的服務。

Istio 解決的任務包括：

流量管理（Traffic Management）： 實作智慧路由、負載平衡與容錯移轉。
安全性（Security）： 提供服務間的身份驗證、授權與加密。
可觀察性（Observability）： 收集服務指標、日誌與追蹤資料，方便監控與除錯。

整合 Istio 多叢集的過程可以分為幾個階段：

準備概念驗證（Proof of Concept，POC）與檢驗假設
完善持續整合與持續交付（Continuous Integration/Continuous Delivery，CI/CD）流程
準備環境
服務分發

Istio 多叢集架構：運作原理

在根據多個微服務的專案中，網路架構的基本工作模型如下：負載平衡器接收使用者請求，並將其傳送到叢集。接著，Istio 的 Sidecar 容器（Envoy）攔截請求，並透過互通傳輸層安全協定（Mutual Transport Layer Security，mTLS）、可觀察性、熔斷機制（Circuit Breaker）等功能進行增強，然後將其傳送到應用程式的 Pod。請求的傳送方向根據 Envoy 從 Istio 控制器取得的資訊，控制器會根據任何變更做出決策。

概念驗證：實作 Istio 多叢集

為了驗證 Istio 多叢集的可行性，我們將位於不同資料中心的兩個叢集整合到 Istio 多叢集中。在這個階段，我們發現具備 Istio 多叢集專業知識的人員不多，與公司沒有現成的生產環境解決方案，因此我們必須自行探索。以下是在兩個 K8s 叢集中設定 Istio 多叢集的步驟：

啟用 Deckhouse 的 Istio 模組。

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: istio
spec:
  version: 2
  enabled: true

在兩個叢集的應用程式名稱空間中安裝標籤 istio-injection: enabled，以便 Istio 為名稱空間內的每個 Pod 連線其 Sidecar。
透過引數 istio.spec.settings.multicluster.enabled = true 啟用 Deckhouse 中 Istio 模組的 Istio Multicluster。
為 Ingress-Controller 啟用 Istio Sidecar，使用以下引數。

對於兩個叢集，在 kube-dns 模組中新增共同的 clusterDomainAliases。

修改前：

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: kube-dns
spec:
  version: 1
  enabled: true
settings:
  clusterDomainAliases:
    - cluster.local

修改後：

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: kube-dns
spec:
  version: 1
  enabled: true
settings:
  clusterDomainAliases:
    - cluster.local
    - alpha.p.mesh

對於兩個叢集，在 control-plane-manager 模組中新增共同的 certSAN。

修改前：

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: control-plane-manager
spec:
  version: 1
  enabled: true
settings:
  apiserver:
    certSANs:
      - kubernetes.default.svc.cluster.local

修改後：

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: control-plane-manager
spec:
  version: 1
  enabled: true
settings:
  apiserver:
    certSANs:
      - kubernetes.default.svc.cluster.local
      - kubernetes.default.svc.alpha.p.mesh

重要： 在操作後，API 伺服器會開始重新啟動，直到新的設定應用為止。

結論：邁向高用性 K8s 系統

透過 Istio 多叢集整合，我們成功地提高了 K8s 叢集中關鍵應用程式的穩定性與容錯能力。這種架構不僅能夠在單一叢集發生故障時提供備援，還能夠實作更智慧的流量管理與更強大的安全性。雖然實作過程充滿挑戰，但最終的成果證明瞭 Istio 多叢集是開發高用性 K8s 系統的有效解決方案。透過本文的分享，希望能幫助更多企業在 K8s 環境中實作更穩固、高效的應用程式佈署。

在現代微服務架構中，高用性（High Availability，HA）與災難還原（Disaster Recovery，DR）是至關重要的考量因素。為了確保應用程式的持續執行，即使在單一資料中心發生故障時，也能夠快速切換到其他可用區域，Istio Multicluster 提供了一個強大的解決方案。本文將探討如何利用 Istio Multicluster，將微服務佈署到多個 Kubernetes 叢集，從而提升系統的容錯能力和災難還原能力。

多叢集架構的必要性

單一 Kubernetes 叢集雖然能夠提供一定的容錯能力，但仍然存在單點故障的風險。例如，如果整個資料中心發生故障，那麼佈署在該資料中心的所有應用程式都會受到影響。為了避免這種情況，將應用程式佈署到多個 Kubernetes 叢集，並將這些叢集分散在不同的地理位置，可以顯著提高系統的可用性。

多叢集架構的主要優點包括：

提高用性：即使一個叢集發生故障，應用程式仍然可以在其他叢集上執行。
增強災難還原能力：當整個資料中心發生故障時，可以快速切換到其他資料中心的叢集。
降低延遲：可以將應用程式佈署到離使用者更近的叢集，從而降低延遲。
隔離故障：一個叢集的故障不會影響其他叢集。

Istio Multicluster 的運作原理

Istio Multicluster 允許將多個 Kubernetes 叢集連線在一起，形成一個統一的服務網格（Service Mesh）。在這種架構下，佈署在不同叢集上的微服務可以像在單一叢集中一樣互相發現和通訊。Istio 透過以下機制實作多叢集支援：

分享控制平面（Shared Control Plane）或獨立控制平面（Separate Control Plane）：可以選擇使用一個分享的 Istio 控制平面來管理所有叢集，或者為每個叢集設定獨立的控制平面。分享控制平面簡化了管理，而獨立控制平面提供了更高的隔離性。
跨叢集服務發現（Cross-Cluster Service Discovery）：Istio 使用 DNS 和 Kubernetes API 伺服器（API Server）來實作跨叢集的服務發現。當一個微服務需要呼叫另一個微服務時，Istio 會自動將請求路由到目標微服務所在的叢集。
流量管理（Traffic Management）：Istio 提供了豐富的流量管理功能，例如流量轉移、負載平衡和故障注入。可以使用這些功能來控制跨叢集的流量路由，實作灰度發布、金絲雀佈署和故障還原。
安全性（Security）：Istio 提供了強大的安全功能，例如相互 TLS（Mutual TLS，mTLS）和身份驗證。可以使用這些功能來保護跨叢集的通訊安全。

實作 Istio Multicluster 的步驟

以下是使用 Istio Multicluster 佈署微服務的基本步驟：

安裝 Istio：在每個 Kubernetes 叢集上安裝 Istio。可以選擇使用分享控制平面或獨立控制平面。
設定叢集間的連線：設定 Istio，使其能夠發現和連線到其他叢集。這通常涉及到設定 DNS 和 Kubernetes API 伺服器（API Server）的存取許可權。
佈署微服務：將微服務佈署到不同的 Kubernetes 叢集。確保每個微服務都設定了 Istio sidecar 代理。
設定流量路由：使用 Istio 的流量管理功能，設定跨叢集的流量路由。例如，可以將一部分流量路由到一個叢集，將另一部分流量路由到另一個叢集。
測試和監控：測試跨叢集的微服務通訊，並使用 Istio 的監控功能來監控系統的健康狀況。

實戰經驗與注意事項

在實作 Istio Multicluster 的過程中，可能會遇到一些挑戰。以下是一些實戰經驗和注意事項：

版本一致性：確保所有叢集上執行的 Istio 版本一致。版本不一致可能導致相容性問題。
容錯移轉策略：設定合理的區域容錯移轉策略，避免叢集之間的大量流量。例如，可以優先將流量路由到同一區域的叢集。
Sidecar 注入：控制哪些微服務需要注入 Istio sidecar 代理。可以使用名稱空間標籤或 Pod 標籤來控制 Sidecar 注入。
資源限制：限制 Istio 傳送到 Envoy 代理的資訊量，避免網路和控制平面的過載。可以使用 Sidecar 自定義資源定義（Custom Resource Definition，CRD）來限制資訊傳送範圍。
啟動順序：確保 Istio 容器在主 Pod 啟動之前啟動，並在主 Pod 停止之後停止。可以使用 Kubernetes 的生命週期鉤子（Lifecycle Hooks）來控制容器的啟動和停止順序。
負載平衡：注意 Istio 和 Envoy 代理的負載平衡優先順序。在某些情況下，可能需要調整負載平衡策略，以確保流量在 Pod 之間均勻分配。

以下是一個 DestinationRule 的範例，用於設定負載平衡優先順序：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: example
spec:
  host: example.host
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failoverPriority:
          - "topology.istio.io/network"

多叢集之外的資源考量

除了 Kubernetes 叢集之外，還需要考慮其他基礎設施資源的佈署。例如，資料函式庫atabase）可以使用 Patroni + etcd 叢集分散到不同的資料中心。訊息佇列（Message Queue）系統，如 Kafka，也應該考慮多叢集佈署。

Istio Multicluster 是一個強大的工具，可以幫助我們構建高用性、高容錯性的微服務架構。然而，使用 Istio Multicluster 需要仔細的規劃和設定。透過本文的介紹，希望能幫助讀者更好地理解 Istio Multicluster 的運作原理和實作細節，從而在實際專案中成功應用 Istio Multicluster。建議在生產環境中啟用 Istio Multicluster 之前，進行充分的測試和驗證。透過不斷的實驗、創造和分享，我們可以更好地掌握這項技術，並將其應用於更多的場景中。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。