K8S 1.3中將引入網(wǎng)絡(luò)策略API

魏憲會(huì) 發(fā)布于2019-07-01 16:21 / 2737人閱讀

摘要：在網(wǎng)絡(luò)管理上目前為止是最為缺失的一個(gè)環(huán)節(jié)，但這將在中有極大的改變。今天這篇帖子是由小組撰寫，描述中將加入網(wǎng)絡(luò)策略關(guān)于安全隔離多租戶。小組自去年年底以來一直頻繁開會(huì)，旨在給添加網(wǎng)絡(luò)策略，也收獲很多進(jìn)展。

Kubernetes在網(wǎng)絡(luò)管理上目前為止是最為缺失的一個(gè)環(huán)節(jié)，但這將在1.3中有極大的改變。今天這篇帖子是由Network－SIG（Kubernetes Special Interest Groups）小組撰寫，描述Kubernetes1.3中將加入網(wǎng)絡(luò)策略API —— 關(guān)于安全、隔離、多租戶。

Kubernetes SIG小組自去年年底以來一直頻繁開會(huì)，旨在給Kubernetes添加網(wǎng)絡(luò)策略，也收獲很多進(jìn)展。

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

在大多數(shù)的IaaS環(huán)境（無論公有還是私有），這種控制能力都是通過虛擬機(jī)加入一個(gè)“安全組”獲得，在這個(gè)組里面流動(dòng)到每個(gè)成員的流量是通過網(wǎng)絡(luò)策略或者ACL（Access Control List）來定義，并且由一個(gè)網(wǎng)絡(luò)包過濾器執(zhí)行。

網(wǎng)絡(luò)SIG小組努力搭建，從識(shí)別特定的需要網(wǎng)絡(luò)隔離增強(qiáng)安全性的案例場(chǎng)景（網(wǎng)址）著手。正確獲得這些簡(jiǎn)單使用案例的API對(duì)于工作十分重要，因?yàn)檫@也是更加復(fù)雜的網(wǎng)絡(luò)協(xié)議的基礎(chǔ)，對(duì)于Kubernetes里面的多租戶來說十分重要。

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

要快速支持這個(gè)實(shí)驗(yàn)的API最簡(jiǎn)單的方法就是以第三方資源拓展（ThirdPartyResource）的形式到API服務(wù)器，Kubernetes 1.2 現(xiàn)在已經(jīng)支持了。

如果對(duì)這個(gè)運(yùn)行不熟悉，Kubernetes API可以通過定義第三方資源（ThirdPartyResources）拓展，在指定的URL上創(chuàng)建一個(gè)新的API端點(diǎn)。

這樣就可以創(chuàng)建一個(gè)API端點(diǎn)（每個(gè)命名空間一個(gè)）：

第三方網(wǎng)絡(luò)控制器可以在這些端點(diǎn)上監(jiān)聽，當(dāng)資源被創(chuàng)建、修改或者刪除的時(shí)候作出必要的回應(yīng)。注意：kubernetes 1.3版本即將發(fā)布，網(wǎng)絡(luò)策略API會(huì)以測(cè)試版的形式發(fā)布，那么也就沒有必要像上文提到那樣去創(chuàng)建一個(gè)第三方資源API端點(diǎn)了。

網(wǎng)絡(luò)隔離默認(rèn)設(shè)置下是關(guān)閉的，所以所有的pods之間正常情況下可以互相交流。然而，重點(diǎn)是一旦網(wǎng)絡(luò)隔離打開，在所有的命名空間里，所有到pods的流量都會(huì)被攔截，也就是說，打開隔離將會(huì)改變你的pods的行為反應(yīng)。

通過定義命名空間上的網(wǎng)絡(luò)隔離注釋來打開網(wǎng)絡(luò)隔離，如下圖所示：

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

現(xiàn)在，Romana，OpenShift，OpenContrail和Calico都支持網(wǎng)絡(luò)協(xié)議應(yīng)用到命名空間和pods。Cisco和VMware也都在致力于這方面的實(shí)施工作。Romana和Calico最近在KubeCon證實(shí)了Kubernetes1.2的性能。你可以點(diǎn)擊這里查看他們的presentation：Romana（視頻地址：點(diǎn)我幻燈片地址：點(diǎn)我），Calico（視頻地址：點(diǎn)我幻燈片地址：點(diǎn)我）

如何運(yùn)作

每個(gè)解決方案都有各自的實(shí)施細(xì)節(jié)。目前，他們依靠的是主機(jī)執(zhí)行機(jī)制，但是未來的實(shí)施也會(huì)在超級(jí)管理器上面創(chuàng)建應(yīng)用協(xié)議，或者直接依靠網(wǎng)絡(luò)本身。

外部協(xié)議控制軟件（不同實(shí)施細(xì)節(jié)）會(huì)為pods創(chuàng)建或者運(yùn)用新的協(xié)議，查看新的API端點(diǎn)。當(dāng)一個(gè)event要求策略配置，收聽器會(huì)識(shí)別區(qū)別，控制器會(huì)通過配置界面、運(yùn)用策略來回應(yīng)。下面的框架展示了一個(gè)API收聽器和協(xié)議控制器如何通過主機(jī)來應(yīng)用網(wǎng)絡(luò)策略，然后回應(yīng)更新。pods上面的網(wǎng)絡(luò)界面是通過主機(jī)上一個(gè)CNI插件配置的（沒有在圖中展示）。

如果你因?yàn)榫W(wǎng)絡(luò)隔斷或者安全問題（或者兩者都有）在開發(fā)程序時(shí)被絆住了，這些新的網(wǎng)絡(luò)協(xié)議對(duì)提供你需要的control很有幫助。因?yàn)榫W(wǎng)絡(luò)策略現(xiàn)在已經(jīng)像一個(gè)API一樣可得到，所以不需要等到Kubernetes1.3。

原文鏈接