溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Cilium多集群詳細介紹”，在日常操作中，相信很多人在Cilium多集群詳細介紹問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Cilium多集群詳細介紹”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
本文是對ClusterMesh（Cilium的多集群實現）的深入研究。簡而言之，ClusterMesh 提供：
通過隧道或直接路由，以本地性能對多個Kubernetes集群進行Pod IP路由，而無需任何網關或代理。
使用標準Kubernetes服務和coredns/kube-dns的透明服務發現。
跨多個集群的網絡策略實施。 策略可以指定為Kubernetes NetworkPolicy資源或擴展的CiliumNetworkPolicy CRD。
透明加密，用于本地集群中的節點之間以及跨集群邊界的所有通信。
多集群功能以層為單位構建，您可以選擇使用所有層，也可以僅選擇和使用所需的層。
在深入研究實現細節之前，讓我們回顧一下連接多個Kubernetes集群的一些用例。
基于Kubernetes的平臺的最初趨勢是構建大型多租戶Kubernetes集群。 為每個租戶構建單個集群或為不同類別的服務構建集群越來越普遍，例如， 不同級別的安全敏感度。 
但是，某些服務（如密鑰管理，日志記錄，監控或DNS）通常仍在所有集群之間共享。 這避免了在每個租戶集群中維護這些服務的操作開銷。
此模型的主要動機是租戶集群之間的隔離，為了維持該目標，租戶集群連接到共享服務集群但未連接到其他租戶集群。
運行有狀態或無狀態服務的操作復雜性是非常不同的。 無狀態服務易于擴展，遷移和升級。 完全使用無狀態服務運行集群可使集群保持靈活和敏捷。 從一個云提供商遷移到另一個云提供商非常簡單。
有狀態服務可能會引入潛在的復雜依賴鏈。 遷移服務通常涉及存儲遷移。 
pod IP路由是多集群能力的基礎。 它允許跨集群的pod通過其pod IP相互聯系。 Cilium可以在多種模式下運行以執行pod IP路由。 所有這些模式都能夠執行多集群pod IP路由。
優點：pod IP在底層網絡上永遠不可見。 網絡只能看到工作節點的IP地址。 這可以簡化安裝和防火墻規則。
缺點：所需的額外網絡標頭將降低網絡的理論最大吞吐量。 確切的成本取決于配置的MTU，與使用MTU 9000的巨型幀相比，使用1500的傳統MTU時會更加明顯。
缺點：為了不消耗過多CPU，包括底層硬件在內的整個網絡堆棧必須支持校驗和和分段卸載，以計算校驗和并在硬件中執行分段，就像對“常規”網絡數據包所做的那樣。如今，這種卸載功能的可用性非常常見。
在直接路由模式中，所有網絡數據包都直接路由到網絡。 這要求網絡能夠路由pod IP。 可以使用多個選項實現跨節點傳播pod IP路由信息：
使用--auto-direct-node-routes選項，這是通過kvstore的超輕量級路由傳播方法，如果所有工作節點共享一個單一的2層網絡，該選項將起作用。 對于所有形式的基于云提供商的虛擬網絡，通常都滿足此要求。
使用kube-router集成運行BGP路由守護進程。
使用任何其他路由守護進程將路由注入標準Linux路由表（bird，quagga，…）
當網絡不再理解pod IP時，網絡數據包地址需要偽裝。
優點：減少的網絡數據包標頭可以優化網絡吞吐量和延遲。
缺點：整個網絡必須能夠路由pod IP，這會增加操作的復雜性。
混合路由模式允許在可用時使用直接路由，這通常在本地集群或同一VPC中的其他集群中，而當跨越VPC或云提供商時可以回退到隧道模式。 這可以限制操作復雜性并且允許僅在需要時支付優化成本。
Cilium的多集群模型的服務發現是使用標準的Kubernetes services 構建的，旨在對現有的Kubernetes應用程序部署完全透明：
apiVersion: v1 kind: Service metadata: name: rebel-base annotations: io.cilium/global-service: "true" spec: type: ClusterIP ports: - port: 80 selector: name: rebel-base
Cilium通過一個注釋io.cilium/global-service: "true" 來監控Kubernetes服務和端點以及監聽服務。 對于此類服務，具有相同名稱和命名空間信息的所有服務將自動合并在一起，并形成跨集群可用的全局服務。
根據標準Kubernetes運行狀況檢查邏輯，任何到全局服務的ClusterIP的流量都將自動負載平衡到所有集群中的端點。
每個集群繼續為每個服務維護自己的ClusterIP，這意味著Kubernetes和kube-dns / coredns不知道其他集群。 DNS服務器繼續返回僅在本地集群中有效的ClusterIP，Cilium將透明地執行負載平衡。
對于細粒度控制存在若干附加注釋，例如單向暴露或親和策略。
從frontend-1到ClusterIP 30.1.1.1的所有流量將自動負載均衡到集群1 的后端pod IP[10.0.0.1,10.0.0.2]以及集群2的后端pod IP[20.0.0.1,20.0.0.2]。 每個集群將執行本地后端實例的運行狀況檢查，并在容器創建，銷毀或變得不健康時通知其他集群。
Cilium 1.4中引入的透明加密與多集群兼容。確保使用公共密鑰配置所有集群中的所有節點，如此節點之間的所有通信都會自動加密。
簡單版本是您從單個集群中熟悉的策略實施將簡單地擴展并跨集群工作。 由于策略是使用pod標簽指定的，因此允許frontend與backend通信的策略將應用于集群流量，就像流量跨越集群一樣。
Cilium不會跨集群自動傳播NetworkPolicy或CiliumNetworkPolicy。 用戶有責任將策略導入所有集群。 這是有意為之，因為這意味著每個集群都可以決定是否允許集群接收來自遠程集群的通信或者發出到遠程集群的通信。
可以僅建立適用于特定集群中的pod的策略。 集群名稱由Cilium表示為每個pod上的標簽，允許匹配的集群名稱可以是endpointSelector或者是由toEndpoints和fromEndpoints構造的matchLabels標簽：
apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "allow-cross-cluster" description: "Allow x-wing in cluster1 to contact rebel-base in cluster2" spec: endpointSelector: matchLabels: name: x-wing io.cilium.k8s.policy.cluster: cluster1 egress: - toEndpoints: - matchLabels: name: rebel-base io.cilium.k8s.policy.cluster: cluster2
上面的示例策略將允許cluster1中的x-wing與cluster2中的rebel-base對話。 除非存在將通信列入白名單的附加策略，否則x-wing將無法與本地集群中的rebel-base通信。
這兩個項目都是獨立的，但可以很好地相互補充。 組合Cilium和Istio多集群的常用方法是使用Cilium的多集群Pod IP路由層來滿足Istio多集群指南的以下要求：
每個集群中的所有pod CIDR必須可以相互路由。
此外，Cilium策略執行功能可用于保護與Istio控制平面之間的通信，以及通過不支持的協議（如UDP或IPV6）保護sidecar的旁路嘗試，以及防止受損的sidecar代理。
還可以同時運行全局Istio服務和Cilium全局服務。 所有Istio托管服務都可以獲得Cilium的全局服務，因為它們可以像常規服務一樣通過DNS發現。
到此，關于“Cilium多集群詳細介紹”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
