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

TF中文社群發表於2020-06-17

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


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

   K8s+OpenStack

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


另外，Tungsten Fabric支援巢狀安裝（nested installation）和非巢狀安裝（non-nested installation），因此你可以選擇其中一個選項。


   K8s+K8s

將多個Kubernetes叢集新增到一個Tungsten Fabric中，是一種可能的安裝選項。

由於kube-manager支援cluster_name引數，該引數修改了將要建立的租戶名稱（預設為“k8s”），因此這應該是可行的。不過，我在上次嘗試該方法時效果不佳，因為有些物件被其它kube-manager作為陳舊物件（stale object）刪除了。


在將來的版本中，可能會更改此行為。

注意：

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


注意：應用這些補丁，似乎可以將多個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 0f6f7a
0
..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具有一些功能重疊，儘管如果設定正確的話會工作良好。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69957171/viewspace-2698864/，如需轉載，請註明出處，否則將追究法律責任。

相關文章