摘要：自從月份發(fā)布以來，用戶已經(jīng)能夠在其集群中定義和實施網(wǎng)絡策略。吞吐量即以測量的數(shù)據(jù)傳輸速度和延遲完成請求的時間是網(wǎng)絡性能的常用度量。文章網(wǎng)絡延遲和比較的網(wǎng)絡方案已經(jīng)檢查了運行覆蓋網(wǎng)絡對吞吐量和延遲的性能影響。

自從7月份發(fā)布Kubernetes 1.3以來，用戶已經(jīng)能夠在其集群中定義和實施網(wǎng)絡策略。這些策略是防火墻規(guī)則，用于指定允許流入和流出的數(shù)據(jù)類型。如果需要，Kubernetes可以阻止所有未明確允許的流量。本文針對K8s的網(wǎng)絡策略進行介紹并對網(wǎng)絡性能進行測試。

K8s的網(wǎng)絡策略應用于通過常用標簽標識的pod組。然后，可以使用標簽來模擬傳統(tǒng)的分段網(wǎng)絡，這些網(wǎng)絡通常用于在多層應用程序中隔離層：例如，您可以通過特定的“段”標簽來標識前端和后端pod。策略控制這些段之間的流量，甚至控制來自外部源的流量。

這對于應用程序開發(fā)人員意味著什么？最后，Kubernetes獲得了提供 深度防御) 的必要能力。流量可以分段，應用程序的不同部分可以獨立保護。例如，您可以通過特定的網(wǎng)絡策略非常輕松地保護每個服務：由服務器后的Replication Controller標識的所有窗格都已由特定標簽標識。因此，您可以使用同一標簽將策略應用于這些pod。

長期以來，深度防御被建議作為最佳實踐。在AWS和OpenStack上，通過將安全組應用于VM，可以輕松實現(xiàn)應用程序的不同部分或層之間的這種隔離。

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

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

網(wǎng)絡策略是一個令人興奮的功能，Kubernetes社區(qū)已經(jīng)工作了很長時間。但是，它需要一個能夠應用策略的網(wǎng)絡后端。例如，簡單路由網(wǎng)絡或常用的 flannel 網(wǎng)絡程序本身不能應用網(wǎng)絡策略。

今天Kubernetes只有幾個具有政策功能的網(wǎng)絡組件：Romana，Calico和Canal;與Weave在不久的將來指示支持。 Red Hat的OpenShift還包括網(wǎng)絡策略功能。

我們選擇Romana作為這些測試的后端，因為它將pod配置為在完整L3配置中使用本地可路由的IP地址。因此，網(wǎng)絡策略可以直接由Linux內核中的主機使用iptables規(guī)則應用。這個結果是一個高性能，易于管理的網(wǎng)絡。

在應用網(wǎng)絡策略之后，需要根據(jù)這些策略來檢查網(wǎng)絡分組，以驗證這種類型的業(yè)務是允許的。但是，對每個數(shù)據(jù)包應用網(wǎng)絡策略的性能損失是多少？我們可以使用所有的策略功能，而不會影響應用程序性能？我們決定通過運行一些測試來找出。

在深入研究這些測試之前，值得一提的是，“性能”是一個棘手的測量，網(wǎng)絡性能尤其如此。吞吐量（即以Gpbs測量的數(shù)據(jù)傳輸速度）和延遲（完成請求的時間）是網(wǎng)絡性能的常用度量。文章：K8s網(wǎng)絡延遲和比較k8s的網(wǎng)絡方案已經(jīng)檢查了運行覆蓋網(wǎng)絡對吞吐量和延遲的性能影響。我們從這些測試中學到的是Kubernetes網(wǎng)絡通常相當快，服務器沒有麻煩使1G鏈路飽和，有或沒有覆蓋。只有當你有10G網(wǎng)絡，你需要開始思考封裝的開銷。

這是因為在典型的網(wǎng)絡性能基準測試期間，沒有用于主機CPU執(zhí)行的應用邏輯，使得它可用于任何需要的網(wǎng)絡處理。為此，我們在不使鏈路或CPU飽和的操作范圍內運行我們的測試。這具有隔離處理網(wǎng)絡策略規(guī)則對主機的影響的效果。對于這些測試，我們決定測量由在一系列響應大小范圍內完成HTTP請求所需的平均時間來衡量的延遲。

硬件

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

NIC：Intel以太網(wǎng)連接I218-V（rev 03）

Ubuntu14.04.5?

Kubernetes 1.3（v1.4.0-beta.5上的驗證樣本）

Romana v0.9.3.1

客戶端和服務器負載測試軟件。

