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

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

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

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

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

然而，在網(wǎng)絡(luò)策略之前，這種對容器的隔離是不可能的。VXLAN覆蓋可以提供簡單的網(wǎng)絡(luò)隔離，但是應(yīng)用程序開發(fā)人員需要對流量訪問pod進行更細粒度的控制。從這個簡單的例子可以看出，Kubernetes網(wǎng)絡(luò)策略可以根據(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)絡(luò)策略是一個令人興奮的功能，Kubernetes社區(qū)已經(jīng)工作了很長時間。但是，它需要一個能夠應(yīng)用策略的網(wǎng)絡(luò)后端。例如，簡單路由網(wǎng)絡(luò)或常用的 flannel 網(wǎng)絡(luò)程序本身不能應(yīng)用網(wǎng)絡(luò)策略。

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

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

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

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

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

硬件

兩臺服務(wù)器采用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

客戶端和服務(wù)器負載測試軟件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

譯者：云盟認(rèn)證成員 JCH