Tungsten Fabric入门宝典丨多编排器用法及配置

发布时间:2020-08-11 00:01:56 作者:TF中文社区
来源:ITPUB博客 阅读:212

在多个编排器之间共享控制平面有很多好处,包括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入门宝典丨多编排器用法及配置

我知道你“在看”哟~




推荐阅读:
  1. Tungsten Fabric架构解析丨TF支持API一览
  2. Tungsten Fabric架构解析丨Tungsten F

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

fabric tungsten 丨多

上一篇:LDEE流程图绘制软件那个专业,怎么画LDEE流程图

下一篇:以文案人员为例,解析协同办公“协同”的到底是什么?

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》