K8S 1.3中將引入的網絡策略API的示例分析

K8S 1.3中將引入的網絡策略API的示例分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

Kubernetes SIG小組自去年年底以來一直頻繁開會，旨在給Kubernetes添加網絡策略，也收獲很多進展。

很多用戶都遇到過一個問題，就是Kubernetes的開放網絡策略對于有些程序是不合適的，比如那些需要更精確控制流量來問訪問pod或者service的程序。現在，這可能是一個只允許流量從隔壁層流過來的多層應用程序。但是隨著新的云原生應用組合著微服務的產生，控制信息流量在這些service間的流動的能力變得愈發重要。

網絡SIG小組努力搭建，從識別特定的需要網絡隔離增強安全性的案例場景（網址）著手。正確獲得這些簡單使用案例的API對于工作十分重要，因為這也是更加復雜的網絡協議的基礎，對于Kubernetes里面的多租戶來說十分重要。

從這些場景中，一些可行的辦法早就想到了，最小的策略規范已經被定義好了。基礎的想法就是，如果每個命名空間之間開啟隔離，那么特殊pods之間的通信就需要啟用特定的策略。

要快速支持這個實驗的API最簡單的方法就是以第三方資源拓展（ThirdPartyResource）的形式到API服務器，Kubernetes 1.2 現在已經支持了。

如果對這個運行不熟悉，Kubernetes API可以通過定義第三方資源（ThirdPartyResources）拓展，在指定的URL上創建一個新的API端點。

這樣就可以創建一個API端點（每個命名空間一個）：

第三方網絡控制器可以在這些端點上監聽，當資源被創建、修改或者刪除的時候作出必要的回應。注意：kubernetes 1.3版本即將發布，網絡策略API會以測試版的形式發布，那么也就沒有必要像上文提到那樣去創建一個第三方資源API端點了。 

網絡隔離默認設置下是關閉的，所以所有的pods之間正常情況下可以互相交流。然而，重點是一旦網絡隔離打開，在所有的命名空間里，所有到pods的流量都會被攔截，也就是說，打開隔離將會改變你的pods的行為反應。

通過定義命名空間上的網絡隔離注釋來打開網絡隔離，如下圖所示：

只要網絡隔離打開，網絡協議肯定被用來做pod之間的交流。

政策規范可以應用到一個命名空間來定義政策的細節，具體如下圖所示：

在這個例子中，‘tenant－a’命名空間get到‘pol 1’，如圖所示。具體來說，帶有段落標簽‘backend’的pods會在80端口允許TCP流量在帶有段落標簽‘frontend’接收。

現在，Romana，OpenShift，OpenContrail和Calico都支持網絡協議應用到命名空間和pods。Cisco和VMware也都在致力于這方面的實施工作。Romana和Calico最近在KubeCon證實了Kubernetes1.2的性能。你可以點擊這里查看他們的presentation：Romana（視頻地址：https://www.youtube.com/watch?v=f-dLKtK6qCs幻燈片地址：http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn），Calico（視頻地址：https://www.youtube.com/watch?v=p1zfh5N4SX0幻燈片地址：http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico）

如何運作

每個解決方案都有各自的實施細節。目前，他們依靠的是主機執行機制，但是未來的實施也會在超級管理器上面創建應用協議，或者直接依靠網絡本身。

外部協議控制軟件（不同實施細節）會為pods創建或者運用新的協議，查看新的API端點。當一個event要求策略配置，收聽器會識別區別，控制器會通過配置界面、運用策略來回應。下面的框架展示了一個API收聽器和協議控制器如何通過主機來應用網絡策略，然后回應更新。pods上面的網絡界面是通過主機上一個CNI插件配置的（沒有在圖中展示）。

如果你因為網絡隔斷或者安全問題（或者兩者都有）在開發程序時被絆住了，這些新的網絡協議對提供你需要的control很有幫助。因為網絡策略現在已經像一個API一樣可得到，所以不需要等到Kubernetes1.3。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。