【Kubernetes】K8S 網絡隔離 方案

參考資料：

K8S-網絡隔離參考

OpenContrail is an open source network virtualization platform for the cloud. – Kube-O-Contrail – get your hands dirty with Kubernetes and OpenContrail

OpenContrail is an open source network virtualization platform for the cloud.

OpenContrail 體系架構文檔 - 飛翔的鷹的日志 - 網易部落格

opencontrail學習（一） - wanjia19870902的專欄 - 部落格頻道 - CSDN.NET

Calico - Project Calico Documentation

Make the Most from Kubernetes' New Network Policy API - The New Stack

Project Calico | A Pure Layer 3 Approach to Virtual Networking

Kubernetes叢集中的高性能網絡政策 - 好雨雲幫 - SegmentFault

romana/romana: The Romana Project - Installation scripts, documentation, issue tracker and wiki. Start here.

自從7月份釋出Kubernetes 1.3以來，使用者已經能夠在其叢集中定義和實施網絡政策。這些政策是防火牆規則，用于指定允許流入和流出的資料類型。如果需要，Kubernetes可以阻止所有未明确允許的流量。本文針對K8s的網絡政策進行介紹并對網絡性能進行測試。

網絡政策

K8s的網絡政策應用于通過常用标簽辨別的pod組。然後，可以使用标簽來模拟傳統的分段網絡，這些網絡通常用于在多層應用程式中隔離層：例如，您可以通過特定的“段”标簽來辨別前端和後端pod。政策控制這些段之間的流量，甚至控制來自外部源的流量。

分段流量

這對于應用程式開發人員意味着什麼？最後，Kubernetes獲得了提供 深度防禦) 的必要能力。流量可以分段，應用程式的不同部分可以獨立保護。例如，您可以通過特定的網絡政策非常輕松地保護每個服務：由伺服器後的Replication Controller辨別的所有窗格都已由特定标簽辨別。是以，您可以使用同一标簽将政策應用于這些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規則應用。這個結果是一個高性能，易于管理的網絡。

測試網絡政策的性能影響

在應用網絡政策之後，需要根據這些政策來檢查網絡分組，以驗證這種類型的業務是允許的。但是，對每個資料包應用網絡政策的性能損失是多少？我們可以使用所有的政策功能，而不會影響應用程式性能？我們決定通過運作一些測試來找出。

在深入研究這些測試之前，值得一提的是，“性能”是一個棘手的測量，網絡性能尤其如此。吞吐量（即以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或任何其他伺服器配合使用。

總結

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

好雨雲幫目前的生産環境使用的是k8s 1.2.x版本，我們在使用個版本的時候k8s還沒有網絡政策控制的功能，是以我們是基于網絡插件的方式來實作通路控制的。

我們正在進行k8s 1.3.x版本生産環境的性能及相容性測試，随後會将所有的企業版本中進行更新，社群版會在企業版更新後的當月25日進行更新。

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

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