国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

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

U2FsdGVkX1x / 2450人閱讀

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

自從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

譯者：云盟認證成員 JCH

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/27951.html

相關文章

  • Kubernetes集群中的高性能網絡策略

    摘要：自從月份發布以來，用戶已經能夠在其集群中定義和實施網絡策略。吞吐量即以測量的數據傳輸速度和延遲完成請求的時間是網絡性能的常用度量。文章網絡延遲和比較的網絡方案已經檢查了運行覆蓋網絡對吞吐量和延遲的性能影響。 自從7月份發布Kubernetes 1.3以來，用戶已經能夠在其集群中定義和實施網絡策略。這些策略是防火墻規則，用于指定允許流入和流出的數據類型。如果需要，Kubernetes可以...

    tanglijun 評論0 收藏0

  • Kubernetes CNI網絡最強對比：Flannel、Calico、Canal和Weave

    摘要：第層網絡的一個值得注意的示例是以太網，其中表示為子層。與其他方案相比，相對容易安裝和配置。與不同，不使用網絡。網絡策略是其最受追捧的功能之一。 本文將在介紹技術原理和相應術語的基礎上，再集中探索與詳細對比目前最流行的CNI插件：Flannel、Calico、Weave和Canal，對比介紹它們的原理、使用方法、適用場景和優缺點等。 showImg(https://segmentfaul...

    scq000 評論0 收藏0

  • Kubernetes CNI網絡最強對比：Flannel、Calico、Canal和Weave

    摘要：第層網絡的一個值得注意的示例是以太網，其中表示為子層。與其他方案相比，相對容易安裝和配置。與不同，不使用網絡。網絡策略是其最受追捧的功能之一。 本文將在介紹技術原理和相應術語的基礎上，再集中探索與詳細對比目前最流行的CNI插件：Flannel、Calico、Weave和Canal，對比介紹它們的原理、使用方法、適用場景和優缺點等。 showImg(https://segmentfaul...

    Noodles 評論0 收藏0

  • Kubernetes在宜信落地實踐

    摘要：容器云的背景伴隨著微服務的架構的普及，結合開源的和等微服務框架，宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。 容器云的背景 伴隨著微服務的架構的普及，結合開源的Dubbo和Spring Cloud等微服務框架，宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態到無狀態，具體來說將業務狀態數據如：會話、用戶數據等存儲到中間件中服務中。 showI...

    fxp 評論0 收藏0

  • Kubernetes在宜信落地實踐

    摘要：容器云的背景伴隨著微服務的架構的普及，結合開源的和等微服務框架，宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。 容器云的背景 伴隨著微服務的架構的普及，結合開源的Dubbo和Spring Cloud等微服務框架，宜信內部很多業務線逐漸了從原來的單體架構逐漸轉移到微服務架構。應用從有狀態到無狀態，具體來說將業務狀態數據如：會話、用戶數據等存儲到中間件中服務中。 showI...

    Labradors 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<