TungstenFabric+K8s輕鬆上手丨經過Kubernetes命名空間實現初步的應用程序隔離

本文全部相關連接pdf：https://163.53.94.133/assets/uploads/files/tf-ceg-case3.pdf

Kubernetes命名空間是「虛擬化」Kubernetes集羣的一種內置方式。雖然目前尚無人討論如何使用命名空間以及在何處使用命名空間，可是若是沒有網絡範圍內的命名空間隔離能力，集羣虛擬化將沒法完成。

Tungsten Fabric Kubernetes CNI插件包括對isolated命名空間的支持。部署到隔離的命名空間中的應用程序沒法訪問其所在的命名空間以外的任何Pod，其餘命名空間的應用程序也沒法訪問它的Pod和Services。

使用場景

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

可是，因爲未使用的容量是零散的，所以該方法可能致使資源使用效率低下。每一個集羣都有本身的可用容量，其餘集羣中運行的應用程序沒法使用這些可用容量。此外，隨着集羣數量的增長，它引入了保持統一所須要的操做開銷。最後，啓動新集羣須要花費時間，這可能會使事情變慢。

命名空間是解決這些問題的好方法，由於這有助於減小集羣的數量，共享備用容量而且能夠快速建立。這還能夠提供一個隔離級別，基礎架構團隊將負責集羣的管理，而各個開發人員團隊則在本身的命名空間中進行操做。

在處理集羣虛擬化時，須要解決三個問題：
（1）誰能夠訪問虛擬集羣（RBAC）；
（2）每一個虛擬集羣可使用多少計算資源；
（3）虛擬集羣中的應用程序容許哪些網絡通訊。

用於Kubernetes的Tungsten Fabric CNI插件旨在經過本節將要討論的命名空間隔離以及下一節將介紹的網絡策略來解決問題（3）。從法規聽從性的角度來看，這特別有用。PCI合規性就是一個很好的例子，由於它鼓勵工做負載隔離。

當尋求實現PCI合規性時，重點關注的領域之一是縮小範圍。範圍縮小的目的是隔離全部可能影響信用卡信息處理的系統，這些系統被稱爲「持卡人數據環境」（Cardholder Data Environment，CDE）。

任何工做負載或設備，均可以以任何方式與屬於CDE的系統進行交互。網絡分段對於實現所需的隔離相當重要，以減小爲PCI合規性而考慮的系統數量。

Kubernetes命名空間和基礎的容器化平臺Kubernetes編排器，可提供減小容器化工做負載的PCI範圍所需的計算隔離。Kubernetes還提供了有關存儲隔離的解決方案的一部分。可是，Kubernetes當前沒有爲此目的提供足夠的網絡隔離或檢查。

用於Kubernetes的Tungsten Fabric CNI插件不只提供了Kubernetes感知命名空間的網絡隔離功能，還使管理團隊可以經過控制網絡功能虛擬化（NFV）實例的流量來檢查全部進入或離開命名空間的網絡流量。這使得下面的狀況稱爲可能：根據必須被容許進出隔離CDE的通訊類型的要求，來調整數據流檢查的級別。

讓咱們來看一個使用Kubernetes命名空間進行網絡隔離的示例。在此用例中，咱們將部署示例應用程序的兩個副本，一個副本部署到默認命名空間中，另外一個部署到一個新的隔離命名空間中。而後，咱們將看到Tungsten Fabric如何實施網絡通訊隔離，以下圖所示：

添加隔離的命名空間

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

所有完成後，確保您位於沙箱控制節點上，以root用戶身份登陸，而且位於正確的目錄中：

#確認您是root帳戶
whoami | grep root || sudo -s

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

接下來，建立一個新清單，以描述咱們新的隔離命名空間：

這將建立一個名爲dev-isolated.yaml的文件，它包括以上內容。請注意annotations部分——這將告訴Tungsten Fabric隔離新的命名空間。

繼續建立該命名空間，並向Kubernetes配置文件添加相關內容，以便咱們能夠訪問它：
#建立新的命名空間：
kubectl create -f dev-isolated.yaml

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

注意Annotations字段；這向Tungsten Fabric CNI插件發出信號，它須要以不一樣的方式對待此命名空間。

咱們能夠簡單地將此註釋添加到現有命名空間以使其隔離嗎？不幸的是沒有，由於Tungsten必須作不少額外的工做才能設置一個隔離的新命名空間。更具體地說，必須建立一組單獨的虛擬網絡，此命名空間中的應用程序Pod將鏈接到該虛擬網絡。

