Tungsten Fabric+K8s輕松上手丨通過Kubernetes命名空間實(shí)現(xiàn)初步的應(yīng)用程序隔離

本文所有相關(guān)鏈接 pdf ： https://163.53.94.133/assets/uploads/files/tf-ceg-case3.pdf   

Kubernetes命名空間是“虛擬化”Kubernetes集群的一種內(nèi)置方式。雖然目前尚無人討論如何使用命名空間以及在何處使用命名空間，但是如果沒有網(wǎng)絡(luò)范圍內(nèi)的命名空間隔離能力，集群虛擬化將無法完成。

Tungsten Fabric Kubernetes CNI插件包括對(duì)isolated命名空間的支持。部署到隔離的命名空間中的應(yīng)用程序無法訪問其所在的命名空間之外的任何Pod，其他命名空間的應(yīng)用程序也無法訪問它的Pod和Services。

使用場景

一種Kubernetes的部署方法，是每個(gè)開發(fā)團(tuán)隊(duì)部署單獨(dú)的Kubernetes集群，在這種情況下，集群虛擬化和命名空間隔離幾乎沒有好處。

但是，由于未使用的容量是零散的，因此該方法可能導(dǎo)致資源使用效率低下。每個(gè)集群都有自己的可用容量，其他集群中運(yùn)行的應(yīng)用程序無法使用這些可用容量。此外，隨著集群數(shù)量的增加，它引入了保持統(tǒng)一所需要的操作開銷。最后，啟動(dòng)新集群需要花費(fèi)時(shí)間，這可能會(huì)使事情變慢。

命名空間是解決這些問題的好方法，因?yàn)檫@有助于減少集群的數(shù)量，共享備用容量并且可以快速創(chuàng)建。這還可以提供一個(gè)隔離級(jí)別，基礎(chǔ)架構(gòu)團(tuán)隊(duì)將負(fù)責(zé)集群的管理，而各個(gè)開發(fā)人員團(tuán)隊(duì)則在自己的命名空間中進(jìn)行操作。

在處理集群虛擬化時(shí)，需要解決三個(gè)問題：

（1）誰可以訪問虛擬集群（RBAC）；

（2）每個(gè)虛擬集群可以使用多少計(jì)算資源；

（3）虛擬集群中的應(yīng)用程序允許哪些網(wǎng)絡(luò)通信。

用于Kubernetes的Tungsten Fabric CNI插件旨在通過本節(jié)將要討論的命名空間隔離以及下一節(jié)將介紹的網(wǎng)絡(luò)策略來解決問題（3）。從法規(guī)遵從性的角度來看，這特別有用。PCI合規(guī)性就是一個(gè)很好的例子，因?yàn)樗膭?lì)工作負(fù)載隔離。

當(dāng)尋求實(shí)現(xiàn)PCI合規(guī)性時(shí)，重點(diǎn)關(guān)注的領(lǐng)域之一是縮小范圍。范圍縮小的目的是隔離所有可能影響信用卡信息處理的系統(tǒng)，這些系統(tǒng)被稱為“持卡人數(shù)據(jù)環(huán)境”（Cardholder Data Environment，CDE）。

任何工作負(fù)載或設(shè)備，都可以以任何方式與屬于CDE的系統(tǒng)進(jìn)行交互。網(wǎng)絡(luò)分段對(duì)于實(shí)現(xiàn)所需的隔離至關(guān)重要，以減少為PCI合規(guī)性而考慮的系統(tǒng)數(shù)量。

Kubernetes命名空間和基礎(chǔ)的容器化平臺(tái)Kubernetes編排器，可提供減少容器化工作負(fù)載的PCI范圍所需的計(jì)算隔離。Kubernetes還提供了有關(guān)存儲(chǔ)隔離的解決方案的一部分。但是，Kubernetes當(dāng)前沒有為此目的提供足夠的網(wǎng)絡(luò)隔離或檢查。

