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

成都創(chuàng)新互聯(lián)主營白銀網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,app開發(fā)定制,白銀h5微信小程序開發(fā)搭建,白銀網(wǎng)站營銷推廣歡迎白銀等地區(qū)企業(yè)咨詢

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

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

使用場景

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

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

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

在處理集群虛擬化時，需要解決三個問題：
（1）誰可以訪問虛擬集群（RBAC）；
（2）每個虛擬集群可以使用多少計算資源；
（3）虛擬集群中的應(yīng)用程序允許哪些網(wǎng)絡(luò)通信。

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

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

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

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

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

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

添加隔離的命名空間

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

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

#確認(rèn)您是root賬戶
whoami | grep root || sudo -s

#切換到清單目錄
cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

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

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

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

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

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

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

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

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

接下來，我們將示例應(yīng)用程序部署到已創(chuàng)建的隔離命名空間中：
kubectl create --namespace dev-isolated -f cnawebapp-loadbalancer.yaml

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

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

kubectl create -f cnawebapp-loadbalancer.yaml

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

我們期望的行為有：

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

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

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

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

我們將逐個驗證這些行為。

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

我們知道Pod可以與在default命名空間中的服務(wù)通信——這就是示例應(yīng)用程序的工作方式。但是跨命名空間呢？由于我們位于沙箱中，因此可以使用kube-system命名空間中的一個Pod來嘗試訪問在default非隔離命名空間中運行的應(yīng)用程序中的Pods和Services?：

#獲得kube-system pods里的tiller-deploy的名字：
src_pod=$(kubectl get pods --namespace kube-system | grep tiller | awk '{print $1}')

#找到“default”命名空間里的“yelb-ui”pod的IP：
dst_pod_ip=$(kubectl get pods -o wide | grep yelb-ui | awk '{print $6}')

#讓tiller-deploy去ping yelb-ui：
kubectl exec --namespace kube-system -it ${src_pod} ping ${dst_pod_ip}

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

PING 10.47.255.246 (10.47.255.246): 56 data bytes
64 bytes from 10.47.255.246: seq=0 ttl=63 time=1.291 ms
64 bytes from 10.47.255.246: seq=1 ttl=63 time=0.576 ms

用^ C取消命令。

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

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

#獲得運行在“default”命名空間里的“yelb-ui”服務(wù)的集群IP地址：
default_yelb_ui_ip=$(kubectl get svc --namespace default -o wide | grep yelb-ui | awk '{print $3'})

#獲得"dev-isolated" 命名空間的"yelb-appserver" Pod的名字
src_pod2=$(kubectl get pods --namespace dev-isolated | grep yelb-appserver | awk '{print $1}')

#在“yelb-appserver”運行“curl” ，嘗試訪問“default”命名空間的服務(wù)IP：
kubectl exec -it -n dev-isolated ${src_pod2} -- /usr/bin/curl http://${default_yelb_ui_ip}
我們應(yīng)該在yelb-ui主頁上看到大約10行HTML代碼，這表明dev-isolated命名空間中的Pod?可以與非隔離default命名空間中的服務(wù)通信。

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

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

#獲得位于“dev-isolated”命名空間的“yelb-ui”pod 的IP：
isolated_pod_ip=$(kubectl get pods --namespace dev-isolated -o wide | grep yelb-ui | awk '{print $6}')

#..嘗試ping它：
kubectl exec --namespace kube-system -it ${src_pod} ping ${isolated_pod_ip}

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

按^ C取消命令。

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

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

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

kubectl get svc --namespace dev-isolated -o wide | grep yelb-ui | awk '{print $4}'

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

清理

一旦進行了足夠的測試，可以隨時清理：

#刪除兩個“yelb”副本：
kubectl delete -f cnawebapp-loadbalancer.yaml
kubectl delete --namespace dev-isolated -f cnawebapp-loadbalancer.yaml

#刪除獨立的命名空間和它的清單：
kubectl delete -f dev-isolated.yaml
rm -f dev-isolated.yaml

回顧和下一步

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

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

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

---

MORE
更多TF+K8s文章
第一篇：TF Carbide 評估指南--準(zhǔn)備篇
第二篇：通過Kubernetes的服務(wù)進行基本應(yīng)用程序連接
第三篇：通過Kubernetes Ingress進行高級外部應(yīng)用程序連接

---

關(guān)于Tungsten Fabric：
Tungsten Fabric項目是一個開源項目協(xié)議，它基于標(biāo)準(zhǔn)協(xié)議開發(fā)，并且提供網(wǎng)絡(luò)虛擬化和網(wǎng)絡(luò)安全所必需的所有組件。項目的組件包括：SDN控制器，虛擬路由器，分析引擎，北向API的發(fā)布，硬件集成功能，云編排軟件和廣泛的REST API。

關(guān)于TF中文社區(qū)：
TF中文社區(qū)由中國的一群關(guān)注和熱愛SDN的志愿者自發(fā)發(fā)起，有技術(shù)老鳥，市場老炮，也有行業(yè)專家，資深用戶。將作為連接社區(qū)與中國的橋梁，傳播資訊，提交問題，組織活動，聯(lián)合一切對多云互聯(lián)網(wǎng)絡(luò)有興趣的力量，切實解決云網(wǎng)絡(luò)建設(shè)過程中遇到的問題。

關(guān)注微信：TF中文社區(qū)

網(wǎng)頁標(biāo)題：TungstenFabric+K8s輕松上手丨通過Kuber
URL鏈接：http://chinadenli.net/article44/ppcghe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、響應(yīng)式網(wǎng)站、網(wǎng)站設(shè)計公司、網(wǎng)站收錄、標(biāo)簽優(yōu)化、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)