這樣能夠確保將網絡隔離保持在底層水平上，而不是簡單地經過流量過濾器之類的較弱方法。

將示例應用程序部署到隔離的命名空間中

接下來，咱們將示例應用程序部署到已建立的隔離命名空間中：
kubectl create --namespace dev-isolated -f cnawebapp-loadbalancer.yaml

一旦應用程序pod啓動，咱們應該可以像上面用例1中所描述的那樣從Internet訪問咱們的應用程序。

接下來，咱們須要一些東西進行比較和對比；所以，將示例應用程序的另外一個副本部署到default命名空間中：

kubectl create -f cnawebapp-loadbalancer.yaml

如今，咱們有兩個應用程序副本。一個在沒有隔離的default命名空間中運行，另外一個在dev-isolated命名空間中運行。

咱們指望的行爲有：

1.非隔離命名空間中的Pod和服務，應該能夠從非隔離命名空間中的其餘Pod（例如default和kube-system）訪問；

2.非隔離命名空間中的服務，應該能夠從隔離命名空間中運行的Pod訪問；

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

4.對於以上的狀況有個例外：在隔離的命名空間裏的LoadBalancer的服務能夠被外部世界訪問。

咱們將逐個驗證這些行爲。

非隔離命名空間中的Pod應該可以相互通訊

咱們知道Pod能夠與在default命名空間中的服務通訊——這就是示例應用程序的工做方式。可是跨命名空間呢？因爲咱們位於沙箱中，所以可使用kube-system命名空間中的一個Pod來嘗試訪問在default非隔離命名空間中運行的應用程序中的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}

最後一條命令的輸出應相似於：

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取消命令。

這確認了非隔離命名空間中的Pod能夠相互到達。

隔離的Pod應該可以到達非隔離的服務

#得到運行在「default」命名空間裏的「yelb-ui」服務的集羣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」命名空間的服務IP：
kubectl exec -it -n dev-isolated ${src_pod2} -- /usr/bin/curl http://${default_yelb_ui_ip}
咱們應該在yelb-ui主頁上看到大約10行HTML代碼，這代表dev-isolated命名空間中的Pod 能夠與非隔離default命名空間中的服務通訊。

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

如今，讓咱們嘗試從同一個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}

您應該看到該命令被「卡住」了，沒有顯示任何響應，由於此次咱們正嘗試達到某些沒法達到的目的地，Tungsten Fabric正在阻止這一訪問。

按^ C取消命令。

再多試一下——嘗試從位於default命名空間的yelb Pods去ping隔離的yelb Pods和服務。一切都按預期工做了嗎？

隔離命名空間中的LoadBalancer服務應該能夠在外部訪問

可是，若是咱們沒法訪問它，那麼在一個隔離的命名空間中運行應用程序就沒有多大意義了。所以，在獨立命名空間本dev-isolated的yelb副本應經過LoadBalancer Service yelb-ui 供Internet使用。讓咱們測試一下：

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

它應該顯示相似afd9047c2915911e9b411026463a4a33-777914712.us-west-1.elb.amazonaws.com 的結果；將您的瀏覽器指向它，看看咱們的應用程序是否可被加載！

清理

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

#刪除兩個「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命名空間已被設計爲虛擬化Kubernetes集羣的一種方式。沒有網絡，任何虛擬化都是不完整的，而Tungsten Fabric對隔離命名空間的支持提供了此功能。

可是，在您須要在命名空間中實施應用程序網絡安全策略時，隔離的命名空間提供的粒度可能較粗。

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

---

關於Tungsten Fabric：
Tungsten Fabric項目是一個開源項目協議，它基於標準協議開發，而且提供網絡虛擬化和網絡安全所必需的全部組件。項目的組件包括：SDN控制器，虛擬路由器，分析引擎，北向API的發佈，硬件集成功能，雲編排軟件和普遍的REST API。

關於TF中文社區：
TF中文社區由中國的一羣關注和熱愛SDN的志願者自發發起，有技術老鳥，市場老炮，也有行業專家，資深用戶。將做爲鏈接社區與中國的橋樑，傳播資訊，提交問題，組織活動，聯合一切對多雲互聯網絡有興趣的力量，切實解決雲網絡建設過程當中遇到的問題。

關注微信：TF中文社區