我们专注攀枝花网站设计 攀枝花网站制作 攀枝花网站建设
成都网站建设公司服务热线：400-028-6601

网站建设知识

十年网站开发经验 + 多家企业客户 + 靠谱的建站团队

量身定制 + 运营维护+专业推广+无忧售后，网站问题一站解决

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入门宝典丨多编排器用法及配置
浏览路径：http://mswzjz.cn/article/gohcpi.html

其他资讯