TungstenFabric入门宝典丨多编排器用法及配置-创新互联

在多个编排器之间共享控制平面有很多好处，包括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:  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:  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具有一些功能重叠，尽管如果设置正确的话会工作良好。

  ·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入门宝典丨多编排器用法及配置

我知道你“在看”哟～




分享题目：TungstenFabric入门宝典丨多编排器用法及配置-创新互联
链接URL：http://cdiso.cn/article/csdjip.html

其他资讯

联系小谭

企业微信号
友情链接： 古蔺网站建设   网站排名优化   资阳服务器托管   高端网站建设   重庆服务器托管   成都水电改造   乐山做网站   电商网店   成都网站运营维护   响应式网站建设方案   

123ABC 成都网站建设，成都定制网站建设——全心全意建网站公司