用于Kubernetes的Tungsten Fabric CNI插件不僅提供了Kubernetes感知命名空間的網(wǎng)絡(luò)隔離功能，還使管理團(tuán)隊(duì)能夠通過控制網(wǎng)絡(luò)功能虛擬化（NFV）實(shí)例的流量來檢查所有進(jìn)入或離開命名空間的網(wǎng)絡(luò)流量。這使得下面的情況稱為可能：根據(jù)必須被允許進(jìn)出隔離CDE的通信類型的要求，來調(diào)整數(shù)據(jù)流檢查的級(jí)別。

讓我們來看一個(gè)使用Kubernetes命名空間進(jìn)行網(wǎng)絡(luò)隔離的示例。在此用例中，我們將部署示例應(yīng)用程序的兩個(gè)副本，一個(gè)副本部署到默認(rèn)命名空間中，另一個(gè)部署到一個(gè)新的隔離命名空間中。然后，我們將看到Tungsten Fabric如何實(shí)施網(wǎng)絡(luò)通信隔離，如下圖所示：

添加隔離的命名空間

在開始之前，有必要快速瀏覽Kubernetes文檔頁面，該頁面解釋了如何使用命名空間，包括我們需要知道的命令。

全部完成后，確保您位于沙箱控制節(jié)點(diǎn)上，以root用戶身份登錄，并且位于正確的目錄中：

# 確認(rèn)您是root賬戶

whoami | grep root || sudo -s

# 切換到清單目錄

cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

接下來，創(chuàng)建一個(gè)新清單，以描述我們新的隔離命名空間：

這將創(chuàng)建一個(gè)名為dev-isolated.yaml的文件，它包括以上內(nèi)容。請(qǐng)注意annotations部分——這將告訴Tungsten Fabric隔離新的命名空間。

繼續(xù)創(chuàng)建該命名空間，并向Kubernetes配置文件添加相關(guān)內(nèi)容，以便我們可以訪問它：

# 創(chuàng)建新的命名空間：

讓我們快速瀏覽一下新的命名空間：

注意Annotations字段；這向Tungsten Fabric CNI插件發(fā)出信號(hào)，它需要以不同的方式對(duì)待此命名空間。

我們可以簡單地將此注釋添加到現(xiàn)有命名空間以使其隔離嗎？不幸的是沒有，因?yàn)門ungsten必須做很多額外的工作才能設(shè)置一個(gè)隔離的新命名空間。更具體地說，必須創(chuàng)建一組單獨(dú)的虛擬網(wǎng)絡(luò)，此命名空間中的應(yīng)用程序Pod將連接到該虛擬網(wǎng)絡(luò)。

這樣可以確保將網(wǎng)絡(luò)隔離保持在底層水平上，而不是簡單地通過流量過濾器之類的較弱方法。

將示例應(yīng)用程序部署到隔離的命名空間中

接下來，我們將示例應(yīng)用程序部署到已創(chuàng)建的隔離命名空間中：

一旦應(yīng)用程序pod啟動(dòng)，我們應(yīng)該能夠像上面用例1中所描述的那樣從Internet訪問我們的應(yīng)用程序。

接下來，我們需要一些東西進(jìn)行比較和對(duì)比；因此，將示例應(yīng)用程序的另一個(gè)副本部署到default命名空間中：

現(xiàn)在，我們有兩個(gè)應(yīng)用程序副本。一個(gè)在沒有隔離的default命名空間中運(yùn)行，另一個(gè)在dev-isolated命名空間中運(yùn)行。

我們期望的行為有：

1. 非隔離命名空間中的Pod和服務(wù)，應(yīng)該可以從非隔離命名空間中的其他Pod（例如default和kube-system）訪問；

2. 非隔離命名空間中的服務(wù)，應(yīng)該可以從隔離命名空間中運(yùn)行的Pod訪問；

3. 隔離命名空間中的Pod和服務(wù)，只能從相同命名空間中的Pod訪問；

