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

網路政策

自 7 月發布 Kubernetes 1.3 以來，使用者已經能夠在其叢集中定義和實施網路政策。這些政策是防火牆規則，指定允許進出 Pod 以及 Pod 之間流量的類型。如果要求，Kubernetes 會封鎖所有未明確允許的流量。政策會應用於由通用標籤識別的 Pod 群組。然後，標籤可用於模仿傳統的分段網路，這些網路通常用於隔離多層應用程式中的層：例如，您可以使用特定的「區段」標籤來識別您的前端和後端 Pod。政策控制這些區段之間的流量，甚至控制進出外部來源的流量。

區隔流量

這對應用程式開發人員意味著什麼？最終，Kubernetes 獲得了提供「縱深防禦」的必要能力。流量可以分段，並且應用程式的不同部分可以獨立地受到保護。例如，您可以非常輕鬆地透過特定的網路政策來保護您的每個服務：服務後面的 副本控制器 識別的所有 Pod 已經透過特定的標籤識別。因此，您可以使用相同的標籤將政策應用於這些 Pod。

長期以來，縱深防禦一直被推薦為最佳實務。在 AWS 和 OpenStack 上，透過將安全群組應用於 VM，可以輕鬆實現應用程式不同部分或層之間的這種隔離。

然而，在網路政策之前，容器的這種隔離是不可能的。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 RAM 和 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 請求。HTTP 請求由客戶端 Pod 以確保伺服器和網路永遠不會飽和的速率發送。我們還透過停用持久連線（即 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 實際上沒有任何影響。這是因為對於非常小的響應，建立新連線的固定開銷主導了整體響應時間（即傳輸了相同數量的封包）。

注意：.5k 和 1k 線在上面的圖表中在約 ~.8ms 處重疊

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

響應大小

在這些結果中也很有趣的是，隨著政策數量的增加，我們注意到較大的請求經歷了較小的相對（即百分比）效能下降。

這是因為當 Romana 安裝 iptables 規則時，它確保首先評估屬於已建立連線的封包。只有在連線的第一個封包時才需要遍歷完整的政策列表。之後，連線被視為「已建立」，並且連線的狀態儲存在快速查找表中。因此，對於較大的請求，連線的大多數封包都是透過在「已建立」表中快速查找來處理的，而不是完整遍歷所有規則。這種 iptables 優化導致效能在很大程度上獨立於網路政策的數量。

這種「流表」是網路設備中的常見優化，並且 iptables 看起來非常有效地使用了相同的技術。

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

這些測試是使用 Romana 作為後端政策提供者執行的，而其他網路政策實作可能會產生不同的結果。然而，這些測試顯示，幾乎在所有應用程式部署情境中，都可以使用 Romana 作為網路後端來應用網路政策，而不會對效能產生任何負面影響。

如果您想親自試用，我們邀請您查看 Romana。在我們的 GitHub 儲存庫中，您可以找到一個易於使用的安裝程式，它適用於 AWS、Vagrant 虛擬機器或任何其他伺服器。您可以使用它快速開始使用由 Romana 驅動的 Kubernetes 或 OpenStack 叢集。

• ←上一頁
下一頁→