Tungsten Fabric入門寶典丨多編排器用法及配置

Tungsten Fabric入門寶典系列文章,來自技術大牛傾囊相授的實踐經驗,由TF中文社區爲您編譯呈現,旨在幫助新手深入理解TF的運行、安裝、集成、調試等全流程。如果您有相關經驗或疑問,歡迎與我們互動,並與社區極客們進一步交流。更多TF技術文章,請點擊公號底部按鈕>學習>文章合集。

作者:Tatsuya Naganawa 譯者:TF編譯組

在多個編排器之間共享控制平面有很多好處,包括routing/bridging、DNS、security等。

下面我來描述每種情況的使用方法和配置。

K8s+OpenStack

Kubernetes + OpenStack的組合已經涵蓋並且運行良好。

  • https://github.com/Juniper/contrail-ansible-deployer/wiki/Deployment-Example:-Contrail-and-Kubernetes-and-Openstack

另外,Tungsten Fabric支持嵌套安裝(nested installation)和非嵌套安裝(non-nested installation),因此你可以選擇其中一個選項。

  • https://github.com/Juniper/contrail-kubernetes-docs

K8s+K8s

將多個Kubernetes集羣添加到一個Tungsten Fabric中,是一種可能的安裝選項。

由於kube-manager支持cluster_name參數,該參數修改了將要創建的租戶名稱(默認爲“k8s”),因此這應該是可行的。不過,我在上次嘗試該方法時效果不佳,因爲有些對象被其它kube-manager作爲陳舊對象(stale object)刪除了。

  • https://github.com/Juniper/contrail-container-builder/blob/master/containers/kubernetes/kube-manager/entrypoint.sh#L28

在將來的版本中,可能會更改此行爲。

注意:

從R2002及更高版本開始,這個修補程序解決了該問題,並且不再需要自定義修補程序。

  • https://review.opencontrail.org/c/Juniper/contrail-controller/+/55758

注意:應用這些補丁,似乎可以將多個kube-master添加到一個Tungsten Fabric集羣中。

