我們為何選擇 Cilium 作為 Kubernetes 的網路介面

rife發表於2023-04-07

文字翻譯自: https://blog.palark.com/why-cilium-for-kubernetes-networking/

原文作者是 Palark 平臺工程師 Anton Kuliashov，其說明了選擇 Cilium 作為 Kubernetes 網路介面的原因以及喜愛 Cilium 的地方。

多虧了 CNI（容器網路介面），Kubernetes 提供了大量選項來滿足您的網路需求。在多年依賴簡單的解決方案之後，我們面臨著對高階功能日益增長的客戶需求。Cilium 將我們 K8s 平臺中的網路提升到了一個新的水平。

背景

我們為不同行業、規模和技術堆疊的公司構建和維護基礎設施。他們的應用程式部署到私有云和公共雲以及裸機伺服器。他們對容錯性、可擴充套件性、財務費用、安全性等方面有不同的要求。在提供我們的服務時，我們需要滿足所有這些期望，同時足夠高效以應對新興的與基礎設施相關的多樣性。

多年前，當我們構建基於 Kubernetes 的早期平臺時，我們著手實現基於可靠開源元件的生產就緒、簡單、可靠的解決方案。為實現這一目標，我們的 CNI 外掛的自然選擇似乎是 Flannel（與 kube-proxy 一起使用）。

當時最受歡迎的選擇是 Flannel 和 Weave Net。Flannel 更成熟，依賴性最小，並且易於安裝。我們的基準測試也證明它的效能很高。因此，我們選擇了它，並最終對我們的選擇感到滿意。

同時，我們堅信有一天會達到極限。

隨著需求的增長

隨著時間的推移，我們獲得了更多的客戶、更多的 Kubernetes 叢集以及對平臺的更具體的要求。我們遇到了對更好的安全性、效能和可觀測性的日益增長的需求。這些需求適用於各種基礎設施元素，而網路顯然是其中之一。最終，我們意識到是時候轉向更高階的 CNI 外掛了。

許多問題促使我們跳到下一階段：

  1. 一家金融機構執行了嚴格的“預設禁止一切”規則。
  2. 一個廣泛使用的入口網站的叢集有大量的服務，這對 kube-proxy 產生了壓倒性的影響。
  3. PCI DSS 合規性要求另一個客戶實施靈活而強大的網路策略管理，並在其之上具有良好的可觀測性。
  4. 在 Flannel 使用的 iptables 和 netfilter 中，遇到大量傳入流量的多個其他應用程式面臨效能問題。

我們不能再受現有限制的阻礙，因此決定在我們的 Kubernetes 平臺中尋找另一個 CNI —— 一個可以應對所有新挑戰的 CNI。

為什麼選擇 Cilium

今天有很多可用的 CNI 選項。我們想堅持使用 eBPF，它被證明是一項強大的技術，在可觀測性、安全性等方面提供了許多好處。考慮到這一點，當您想到 CNI 外掛時，會出現兩個著名的專案：Cilium 和 Calico。

總的來說，他們兩個都非常棒。但是，我們仍然需要選擇其中之一。Cilium 似乎在社群中得到了更廣泛的使用和討論：更好的 GitHub 統計資料（例如 stars、forks 和 contributors）可以作為證明其價值的某種論據。它也是一個 CNCF 專案。雖然它不能保證太多，但這仍然是一個有效的觀點，所有事情都是平等的。

在閱讀了關於 Cilium 的各種文章後，我們決定嘗試一下，並在幾個不同的 K8s 叢集上進行了各種測試。事實證明，這是一次純粹的積極體驗，揭示了比我們預期更多的功能和好處。

我們喜歡的 Cilium 的主要功能

在考慮是否使用 Cilium 來解決我們遇到的上述問題時，我們喜歡 Cilium 的地方如下：

1. 效能

使用 bpfilter（而不是 iptables）進行路由意味著將過濾任務轉移到核心空間，這會產生令人印象深刻的效能提升。這正是專案設計、大量文章和第三方基準測試所承諾的。我們自己的測試證實，與我們之前使用的 Flannel + kube-proxy 相比，處理流量速度有顯著提升。


eBPF host-routing compared to using iptables. source: “CNI Benchmark: Understanding Cilium Network Performance”

有關此主題的有用資料包括：

  1. Why is the kernel community replacing iptables with BPF?
  2. BPF, eBPF, XDP and Bpfilter… What are These Things and What do They Mean for the Enterprise?
  3. kube-proxy Hybrid Modes

2. 更好的網路策略

CiliumNetworkPolicy CRD 擴充套件了 Kubernetes NetworkPolicy API。它帶來了 L7（而不僅僅是 L3/L4）網路策略支援網路策略中的 ingress 和 egress 以及 port ranges 規範等功能。

正如 Cilium 開發人員所說：“理想情況下，所有功能都將合併到標準資源格式中，並且不再需要此 CRD。”

3. 節點間流量控制

藉助 CiliumClusterwideNetworkPolicy ，您可以控制節點間流量。這些策略適用於整個叢集（非名稱空間），併為您提供將節點指定為源和目標的方法。它使過濾不同節點組之間的流量變得方便。

4. 策略執行模式

