溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

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

發(fā)布時間：2020-08-11 00:01:56 來源：ITPUB博客 閱讀：213 作者：TF中文社區(qū) 欄目：互聯網科技

在多個編排器之間共享控制平面有很多好處，包括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參數，該參數修改了將要創(chuàng)建的租戶名稱（默認為“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 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創(chuàng)建的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，因此，如果創(chuàng)建了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完成后會創(chuàng)建一個新的端口，并且可能會分配不同的固定IP。
因此，我認為將多個vCenter分配給一個Tungsten Fabric集群，將會有比較合理的用例。
根據我的嘗試，在當前實現中，由于vcenter-plugin僅對某些對象使用“vCenter”租戶，因此，如果不進行代碼修改，就不可能同時使用兩個vcenter-plugin。
如果可以按vcenter-plugin和vcenter-manager修改租戶，則可以為每個vCenter分配一個單獨的租戶，然后同時使用它們，就像同時使用Kubernetes和OpenStack一樣。
如果這是可行的，還可以在多vCenter的環(huán)境中使用service-insertion和物理交換機擴展。

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


   K8s+ OpenStack+vCenter

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


  ·END·

Tungsten Fabric入門寶典系列文章——


  1. 首次啟動和運行指南

  2. TF組件的七種“武器”

  3. 編排器集成
  4. 關于安裝的那些事（上）
  5. 關于安裝的那些事（下）
  6. 主流監(jiān)控系統(tǒng)工具的集成
  7. 開始第二天的工作
  8. 8個典型故障及排查Tips

  9. 關于集群更新的那些事

  10. 說說L3VPN及EVPN集成

  11. 關于服務鏈、BGPaaS及其它

  12. 關于多集群和多數據中心


 Tungsten Fabric 架構解析 系列文章 ——


  • 第一篇： TF主要特點和用例

  •   第二篇： TF怎么運作

  •    第三篇：詳解vRouter體系結構

  •    第四篇： TF的服務鏈

  •   第五篇： vRouter的部署選項

  •    第六篇： TF如何收集、分析、部署？

  •    第七篇： TF如何編排

  •   第八篇： TF支持API一覽

  •   第九篇： TF如何連接到物理網絡

  •   第十篇： TF基于應用程序的安全策略



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

TF中文社區(qū)

多云互聯 · 開源開放

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

我知道你“在看”喲～




向AI問一下細節(jié)

免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。

AI
助
手