Kubernetes 叢集中的高效能網路策略

網路策略

自 Kubernetes 1.3 版本於七月釋出以來，使用者已能夠在他們的叢集中定義和實施網路策略。這些策略是防火牆規則，用於指定允許進入、傳出和 Pod 之間傳輸的流量型別。如果需要，Kubernetes 會阻止所有未明確允許的流量。策略應用於由通用標籤標識的 Pod 組。然後可以使用標籤來模擬傳統的分段網路，這些網路通常用於隔離多層應用程式中的層：例如，您可以透過特定的“segment”標籤來標識您的前端和後端 Pod。策略控制這些段之間的流量，甚至控制進出外部源的流量。

分段流量

這對應用程式開發者意味著什麼？Kubernetes 終於獲得了提供“深度防禦”的必要能力。流量可以分段，並且應用程式的不同部分可以獨立地進行安全保護。例如，您可以透過特定的網路策略非常容易地保護您的每個服務：由Replication Controller標識的所有位於服務後面的 Pod 都已由特定標籤標識。因此，您可以使用相同的標籤將策略應用於這些 Pod。

深度防禦長期以來一直被推薦為最佳實踐。這種在應用程式不同部分或層之間進行隔離的方法在 AWS 和 OpenStack 上透過將安全組應用於虛擬機器很容易實現。

然而，在網路策略出現之前，容器的這種隔離是不可能的。VXLAN 疊加層可以提供簡單的網路隔離，但應用程式開發者需要對訪問 Pod 的流量進行更細粒度的控制。正如您在這個簡單的示例中看到的，Kubernetes 網路策略可以根據來源和出處、協議和埠來管理流量。

apiVersion: extensions/v1beta1  
kind: NetworkPolicy  
metadata:  
 name: pol1  
spec:  
 podSelector:  
   matchLabels:  
     role: backend  
 ingress:  
 - from:  
   - podSelector:  
      matchLabels:  
       role: frontend  
   ports:  
   - protocol: tcp  
     port: 80

並非所有網路後端都支援策略

網路策略是一個令人興奮的功能，Kubernetes 社群為此付出了長時間的努力。然而，它需要一個能夠應用策略的網路後端。例如，簡單的路由網路或常用的 flannel 網路驅動本身無法應用網路策略。

目前只有少數支援策略的網路後端可用於 Kubernetes：Romana、Calico 和 Canal；Weave 也表示將在不久的將來提供支援。Red Hat 的 OpenShift 也包含網路策略功能。

我們選擇 Romana 作為這些測試的後端，因為它將 Pod 配置為在完整的 L3 配置中使用本地可路由的 IP 地址。因此，網路策略可以直接由主機在 Linux 核心中使用 iptables 規則應用。這使得網路具有高效能且易於管理。

測試網路策略的效能影響

應用網路策略後，需要對照這些策略檢查網路資料包，以驗證此類流量是否允許。但是，對每個資料包應用網路策略會帶來什麼效能損失呢？我們能否在不影響應用程式效能的情況下使用所有強大的策略功能？我們決定透過執行一些測試來找出答案。

在我們深入研究這些測試之前，值得一提的是，“效能”是一個很難衡量的東西，網路效能尤其如此。

吞吐量（即以 Gbps 為單位測量的資料傳輸速度）和延遲（完成請求所需的時間）是衡量網路效能的常見指標。之前已在此處和此處對執行覆蓋網路對吞吐量和延遲的效能影響進行了研究。我們從這些測試中瞭解到，Kubernetes 網路通常非常快，伺服器在有或沒有覆蓋網路的情況下都可以輕鬆地使 1G 鏈路飽和。只有當您擁有 10G 網路時，才需要開始考慮封裝的開銷。

這是因為在典型的網路效能基準測試中，主機 CPU 沒有應用程式邏輯需要執行，因此可以用於任何所需的網路處理。因此，我們選擇在不會使鏈路或 CPU 飽和的操作範圍內執行測試。這隔離了在主機上處理網路策略規則的影響。對於這些測試，我們決定測量延遲，即透過在一系列響應大小下完成 HTTP 請求所需的平均時間來衡量。

測試設定

• 硬體：兩臺伺服器，配備 Intel Core i5-5250U CPU（2 核，每核 2 執行緒），執行頻率為 1.60GHz，16GB 記憶體和 512GB SSD。網絡卡：Intel Ethernet Connection I218-V (rev 03)
• Ubuntu 14.04.5
• 用於資料收集的 Kubernetes 1.3（在 v1.4.0-beta.5 上驗證的樣本）
• Romana v0.9.3.1
• 客戶端和伺服器負載測試軟體

