91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

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

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

發布時間:2020-08-11 00:01:56 來源:ITPUB博客 閱讀:216 作者: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 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 .02 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:  50AS  pathNone

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:  50AS  pathNone
[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 .02 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:  50AS  pathNone

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:  50AS  pathNone
[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具有一些功能重疊,盡管如果設置正確的話會工作良好。



  ·END·

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基于應用程序的安全策略




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

TF中文社區

多云互聯 · 開源開放

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

我知道你“在看”喲~




向AI問一下細節

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

AI

同仁县| 西峡县| 呼玛县| 高雄市| 宜兴市| 通山县| 安顺市| 杂多县| 阳山县| 蕉岭县| 布拖县| 崇阳县| 花莲县| 南郑县| 嘉禾县| 桦甸市| 乐亭县| 子长县| 五大连池市| 儋州市| 本溪| 辰溪县| 天津市| 宜都市| 深水埗区| 阿拉善右旗| 团风县| 青川县| 雷山县| 永登县| 东至县| 陈巴尔虎旗| 泗洪县| 南涧| 都匀市| 新津县| 醴陵市| 临沂市| 葫芦岛市| 阿拉尔市| 肥城市|