SIG-Networking：Kubernetes 網路策略 API 即將在 1.3 中推出

編者按：本週我們將介紹Kubernetes 特別興趣小組；今天的文章由網路 SIG 團隊撰寫，介紹了 1.3 版本中即將推出的網路策略 API——用於安全、隔離和多租戶的策略。

Kubernetes 網路 SIG 自去年年底以來一直定期開會，致力於將網路策略引入 Kubernetes，我們開始看到這項工作的成果。

許多使用者面臨的一個問題是，Kubernetes 的開放訪問網路策略不適用於需要更精確控制訪問 Pod 或服務的流量的應用程式。目前，這可能是一個多層應用程式，流量只允許來自某層的相鄰層。但是，隨著新的雲原生應用程式透過組合微服務來構建，控制這些服務之間流量流動的能力變得更加關鍵。

在大多數 IaaS 環境（包括公共和私有）中，這種控制是透過允許虛擬機器加入“安全組”來實現的，其中對組內成員的流量由網路策略或訪問控制列表 (ACL) 定義，並由網路資料包過濾器強制執行。

網路 SIG 開始這項工作，首先確定了需要基本網路隔離以增強安全性的特定用例場景。正確地為這些簡單常見的用例設計 API 非常重要，因為它們也是 Kubernetes 內部多租戶所需更復雜網路策略的基礎。

根據這些場景，我們考慮了幾種可能的方法，並定義了一個最小的策略規範。基本思想是，如果啟用按名稱空間隔離，則將選擇特定的 Pod，並允許特定的流量型別。

快速支援此實驗性 API 的最簡單方法是使用第三方資源擴充套件 API 伺服器，這在 Kubernetes 1.2 中已可用。

如果您不熟悉其工作原理，Kubernetes API 可以透過定義第三方資源來擴充套件，這些資源在指定的 URL 建立新的 API 端點。

third-party-res-def.yaml

kind: ThirdPartyResource

apiVersion: extensions/v1beta1

metadata:

  name: network-policy.net.alpha.kubernetes.io

description: "Network policy specification"

versions:

- name: v1alpha1

$kubectl create -f third-party-res-def.yaml

這將建立一個 API 端點（每個名稱空間一個）

/net.alpha.kubernetes.io/v1alpha1/namespace/default/networkpolicys/

第三方網路控制器現在可以偵聽這些端點，並在資源建立、修改或刪除時按需作出響應。注意：隨著即將釋出的 Kubernetes 1.3 版本——當網路策略 API 以 Beta 形式釋出時——將不再需要建立如上所示的第三方資源 API 端點。 

網路隔離預設是關閉的，因此所有 Pod 都可以像往常一樣通訊。但是，重要的是要知道，一旦啟用網路隔離，所有名稱空間中所有 Pod 的所有流量都將被阻止，這意味著啟用隔離將改變 Pod 的行為

透過在名稱空間上定義 network-isolation 註解來啟用網路隔離，如下所示

net.alpha.kubernetes.io/network-isolation: [on | off]

啟用網路隔離後，必須應用明確的網路策略才能啟用 Pod 通訊。

可以將策略規範應用於名稱空間以定義策略的詳細資訊，如下所示

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/


{

"kind": "NetworkPolicy",

"metadata": {

"name": "pol1"

},

"spec": {

"allowIncoming": {

"from": [

{ "pods": { "segment": "frontend" } }

],

"toPorts": [

{ "port": 80, "protocol": "TCP" }

]

},

"podSelector": { "segment": "backend" }

}

}

在此示例中，將按照指示將策略“pol1”應用於“tenant-a”名稱空間。具體來說，帶有“backend”segment標籤的 Pod 將允許接收來自帶有“frontend”segment標籤的 Pod 的埠 80 上的 TCP 流量。

目前，Romana、OpenShift、OpenContrail 和 Calico 支援應用於名稱空間和 Pod 的網路策略。Cisco 和 VMware 也在開發實現。Romana 和 Calico 最近在 KubeCon 上展示了這些與 Kubernetes 1.2 結合使用的功能。您可以在這裡觀看他們的演示：Romana (幻燈片)、Calico (幻燈片)。 

它是如何工作的？

每個解決方案都有其自身的具體實施細節。目前，它們依賴於某種主機上的強制機制，但未來的實施也可以構建在虛擬機器管理程式上，甚至直接由網路本身應用策略。 

外部策略控制軟體（具體實現因供應商而異）將監視新的 API 端點，以瞭解 Pod 的建立和/或新策略的應用。當發生需要策略配置的事件時，監聽器將識別此更改，控制器將透過配置介面和應用策略來響應。下圖顯示了一個 API 監聽器和策略控制器透過主機代理在本地應用網路策略來響應更新。Pod 上的網路介面由主機上的 CNI 外掛配置（未顯示）。

如果您一直因為網路隔離和/或安全問題而遲遲未在 Kubernetes 上開發應用程式，那麼這些新的網路策略在提供您所需的控制方面大有裨益。無需等到 Kubernetes 1.3，因為網路策略現在作為實驗性 API 提供，並作為第三方資源啟用。

如果您對 Kubernetes 和網路感興趣，有多種參與方式——歡迎加入我們：

• 我們的 網路 Slack 頻道 
• 我們的 Kubernetes 網路特別興趣小組 郵件列表 

網路“特別興趣小組”，每兩週一次在太平洋時間下午3點（15:00）在 SIG-Networking 聚會上開會。

• ←上一篇
• 下一篇→