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

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

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

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

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

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

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

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

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

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

這是因?yàn)樵诘湫偷木W(wǎng)絡(luò)性能基準(zhǔn)測(cè)試期間，沒有用于主機(jī)CPU執(zhí)行的應(yīng)用邏輯，使得它可用于任何需要的網(wǎng)絡(luò)處理。為此，我們?cè)诓皇规溌坊駽PU飽和的操作范圍內(nèi)運(yùn)行我們的測(cè)試。這具有隔離處理網(wǎng)絡(luò)策略規(guī)則對(duì)主機(jī)的影響的效果。對(duì)于這些測(cè)試，我們決定測(cè)量由在一系列響應(yīng)大小范圍內(nèi)完成HTTP請(qǐng)求所需的平均時(shí)間來衡量的延遲。

硬件

兩臺(tái)服務(wù)器采用IntelCore i5-5250U CPU（2核，每核2個(gè)線程），運(yùn)行速度1.60GHz，16GBRAM和512GB SSD。

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

Ubuntu14.04.5?

Kubernetes 1.3（v1.4.0-beta.5上的驗(yàn)證樣本）

Romana v0.9.3.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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