# Kubernetes集羣中的高性能網絡策略

時間 2019-11-06

原文原文鏈接

Kubernetes集羣中的高性能網絡策略

自從7月份發佈Kubernetes 1.3以來，用戶已經可以在其集羣中定義和實施網絡策略。這些策略是防火牆規則，用於指定容許流入和流出的數據類型。若是須要，Kubernetes能夠阻止全部未明確容許的流量。本文針對K8s的網絡策略進行介紹並對網絡性能進行測試。php

網絡策略

K8s的網絡策略應用於經過經常使用標籤標識的pod組。而後，可使用標籤來模擬傳統的分段網絡，這些網絡一般用於在多層應用程序中隔離層：例如，您能夠經過特定的「段」標籤來標識前端和後端pod。策略控制這些段之間的流量，甚至控制來自外部源的流量。html

分段流量

這對於應用程序開發人員意味着什麼？最後，Kubernetes得到了提供深度防護的必要能力。流量能夠分段，應用程序的不一樣部分能夠獨立保護。例如，您能夠經過特定的網絡策略很是輕鬆地保護每一個服務：由服務器後的Replication Controller標識的全部窗格都已由特定標籤標識。所以，您可使用同一標籤將策略應用於這些pod。前端

長期以來，深度防護被建議做爲最佳實踐。在AWS和OpenStack上，經過將安全組應用於VM，能夠輕鬆實現應用程序的不一樣部分或層之間的這種隔離。git

然而，在網絡策略以前，這種對容器的隔離是不可能的。VXLAN覆蓋能夠提供簡單的網絡隔離，可是應用程序開發人員須要對流量訪問pod進行更細粒度的控制。從這個簡單的例子能夠看出，Kubernetes網絡策略能夠根據源和源頭，協議和端口來管理流量。github

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還包括網絡策略功能。api

咱們選擇Romana做爲這些測試的後端，由於它將pod配置爲在完整L3配置中使用本地可路由的IP地址。所以，網絡策略能夠直接由Linux內核中的主機使用iptables規則應用。這個結果是一個高性能，易於管理的網絡。安全

測試網絡策略的性能影響

在應用網絡策略以後，須要根據這些策略來檢查網絡分組，以驗證這種類型的業務是容許的。可是，對每一個數據包應用網絡策略的性能損失是多少？咱們可使用全部的策略功能，而不會影響應用程序性能？咱們決定經過運行一些測試來找出。服務器

在深刻研究這些測試以前，值得一提的是，「性能」是一個棘手的測量，網絡性能尤爲如此。吞吐量（即以Gpbs測量的數據傳輸速度）和延遲（完成請求的時間）是網絡性能的經常使用度量。文章：K8s網絡延遲和比較k8s的網絡方案已經檢查了運行覆蓋網絡對吞吐量和延遲的性能影響。咱們從這些測試中學到的是Kubernetes網絡一般至關快，服務器沒有麻煩使1G鏈路飽和，有或沒有覆蓋。只有當你有10G網絡，你須要開始思考封裝的開銷。網絡

這是由於在典型的網絡性能基準測試期間，沒有用於主機CPU執行的應用邏輯，使得它可用於任何須要的網絡處理。**爲此，咱們在不使鏈路或CPU飽和的操做範圍內運行咱們的測試。這具備隔離處理網絡策略規則對主機的影響的效果。**對於這些測試，咱們決定測量由在一系列響應大小範圍內完成HTTP請求所需的平均時間來衡量的延遲。

測試步驟：

硬件

兩臺服務器採用IntelCore i5-5250U CPU（2核，每核2個線程），運行速度1.60GHz，16GBRAM和512GB SSD。

NIC：Intel以太網鏈接I218-V（rev 03）
Ubuntu14.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網絡策略僅適用於入口流量。這意味着傳出的流量不受影響。

首先，咱們進行了沒有任何政策的測試來創建基線。而後，咱們再次運行測試，增長測試網段的策略數量。策略是常見的「容許給定協議和端口的流量」格式。爲了確保數據包必須遍歷全部策略，咱們建立了一些不匹配數據包的策略，最後是一個將致使接受數據包的策略。

下表顯示不一樣請求大小和策略數量的結果（以毫秒爲單位）：

咱們在這裏看到的是，隨着策略數量的增長，即便在應用200個策略以後，處理網絡策略也會引入很是小的延遲，毫不會超過0.2ms。爲了全部實際目的，當應用網絡策略時不引入有意義的延遲。還值得注意的是，響應大小從0.5k增長到1.0k幾乎沒有效果。這是由於對於很是小的響應，建立新鏈接的固定開銷支配總體響應時間（即傳送相同數量的分組）。

注意： 0.5k和1k線在上圖中的〜.8ms重疊

即便做爲基準性能的一個百分比，影響仍然很小。下表顯示，對於最小響應大小，最差狀況下的延遲保持在7％或更小，最多200個策略。對於較大的響應大小，延遲降低到約1％。

在這些結果中還感興趣的是，隨着策略數量的增長，咱們注意到較大的請求經歷較小的相對（即百分比）性能降級。

這是由於當Romana安裝iptables規則時，它確保首先評估屬於已創建鏈接的數據包。僅須要遍歷鏈接的第一個數據包的完整策略列表。以後，鏈接被認爲「創建」，而且鏈接的狀態被存儲在快速查找表中。所以，對於較大的請求，鏈接的大多數數據包都將在「已創建」表中進行快速查找，而不是對全部規則進行徹底遍歷。這個iptables優化結果的性能在很大程度上獨立於網絡策略的數量。

這樣的「流表」是網絡設備中的常見優化，彷佛iptables使用相同的技術至關有效。

它還值得注意的是，在實踐中，一個至關複雜的應用程序能夠爲每一個段配置幾打規則。一樣的，諸如Websockets和持久鏈接之類的公共網絡優化技術甚至會進一步提升網絡策略的性能（特別是對於小請求大小），由於鏈接保持打開時間更長，所以能夠從已創建的鏈接優化中受益。

這些測試是使用Romana做爲後端策略提供程序執行的，其餘網絡策略實現可能會產生不一樣的結果。可是，這些測試顯示，對於幾乎每一個應用程序部署情形，可使用Romana做爲網絡後端應用網絡策略，而不會對性能產生任何負面影響。

若是你想本身嘗試，咱們建議使用Romana。在咱們的GitHub代碼倉庫中，您能夠找到一個易於使用的安裝程序，它與AWS，Vagrant VM或任何其餘服務器配合使用。