在多个编排器之间共享控制平面有很多好处，包括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）是可能的:)
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+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和物理交换机扩展。
K8s+
OpenStack+vCenter
我不知道是否会使用这样的配置，因为Kubernetes / OpenStack / vCenter具有一些功能重叠，尽管如果设置正确的话会工作良好。
·END·
Tungsten Fabric入门宝典系列文章——
-
首次启动和运行指南
TF组件的七种“武器”
-
编排器集成
-
关于安装的那些事（上）
-
关于安装的那些事（下）
-
主流监控系统工具的集成
-
开始第二天的工作
-
8个典型故障及排查Tips
关于集群更新的那些事
说说L3VPN及EVPN集成
关于服务链、BGPaaS及其它
-
关于多集群和多数据中心
Tungsten Fabric 架构解析
系列文章
——
第一篇：
TF主要特点和用例
第二篇：
TF怎么运作
第三篇：详解vRouter体系结构
第四篇：
TF的服务链
第五篇：
vRouter的部署选项
第六篇：
TF如何收集、分析、部署？
第七篇：
TF如何编排
第八篇：
TF支持API一览
第九篇：
TF如何连接到物理网络
第十篇：
TF基于应用程序的安全策略
TF中文社区
多云互联 · 开源开放
我知道你“在看”哟～
网站题目：TungstenFabric入门宝典丨多编排器用法及配置-创新互联
文章分享：
http://njwzjz.com/article/csdjip.html