在測試中，我們讓客戶端 Pod 向伺服器 Pod 傳送 2,000 個 HTTP 請求。客戶端 Pod 以確保伺服器和網路都不會飽和的速率傳送 HTTP 請求。我們還透過停用持久連線（即 HTTP keep-alive）來確保每個請求都啟動一個新的 TCP 會話。我們對不同響應大小的每個測試執行，並測量平均請求持續時間（完成該大小的請求需要多長時間）。最後，我們使用不同的策略配置重複每組測量。

Romana 在建立 Kubernetes 網路策略時檢測到它們，將其轉換為 Romana 自己的策略格式，然後將它們應用於所有主機。目前，Kubernetes 網路策略僅適用於入站流量。這意味著出站流量不受影響。

首先，我們在沒有任何策略的情況下進行測試以建立基線。然後，我們再次執行測試，增加測試網路段的策略數量。策略採用常見的“允許給定協議和埠的流量”格式。為了確保資料包必須遍歷所有策略，我們建立了多個與資料包不匹配的策略，最後建立了一個會導致資料包被接受的策略。

下表顯示了結果，以毫秒為單位測量，適用於不同請求大小和策略數量

響應大小

|策略 |.5k |1k |10k |100k |1M | |---|---|---|---|---| |0 |0.732 |0.738 |1.077 |2.532 |10.487 | |10 |0.744 |0.742 |1.084 |2.570 |10.556 | |50 |0.745 |0.755 |1.086 |2.580 |10.566 | |100 |0.762 |0.770 |1.104 |2.640 |10.597 | |200 |0.783 |0.783 |1.147 |2.652 |10.677 |

我們在這裡看到的是，隨著策略數量的增加，處理網路策略會引入非常小的延遲，即使在應用 200 個策略後，也從未超過 0.2 毫秒。對於所有實際目的，應用網路策略時不會引入任何有意義的延遲。同樣值得注意的是，將響應大小從 0.5k 增加到 1.0k 幾乎沒有影響。這是因為對於非常小的響應，建立新連線的固定開銷在總體響應時間中佔據主導地位（即傳輸相同數量的資料包）。

注意：上圖中 0.5k 和 1k 的線條在約 0.8 毫秒處重疊

即使作為基線效能的百分比，影響仍然非常小。下表顯示，對於最小的響應大小，最壞情況下的延遲在多達 200 個策略的情況下仍保持在 7% 或更少。對於較大的響應大小，延遲下降到約 1%。

響應大小

這些結果中另一個有趣之處是，隨著策略數量的增加，我們注意到較大的請求所經歷的相對（即百分比）效能下降較小。

這是因為當 Romana 安裝 iptables 規則時，它確保屬於已建立連線的資料包首先被評估。只有對於連線的第一個資料包，才需要遍歷完整的策略列表。此後，該連線被視為“已建立”，並且連線的狀態儲存在一個快速查詢表中。因此，對於較大的請求，連線的大多數資料包都透過在“已建立”表中進行快速查詢來處理，而不是完全遍歷所有規則。這種 iptables 最佳化使得效能在很大程度上獨立於網路策略的數量。

這種“流表”是網路裝置中常見的最佳化，看來 iptables 也非常有效地使用了相同的技術。

同樣值得注意的是，在實踐中，一個相當複雜的應用程式可能為每個段配置幾十條規則。常見的網路最佳化技術（如 Websockets 和持久連線）將進一步提高網路策略的效能（特別是對於小請求大小），因為連線保持開啟時間更長，因此可以從已建立連線的最佳化中受益。

這些測試是使用 Romana 作為後端策略提供商進行的，其他網路策略實現可能會產生不同的結果。然而，這些測試表明，對於幾乎所有應用程式部署場景，都可以使用 Romana 作為網路後端來應用網路策略，而不會對效能產生任何負面影響。

如果您想親自嘗試，我們邀請您檢視 Romana。在我們的 GitHub 倉庫中，您可以找到一個易於使用的安裝程式，它適用於 AWS、Vagrant VM 或任何其他伺服器。您可以使用它快速開始使用由 Romana 支援的 Kubernetes 或 OpenStack 叢集。

• ←上一篇
• 下一篇→