對于測試，我們有一個客戶端pod向服務器pod發(fā)送2,000個HTTP請求。 HTTP請求由客戶端pod以確保服務器和網(wǎng)絡均未飽和的速率發(fā)送。我們還確保每個請求通過禁用持久連接（如 HTTP 的Keep-alive）啟動一個新的TCP會話。我們使用不同的響應大小運行每個測試，并測量平均請求持續(xù)時間（完成該大小的請求需要多長時間）。最后，我們用不同的策略配置重復每組測量。

Romana檢測Kubernetes網(wǎng)絡策略創(chuàng)建時，將其轉換為Romana自己的策略格式，然后將其應用于所有主機。目前，Kubernetes網(wǎng)絡策略僅適用于入口流量。這意味著傳出的流量不受影響。

首先，我們進行了沒有任何政策的測試來建立基線。然后，我們再次運行測試，增加測試網(wǎng)段的策略數(shù)量。策略是常見的“允許給定協(xié)議和端口的流量”格式。為了確保數(shù)據(jù)包必須遍歷所有策略，我們創(chuàng)建了一些不匹配數(shù)據(jù)包的策略，最后是一個將導致接受數(shù)據(jù)包的策略。

下表顯示不同請求大小和策略數(shù)量的結果（以毫秒為單位）：

我們在這里看到的是，隨著策略數(shù)量的增加，即使在應用200個策略之后，處理網(wǎng)絡策略也會引入非常小的延遲，絕不會超過0.2ms。為了所有實際目的，當應用網(wǎng)絡策略時不引入有意義的延遲。還值得注意的是，響應大小從0.5k增加到1.0k幾乎沒有效果。這是因為對于非常小的響應，創(chuàng)建新連接的固定開銷支配整體響應時間（即傳送相同數(shù)量的分組）。

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

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

在這些結果中還感興趣的是，隨著策略數(shù)量的增加，我們注意到較大的請求經(jīng)歷較小的相對（即百分比）性能降級。

這是因為當Romana安裝iptables規(guī)則時，它確保首先評估屬于已建立連接的數(shù)據(jù)包。僅需要遍歷連接的第一個數(shù)據(jù)包的完整策略列表。之后，連接被認為“建立”，并且連接的狀態(tài)被存儲在快速查找表中。因此，對于較大的請求，連接的大多數(shù)數(shù)據(jù)包都將在“已建立”表中進行快速查找，而不是對所有規(guī)則進行完全遍歷。這個iptables優(yōu)化結果的性能在很大程度上獨立于網(wǎng)絡策略的數(shù)量。

這樣的“流表”是網(wǎng)絡設備中的常見優(yōu)化，似乎iptables使用相同的技術相當有效。

它還值得注意的是，在實踐中，一個相當復雜的應用程序可以為每個段配置幾打規(guī)則。同樣的，諸如Websockets和持久連接之類的公共網(wǎng)絡優(yōu)化技術甚至會進一步提高網(wǎng)絡策略的性能（特別是對于小請求大?。?，因為連接保持打開時間更長，因此可以從已建立的連接優(yōu)化中受益。?

這些測試是使用Romana作為后端策略提供程序執(zhí)行的，其他網(wǎng)絡策略實現(xiàn)可能會產(chǎn)生不同的結果。但是，這些測試顯示，對于幾乎每個應用程序部署情形，可以使用Romana作為網(wǎng)絡后端應用網(wǎng)絡策略，而不會對性能產(chǎn)生任何負面影響。?

如果你想自己嘗試，我們建議使用Romana。在我們的GitHub代碼倉庫中，您可以找到一個易于使用的安裝程序，它與AWS，Vagrant VM或任何其他服務器配合使用。

通過以上的功能介紹和測試分析，k8s可以對應用之間流量以更小的顆粒度進行控制。網(wǎng)絡性能損耗在可以接受的范圍之內。

好雨云幫目前的生產(chǎn)環(huán)境使用的是k8s 1.2.x版本，我們在使用個版本的時候k8s還沒有網(wǎng)絡策略控制的功能，因此我們是基于網(wǎng)絡插件的方式來實現(xiàn)訪問控制的。

我們正在進行k8s 1.3.x版本生產(chǎn)環(huán)境的性能及兼容性測試，隨后會將所有的企業(yè)版本中進行升級，社區(qū)版會在企業(yè)版升級后的當月25日進行升級。

后續(xù)我會針對calico與k8s結合的方式來完成網(wǎng)絡互通和網(wǎng)絡的隔離控制并對性能的損耗進行測試分析，在以后的文章中我會把測試的情況跟大家分享和討論。

原文鏈接：http://blog.kubernetes.io/2016/09/high-performance-network-policies-kubernetes.html

譯者：云盟認證成員 JCH