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

发布时间：2020-08-11 00:01:56 阅读：229 作者：TF中文社区栏目：互联网科技

开发者测试专用服务器限时活动，0元免费领，库存有限，领完即止！点击查看>>

在多个编排器之间共享控制平面有很多好处，包括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
.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入门宝典系列文章——

首次启动和运行指南
TF组件的七种“武器”
编排器集成
关于安装的那些事（上）
关于安装的那些事（下）
主流监控系统工具的集成
开始第二天的工作
8个典型故障及排查Tips
关于集群更新的那些事
说说L3VPN及EVPN集成
关于服务链、BGPaaS及其它
关于多集群和多数据中心

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

第一篇： TF主要特点和用例
第二篇： TF怎么运作
第三篇：详解vRouter体系结构
第四篇： TF的服务链
第五篇： vRouter的部署选项
第六篇： TF如何收集、分析、部署？
第七篇： TF如何编排
第八篇： TF支持API一览
第九篇： TF如何连接到物理网络
第十篇： TF基于应用程序的安全策略

TF中文社区

多云互联 · 开源开放

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

我知道你“在看”哟～

亿速云「云服务器」，即开即用、新一代英特尔至强铂金CPU、三副本存储NVMe SSD云盘，价格低至29元/月。点击查看>>

向AI问一下细节

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

TF组件的七种“武器”

关于集群更新的那些事

说说L3VPN及EVPN集成

关于服务链、BGPaaS及其它

关于多集群和多数据中心

猜你喜欢

最新资讯

相关推荐

开发者交流群：

相关标签