4. 對(duì)于以上的情況有個(gè)例外：在隔離的命名空間里的LoadBalancer的服務(wù)可以被外部世界訪問。

我們將逐個(gè)驗(yàn)證這些行為。

非隔離命名空間中的Pod應(yīng)該能夠相互通信

我們知道Pod可以與在default命名空間中的服務(wù)通信——這就是示例應(yīng)用程序的工作方式。但是跨命名空間呢？

由于我們位于沙箱中，因此可以使用kube-system命名空間中的一個(gè)Pod來嘗試訪問在default非隔離命名空間中運(yùn)行的應(yīng)用程序中的Pods和Services ：

# 獲得kube-system pods里的tiller-deploy的名字：

# 找到“default”命名空間里的“yelb-ui”pod的IP：

# 讓tiller-deploy去ping yelb-ui：

最后一條命令的輸出應(yīng)類似于：

用^ C取消命令。

這確認(rèn)了非隔離命名空間中的Pod可以相互到達(dá)。

隔離的Pod應(yīng)該能夠到達(dá)非隔離的服務(wù)

# 獲得運(yùn)行在“default”命名空間里的“yelb-ui”服務(wù)的集群IP地址：

# 獲得"dev-isolated" 命名空間的"yelb-appserver" Pod的名字

# 在“yelb-appserver”運(yùn)行“curl” ，嘗試訪問“default”命名空間的服務(wù)IP：

我們應(yīng)該在yelb-ui主頁上看到大約10行HTML代碼，這表明dev-isolated命名空間中的Pod 可以與非隔離default命名空間中的服務(wù)通信。

隔離命名空間中的Pod不能從其他命名空間訪問

現(xiàn)在，讓我們嘗試從同一個(gè)tiller-deploy Pod去ping 運(yùn)行在dev-isolated命名空間的yelb-ui Pod：

# 獲得位于“dev-isolated”命名空間的“yelb-ui”pod 的IP：

# ..嘗試ping它：

您應(yīng)該看到該命令被“卡住”了，沒有顯示任何響應(yīng)，因?yàn)檫@次我們正嘗試達(dá)到某些無法達(dá)到的目的地，Tungsten Fabric正在阻止這一訪問。

按^ C取消命令。

再多試一下——嘗試從位于default命名空間的yelb Pods去ping隔離的yelb Pods和服務(wù)。一切都按預(yù)期工作了嗎？

隔離命名空間中的LoadBalancer服務(wù)應(yīng)該可以在外部訪問

但是，如果我們無法訪問它，那么在一個(gè)隔離的命名空間中運(yùn)行應(yīng)用程序就沒有多大意義了。因此，在獨(dú)立命名空間本dev-isolated的yelb副本應(yīng)通過LoadBalancer Service yelb-ui 供Internet使用。讓我們測(cè)試一下：

它應(yīng)該顯示類似afd9047c2915911e9b411026463a4a33-777914712.us-west-1.elb.amazonaws.com的結(jié)果；將您的瀏覽器指向它，看看我們的應(yīng)用程序是否可被加載！

清理

一旦進(jìn)行了足夠的測(cè)試，可以隨時(shí)清理：

# 刪除兩個(gè)“yelb”副本：

# 刪除獨(dú)立的命名空間和它的清單：

回顧和下一步

Kubernetes命名空間已被設(shè)計(jì)為虛擬化Kubernetes集群的一種方式。沒有網(wǎng)絡(luò)，任何虛擬化都是不完整的，而Tungsten Fabric對(duì)隔離命名空間的支持提供了此功能。

但是，在您需要在命名空間中實(shí)施應(yīng)用程序網(wǎng)絡(luò)安全策略時(shí)，隔離的命名空間提供的粒度可能較粗。

也有一些更精細(xì)的控件，我們將在用例4的文章中進(jìn)行詳細(xì)介紹。

（“TF中文社區(qū)”公眾號(hào)將陸續(xù)發(fā)布其他Carbide評(píng)估指南文章，敬請(qǐng)關(guān)注）

  ·END·