易於使用的 策略執行模式 讓生活變得更加輕鬆。 default 模式適合大多數情況：沒有初始限制，但一旦允許某些內容，其餘所有內容都會受到限制。Always* 模式 —— 當對所有端點執行策略時 —— 對於具有更高安全要求的環境很有幫助。

5. Hubble 及其 UI

Hubble 是一個真正出色的網路和服務可觀測性以及視覺渲染工具。具體來說，就是對流量進行監控，實時更新服務互動圖。您可以輕鬆檢視正在處理的請求、相關 IP、如何應用網路策略等。

現在舉幾個例子，說明如何在我的 Kubernetes 沙箱中使用 Hubble。首先，這裡我們有帶有 Ingress-NGINX 控制器的名稱空間。我們可以看到一個外部使用者透過 Dex 授權後進入了 Hubble UI。會是誰呢？...

現在，這裡有一個更有趣的例子：Hubble 花了大約一分鐘的時間視覺化 Prometheus 名稱空間如何與叢集的其餘部分通訊。您可以看到 Prometheus 從眾多服務中抓取了指標。多麼棒的功能！在您花費數小時為您的專案繪製所有這些基礎架構圖之前，您應該已經知道了！

6. 視覺化策略編輯器

此線上服務 提供易於使用、滑鼠友好的 UI 來建立規則並獲取相應的 YAML 配置以應用它們。我在這裡唯一需要抱怨的是缺少對現有配置進行反向視覺化的功能。

再此說明，這個列表遠非完整的 Cilium 功能集。這只是我根據我們的需要和我們最感興趣的內容做出的有偏見的選擇。

Cilium 為我們做了什麼

讓我們回顧一下我們的客戶遇到的具體問題，這些問題促使我們開始對在 Kubernetes 平臺中使用 Cilium 產生興趣。

第一種情況下的“預設禁止一切”規則是使用上述策略執行方式實現的。通常，我們會透過指定此特定環境中允許的內容的完整列表並禁止其他所有內容來依賴 default 模式。

以下是一些可能對其他人有幫助的相當簡單的策略示例。您很可能會有幾十個或數百個這樣的策略。

  1. 允許任何 Pod 訪問 Istio 端點：
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: all-pods-to-istio-internal-access
spec:
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: infra-istio
    toPorts:
    - ports:
      - port: "8443"
        protocol: TCP
  endpointSelector: {}
  1. 允許給定名稱空間內的所有流量：
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-ingress-egress-within-namespace
spec:
  egress:
  - toEndpoints:
    - {}
  endpointSelector: {}
  ingress:
  - fromEndpoints:
    - {}
  1. 允許 VictoriaMetrics 抓取給定名稱空間中的所有 Pod：
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: vmagent-allow-desired-namespace
spec:
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: desired-namespace
  endpointSelector:
    matchLabels:
      k8s:io.cilium.k8s.policy.serviceaccount: victoria-metrics-agent-usr
      k8s:io.kubernetes.pod.namespace: vmagent-system
  1. 允許 Kubernetes Metrics Server 訪問 kubelet 埠：
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: host-firewall-allow-metrics-server-to-kubelet
spec:
  ingress:
  - fromEndpoints:
    - matchLabels:
        k8s:io.cilium.k8s.policy.serviceaccount: metrics-server
        k8s:io.kubernetes.pod.namespace: my-metrics-namespace
    toPorts:
    - ports:
      - port: "10250"
        protocol: TCP
  nodeSelector:
    matchLabels: {}

至於其他問題，我們最初遇到的挑戰是：

  • 案例 #2 和 #4，由於基於 iptables 的網路堆疊效能不佳。我們提到的基準和我們執行的測試在實際操作中證明了自己。
  • Hubble 提供了足夠水平的可觀測性，這在案例 #3 中是必需的。

下一步是什麼？

總結這次經驗，我們成功解決了與 Kubernetes 網路相關的所有痛點。

關於 Cilium 的總體未來，我們能說些什麼？雖然它目前是一個孵化的 CNCF 專案，但它已於去年年底申請畢業。這需要一些時間才能完成，但這個專案正朝著一個非常明確的方向前進。最近，在 2023 年 2 月，Cilium 宣佈 透過了兩次安全審計，這是進一步畢業的重要一步。

我們正在關注該專案的路線圖，並等待一些功能和相關工具的實施或變得足夠成熟。（沒錯，Tetragon 將會很棒！）

例如，雖然我們在高流量叢集中使用 Kubernetes EndpointSlice CRD，但相關的Cilium 功能 目前處於 beta 階段 —— 因此，我們正在等待其穩定釋出。我們正在等待穩定的另一個測試版功能是 本地重定向策略，它將 Pod 流量本地重定向到節點內的另一個後端 Pod，而不是整個叢集內的隨機後端 Pod。

後記

在生產環境中確定了我們新的網路基礎設施並評估了它的效能和新功能之後，我們很高興決定採用 Cilium，因為它的好處是顯而易見的。對於多樣化且不斷變化的雲原生世界來說，這可能不是靈丹妙藥，而且絕不是最容易上手的技術。然而，如果你有動力、知識和一點冒險慾望，那麼它 100% 值得嘗試，而且很可能會得到多方面的回報。

相關文章