SIG-Networking：Kubernetes 網路政策 API 即將於 1.3 版本推出

編者註：本週我們將重點介紹 Kubernetes 特殊興趣小組 (SIG)；今天的文章是由 Network-SIG 團隊撰寫，介紹即將在 1.3 版本中推出的網路原則 API - 用於安全性、隔離和多租戶的原則。

Kubernetes 網路 SIG 自去年年底以來定期舉行會議，致力於將網路原則引入 Kubernetes，我們開始看到這項努力的成果。

許多使用者遇到的一個問題是，Kubernetes 的開放存取網路原則不適用於需要更精確控制存取 Pod 或服務流量的應用程式。如今，這可能是一個多層應用程式，流量僅允許來自層級的鄰近層級。但是，隨著透過組合微服務來建構新的雲原生應用程式，控制這些服務之間流量流動的能力變得更加關鍵。

在大多數 IaaS 環境（公共和私有）中，這種控制是透過允許 VM 加入「安全群組」來實現的，其中群組成員的流量由網路原則或存取控制列表 (ACL) 定義，並由網路封包過濾器強制執行。

網路 SIG 首先確定了 需要基本網路隔離以增強安全性的特定使用案例情境。為這些簡單且常見的使用案例制定正確的 API 非常重要，因為它們也是 Kubernetes 內多租戶所需更複雜網路原則的基礎。

從這些情境中，考慮了幾種可能的方法，並定義了最小的 原則規範。基本概念是，如果在每個命名空間的基礎上啟用隔離，則將選擇特定的 Pod，並允許特定的流量類型。

快速支援此實驗性 API 的最簡單方法是以 ThirdPartyResource 擴充 API Server 的形式，這在 Kubernetes 1.2 中是可行的。

如果您不熟悉其運作方式，可以透過定義 ThirdPartyResources 來擴充 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 形式發布時 - 將不再需要建立如上所示的 ThirdPartyResource 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" }

}

}

在此範例中，「tenant-a」命名空間將套用指示的「pol1」原則。具體而言，具有 segment 標籤「backend」的 Pod 將允許接收來自具有 segment 標籤「frontend」的 Pod 在連接埠 80 上的 TCP 流量。

如今，Romana、OpenShift、OpenContrail 和 Calico 支援套用至命名空間和 Pod 的網路原則。Cisco 和 VMware 也在努力實作。Romana 和 Calico 最近在 KubeCon 上使用 Kubernetes 1.2 展示了這些功能。您可以在此觀看他們的簡報：Romana (投影片)、Calico (投影片)。 

它是如何運作的？

每個解決方案都有其特定的實作細節。如今，它們依賴於某種主機上的強制執行機制，但未來的實作也可能建立在 Hypervisor 上，甚至直接由網路本身實作。 

外部原則控制軟體（具體細節因實作而異）將監看新的 API 端點，以了解是否正在建立 Pod 和/或套用新的原則。當發生需要原則組態的事件時，監聽器將識別變更，並且控制器將透過組態介面並套用原則來做出回應。 下圖顯示 API 監聽器和原則控制器透過主機代理程式在本機套用網路原則來回應更新。Pod 上的網路介面由主機上的 CNI 外掛程式組態（未顯示）。

如果您因為網路隔離和/或安全性問題而一直猶豫不決地使用 Kubernetes 開發應用程式，那麼這些新的網路原則在提供您所需的控制方面大有幫助。由於網路原則現在以實驗性 API 的形式提供，並作為 ThirdPartyResource 啟用，因此無需等到 Kubernetes 1.3。

如果您對 Kubernetes 和網路感興趣，可以透過幾種方式參與 - 加入我們：

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

網路「特殊興趣小組」，每週舉行兩次會議，太平洋時間下午 3 點 (15:00)，網址：SIG-Networking hangout。

• ←上一篇
下一篇→