TungstenFabric+K8s輕松上手丨通過Kuber

本文所有相關鏈接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的文章中進行詳細介紹。

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

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

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

關注微信：TF中文社區