diff --git a/src/container/kube-manager/kube_manager/kube_manager.py b/src/container/kube-manager/kube_manager/kube_manager.py
index 0f6f7a0..adb20a6 100644
--- a/src/container/kube-manager/kube_manager/kube_manager.py
+++ b/src/container/kube-manager/kube_manager/kube_manager.py
@@ -219,10 +219,10 @@ def main(args_str=None, kube_api_skip=False, event_queue=None,

     if args.cluster_id:
         client_pfx = args.cluster_id + '-'
-        zk_path_pfx = args.cluster_id + '/'
+        zk_path_pfx = args.cluster_id + '/' + args.cluster_name
     else:
         client_pfx = ''
-        zk_path_pfx = ''
+        zk_path_pfx = '' + args.cluster_name

     # randomize collector list
     args.random_collectors = args.collectors
diff --git a/src/container/kube-manager/kube_manager/vnc/vnc_namespace.py b/src/container/kube-manager/kube_manager/vnc/vnc_namespace.py
index 00cce81..f968cae 100644
--- a/src/container/kube-manager/kube_manager/vnc/vnc_namespace.py
+++ b/src/container/kube-manager/kube_manager/vnc/vnc_namespace.py
@@ -594,7 +594,8 @@ class VncNamespace(VncCommon):
                 self._queue.put(event)

     def namespace_timer(self):
-        self._sync_namespace_project()
+        # self._sync_namespace_project() ## temporary disabled
+        pass

     def _get_namespace_firewall_ingress_rule_name(self, ns_name):
         return "-".join([vnc_kube_config.cluster_name(),

由於kube-master創建的pod-network都在同一個Tungsten Fabric controller上,因此在它們之間實現路由泄漏(route-leak)是可能的:)

  • 由於cluster_name將成爲Tungsten
    Fabric的fw-policy中的標籤之一,因此在多個Kubernetes集羣之間也可以使用相同的標籤
172.31.9.29 Tungsten Fabric controller
172.31.22.24 kube-master1 (KUBERNETES_CLUSTER_NAME=k8s1 is set)
172.31.12.82 kube-node1 (it belongs to kube-master1)
172.31.41.5 kube-master2(KUBERNETES_CLUSTER_NAME=k8s2 is set)
172.31.4.1 kube-node2 (it belongs to kube-master2)


[root@ip-172-31-22-24 ~]# kubectl get node
NAME                                              STATUS     ROLES    AGE   VERSION
ip-172-31-12-82.ap-northeast-1.compute.internal   Ready      <none>   57m   v1.12.3
ip-172-31-22-24.ap-northeast-1.compute.internal   NotReady   master   58m   v1.12.3
[root@ip-172-31-22-24 ~]# 

[root@ip-172-31-41-5 ~]# kubectl get node
NAME                                             STATUS     ROLES    AGE   VERSION
ip-172-31-4-1.ap-northeast-1.compute.internal    Ready      <none>   40m   v1.12.3
ip-172-31-41-5.ap-northeast-1.compute.internal   NotReady   master   40m   v1.12.3
[root@ip-172-31-41-5 ~]# 

[root@ip-172-31-22-24 ~]# kubectl get pod -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP              NODE                                              NOMINATED NODE
cirros-deployment-75c98888b9-7pf82   1/1     Running   0          28m     10.47.255.249   ip-172-31-12-82.ap-northeast-1.compute.internal   <none>
cirros-deployment-75c98888b9-sgrc6   1/1     Running   0          28m     10.47.255.250   ip-172-31-12-82.ap-northeast-1.compute.internal   <none>
cirros-vn1                           1/1     Running   0          7m56s   10.0.1.3        ip-172-31-12-82.ap-northeast-1.compute.internal   <none>
[root@ip-172-31-22-24 ~]# 


[root@ip-172-31-41-5 ~]# kubectl get pod -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP              NODE                                            NOMINATED NODE
cirros-deployment-75c98888b9-5lqzc   1/1     Running   0          27m     10.47.255.250   ip-172-31-4-1.ap-northeast-1.compute.internal   <none>
cirros-deployment-75c98888b9-dg8bf   1/1     Running   0          27m     10.47.255.249   ip-172-31-4-1.ap-northeast-1.compute.internal   <none>
cirros-vn2                           1/1     Running   0          5m36s   10.0.2.3        ip-172-31-4-1.ap-northeast-1.compute.internal   <none>
[root@ip-172-31-41-5 ~]# 


/ # ping 10.0.2.3
PING 10.0.2.3 (10.0.2.3): 56 data bytes
64 bytes from 10.0.2.3: seq=83 ttl=63 time=1.333 ms
64 bytes from 10.0.2.3: seq=84 ttl=63 time=0.327 ms
64 bytes from 10.0.2.3: seq=85 ttl=63 time=0.319 ms
64 bytes from 10.0.2.3: seq=86 ttl=63 time=0.325 ms
^C
--- 10.0.2.3 ping statistics ---
87 packets transmitted, 4 packets received, 95% packet loss
round-trip min/avg/max = 0.319/0.576/1.333 ms
/ # 
/ # ip -o a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
18: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue \    link/ether 02:b9:11:c9:4c:b1 brd ff:ff:ff:ff:ff:ff
18: eth0    inet 10.0.1.3/24 scope global eth0\       valid_lft forever preferred_lft forever
/ #
 -> 在屬於不同kubernetes 集羣的Pod之間ping,工作良好


[root@ip-172-31-9-29 ~]# ./contrail-introspect-cli/ist.py ctr route show -t default-domain:k8s1-default:vn1:vn1.inet.0 

default-domain:k8s1-default:vn1:vn1.inet.0: 2 destinations, 2 routes (1 primary, 1 secondary, 0 infeasible)

10.0.1.3/32, age: 0:06:50.001343, last_modified: 2019-Jul-28 18:23:08.243656
    [XMPP (interface)|ip-172-31-12-82.local] age: 0:06:50.005553, localpref: 200, nh: 172.31.12.82, encap: ['gre', 'udp'], label: 50, AS path: None

10.0.2.3/32, age: 0:02:25.188713, last_modified: 2019-Jul-28 18:27:33.056286
    [XMPP (interface)|ip-172-31-4-1.local] age: 0:02:25.193517, localpref: 200, nh: 172.31.4.1, encap: ['gre', 'udp'], label: 50, AS path: None
[root@ip-172-31-9-29 ~]# 
[root@ip-172-31-9-29 ~]# ./contrail-introspect-cli/ist.py ctr route show -t default-domain:k8s2-default:vn2:vn2.inet.0 

default-domain:k8s2-default:vn2:vn2.inet.0: 2 destinations, 2 routes (1 primary, 1 secondary, 0 infeasible)

10.0.1.3/32, age: 0:02:36.482764, last_modified: 2019-Jul-28 18:27:33.055702
    [XMPP (interface)|ip-172-31-12-82.local] age: 0:02:36.489419, localpref: 200, nh: 172.31.12.82, encap: ['gre', 'udp'], label: 50, AS path: None

10.0.2.3/32, age: 0:04:37.126317, last_modified: 2019-Jul-28 18:25:32.412149
    [XMPP (interface)|ip-172-31-4-1.local] age: 0:04:37.133912, localpref: 200, nh: 172.31.4.1, encap: ['gre', 'udp'], label: 50, AS path: None
[root@ip-172-31-9-29 ~]#
 -> 基於以下的網絡策略,每一個kube-master的每一個虛擬網絡有路由去其他的kube-master 的Pod


(venv) [root@ip-172-31-9-29 ~]# contrail-api-cli --host 172.31.9.29 ls -l virtual-network
virtual-network/f9d06d27-8fc1-413d-a6d6-c51c42191ac0  default-domain:k8s2-default:vn2
virtual-network/384fb3ef-247b-42e6-a628-7111fe343f90  default-domain:k8s2-default:k8s2-default-service-network
virtual-network/c3098210-983b-46bc-b750-d06acfc66414  default-domain:k8s1-default:k8s1-default-pod-network
virtual-network/1ff6fdbd-ac2e-4601-b08c-5f7255466312  default-domain:default-project:ip-fabric
virtual-network/d8d95738-0a00-457f-b21e-60304859d1f9  default-domain:k8s2-default:k8s2-default-pod-network
virtual-network/0c075b76-4219-4f79-a4f5-1b4e6729f16e  default-domain:k8s1-default:k8s1-default-service-network
virtual-network/985b3b5f-84b7-4810-a54d-abd09a37f525  default-domain:k8s1-default:vn1
virtual-network/23782ea7-4000-491f-b20d-01c6ab9e2ba8  default-domain:default-project:default-virtual-network
virtual-network/90cce352-ef9b-4358-81b3-ef87a9cb63e8  default-domain:default-project:__link_local__
virtual-network/0292810c-c511-4147-89c0-9fdd571ccce8  default-domain:default-project:dci-network
(venv) [root@ip-172-31-9-29 ~]# 

(venv) [root@ip-172-31-9-29 ~]# contrail-api-cli --host 172.31.9.29 ls -l network-policy
network-policy/134d38b2-79e2-4a3e-a2f7-a3d61ceaf5e2  default-domain:k8s1-default:vn1-to-vn2  <-- route-leak between to kubernetes cluster
network-policy/8e5c5c4a-14eb-4fc4-9b46-81a5b923bbe0  default-domain:k8s1-default:k8s1-default-ip-fabric-np
network-policy/544d5076-3dff-45a1-bb47-8aec5e1e5a37  default-domain:k8s1-default:k8s1-default-pod-service-np
network-policy/33884d88-6492-4e0f-934c-080a794ce132  default-domain:k8s2-default:k8s2-default-ip-fabric-np
network-policy/232beb43-2008-4df3-969f-a4eee653ff46  default-domain:k8s2-default:k8s2-default-pod-service-np
network-policy/a6ee02bd-ad0d-4393-be60-66da8032237a  default-domain:k8s2-default:k8s2-default-service-np
network-policy/a9cedd67-127a-40fd-9f44-78890dc3cfe4  default-domain:k8s1-default:k8s1-default-service-np
(venv) [root@ip-172-31-9-29 ~]#

OpenStack+OpenStack

我還沒有嘗試將兩個OpenStack集羣添加到一個Tungsten Fabric controller中,但如果它們不使用相同的租戶名稱,那麼應該是可行的。

K8s+vCenter

Kubernetes和vCenter的組合可以同時使用。用例類似於Kubernetes + OpenStack。

OpenStack+vCenter

OpenStack和vCenter的組合有點奇怪,因爲OpenStack儀表盤可能用作vCenter網絡的管理UI。

根據我的嘗試,vcenter-plugin會檢查所有可用租戶下的所有virtual-network,而不是“vCenter”租戶下的virtual-network,因此,如果創建了virtual-network或其它Neutron組件,也可以在ESXi上的vRouterVM上使用。通過此設置,vCenter用戶可以自己實現網絡功能,就像使用EC2 / VPC一樣。

  • 還可以使用vCenter的權限功能來實現VMI和NF的僞多租戶。
  • https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-4B47F690-72E7-4861-A299-9195B9C52E71.html

vCenter+vCenter

多vCenter是一個重要話題,因爲vCenter具有明確定義的最大配置,而多vCenter安裝是解決這些問題的常用方法。

在這種情況下,最簡單的設置是在每個vCenter上配置多個Tungsten Fabric集羣,但此時很難在兩個集羣之間進行vMotion,因爲Tungsten Fabric在vMotion完成後會創建一個新的端口,並且可能會分配不同的固定IP。

因此,我認爲將多個vCenter分配給一個Tungsten Fabric集羣,將會有比較合理的用例。

根據我的嘗試,在當前實現中,由於vcenter-plugin僅對某些對象使用“vCenter”租戶,因此,如果不進行代碼修改,就不可能同時使用兩個vcenter-plugin。

如果可以按vcenter-plugin和vcenter-manager修改租戶,則可以爲每個vCenter分配一個單獨的租戶,然後同時使用它們,就像同時使用Kubernetes和OpenStack一樣。

如果這是可行的,還可以在多vCenter的環境中使用service-insertion和物理交換機擴展。

  • 甚至SRM集成也可能採用這種方式,因爲佔位符VM將分配一個新的端口,可以對其進行編輯以分配正確的固定IP。

K8s+OpenStack+vCenter

我不知道是否會使用這樣的配置,因爲Kubernetes / OpenStack / vCenter具有一些功能重疊,儘管如果設置正確的話會工作良好。


Tungsten Fabric入門寶典系列文章——
1.首次啓動和運行指南
2. TF組件的七種“武器”
3. 編排器集成
4.關於安裝的那些事(上)
5.關於安裝的那些事(下)
6.主流監控系統工具的集成
7.開始第二天的工作
8.8個典型故障及排查Tips
9.關於集羣更新的那些事
10.說說L3VPN及EVPN集成
11.關於服務鏈、BGPaaS及其它
12.關於多集羣和多數據中心


Tungsten Fabric 架構解析系列文章——
第一篇:TF主要特點和用例
第二篇:TF怎麼運作
第三篇:詳解vRouter體系結構
第四篇:TF的服務鏈
第五篇:vRouter的部署選項
第六篇:TF如何收集、分析、部署?
第七篇:TF如何編排
第八篇:TF支持API一覽
第九篇:TF如何連接到物理網絡
第十篇:TF基於應用程序的安全策略

在這裏插入圖片描述
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章