专栏首页Tungsten Fabric中文社区为OpenStack和K8s集群提供无缝虚拟网络
原创

为OpenStack和K8s集群提供无缝虚拟网络

在数据中心里,同时拥有OpenStack和Kubernetes集群的情况正变得越来越普遍。

一边是由OpenStack管理的虚拟机,另一边是由K8s控制的容器化工作负载。

现实情况下,可能会发生虚拟机和容器需要相互“交谈”的情况。如果是这样,我们需要以某种方式实现两个独立集群之间的通信。

作为两个不同的集群,每个集群都有自己的网络平面。OpenStack可能会依赖OVS,而Kubernetes则会部署某个可用的CNI。

由于每个集群都是独立于其它集群的,因此必须在第三个“元素”上启用通信。这第三个元素可以是IP Fabric。

虚拟机将通过提供商网络退出计算,并在VLAN内的IP Fabric上现身。容器也会做类似的事情。因此,我们可能最终会有两个VLAN,通过配置IP Fabric叶子节点(或spine节点)作为L2/L3 gw来允许它们相互对话。另外,L3 gw的角色可能会被委托给上层设备,比如SDN gw(在这种情况下,IP Fabric叶子节点/spine节点只会是L2 gw)。

这里的一个关键要点是,虚拟/容器化的工作负载成为underlay的一部分,使得服务平面(工作负载)和网络平面(IP Fabric)相互交错。

提供服务也需要在IP Fabric underlay进行配置。我们在探索数据中心使用Tungsten Fabric的优势时,谈到过这个概念,请见下面链接:

https://iosonounrouter.wordpress.com/2020/04/28/which-sdn-solution-is-better-what-i-learned/

同样的考虑在这里也适用,另外我们不仅需要连接虚拟机,还需要连接容器。

我们假设需要部署一个应用程序,其构件既有虚拟机又有容器。这意味着我们需要在OpenStack里部署一些对象,在Kubernetes里部署另外一些对象。从网络的角度来看,我们需要对OpenStack、K8s和IP Fabric进行操作。如果能简化这一点就好了。Tungsten Fabric来了!

TF可以与OpenStack和K8s一起工作(作为CNI)。当然,代码的某些部分是“编排器专用”的。我的意思是,TF一方面需要与Neutron/Nova进行交互,另一方面需要与K8s API和其它K8s组件进行交互。

总之,除了这些,解决方案的核心还是一样的!虚拟网络也还是VRF。工作负载也还是接口!不管我们的接口后面是虚拟机还是容器,对于Tungsten Fabric来说,它只是放到VRF中的一个接口。对于计算节点之间和通向SDN网关的overlay(MPLSoUDP、MPLSoGRE、VXLAN)也是一样的。

因此,让虚拟机与容器进行通信,只是在同一个VRF(虚拟网络)中放置接口的问题。这可以通过让一个实体来“控制”OpenStack和Kubernetes集群的虚拟网络来实现。这个实体就是我们最爱的TF Controller。

我们的数据中心将会是这样的:

如你所见,从配置的角度来看,集群还是有区别的。Kubernetes master控制容器,而OpenStack controller负责Nova虚拟机。

这里的关键变化在于Tungsten Fabric控制器(controller)的存在,它将与OpenStack计算节点和Kubernetes worker节点进行交互(仍然使用XMPP)。这样我们就为集群提供了一个单一的网络平面。

由于TF在overlay层工作,我们不再需要IP Fabric来“看到”虚拟机和容器。工作负载的流量被隐藏在overlay隧道中(无论是在计算节点之间,还是通向SDN网关……就像任何一个TF集群一样)。

拥有一个单一的网络平面还会带来其它优势。例如,TF将负责IP地址分配。假设我们有一个地址为192.168.1.0/24的虚拟网络。如果我们在该VN上创建一个虚拟机,TF将分配地址192.168.1.3。之后,如果我们在Kubernetes中创建一个容器,并将其连接到同一个VN,TF将分配地址192.168.1.4,因为它知道.3已经在使用。如果有两个不同的集群,实现这个功能需要额外的“工具”(例如配置静态分配池或让更高级别的编排器充当IPAM管理器角色)。Tungsten Fabric则简化了这种网络操作。

现在,理论已经说得够多了。让我们来看一个实际的例子!

我在一个虚拟实验室中构建了上述拓扑。为了部署Tungsten Fabric,我使用了Ansible部署器,它允许我们同时配置OpenStack和Kubernetes集群。我不会去详细介绍如何使用Ansible部署器安装TF(这里是一个部署K8s集群的例子);我假设对这个工具有预先的了解。

大家知道,Ansible部署器的核心是instances.yaml文件。下面是我使用的一个文件:

###FILE USED TO DESCRIBE THE CONTRAIL CLOUD THAT ANSIBLE DEPLOYER HAS TO BUILD
global_configuration:
  CONTAINER_REGISTRY: hub.juniper.net/contrail
  CONTAINER_REGISTRY_USERNAME: xxx
  CONTAINER_REGISTRY_PASSWORD: yyy
provider_config:
  bms:
    ssh_user: root
    ssh_pwd: Embe1mpls
    ntpserver: 10.102.255.254
    domainsuffix: multiorch.contrail
instances:
  cnt-control:
    provider: bms
    ip: 10.102.240.183
    roles:
      config:
      config_database:
      control:
      webui:
      analytics:
      analytics_database:
      analytics_alarm:
  os-control:
    provider: bms
    ip: 10.102.240.178
    roles:
      openstack:
  os-compute:
    provider: bms
    ip: 10.102.240.171
    roles:
      vrouter:
        VROUTER_GATEWAY: 192.168.200.1
      openstack_compute:
  k8s-master:
   provider: bms
   roles:
      k8s_master:
      kubemanager:
   ip: 10.102.240.174
  k8s-worker:
   provider: bms
   roles:
     vrouter:
       VROUTER_GATEWAY: 192.168.200.1
     k8s_node:
   ip: 10.102.240.172
contrail_configuration:
  CLOUD_ORCHESTRATOR: openstack
  CONTRAIL_CONTAINER_TAG: 2008.121
  CONTRAIL_VERSION: 2008.121
  OPENSTACK_VERSION: queens
  ENCAP_PRIORITY: "VXLAN,MPLSoUDP,MPLSoGRE"
  BGP_ASN: 65100
  CONFIG_NODEMGR__DEFAULTS__minimum_diskGB: 2
  DATABASE_NODEMGR__DEFAULTS__minimum_diskGB: 2
  CONFIG_DATABASE_NODEMGR__DEFAULTS__minimum_diskGB: 2
  KUBERNETES_CLUSTER_PROJECT: {}
  KUBERNETES_API_NODES: 192.168.200.12
  KUBERNETES_API_SERVER: 192.168.200.12
  KUBEMANAGER_NODES: 192.168.200.12
  RABBITMQ_NODE_PORT: 5673
  KEYSTONE_AUTH_URL_VERSION: /v3
  VROUTER_GATEWAY: 192.168.200.1
  CONTROLLER_NODES: 10.102.240.183
  CONTROL_NODES: 192.168.200.10
  JVM_EXTRA_OPTS: "-Xms1g -Xmx2g"
  PHYSICAL_INTERFACE: "ens3f1"
kolla_config:
  kolla_globals:
    enable_haproxy: no
    enable_ironic: no
    enable_swift: no
    enable_barbican: no
  kolla_passwords:
    keystone_admin_password: contrail123
    metadata_secret: meta123

实例部分包括5台服务器:

  • openstack controller
  • kubernetes master
  • contrail controller
  • openstack compute
  • kubernetes worker

如果你去看“contrail_configuration”部分,就会注意到我们配置TF是为了与openstack controller(KEYSTONE_AUTH_URL_VERSION)和kubernetes master(KUBERNETES_API_NODES)交互。

一旦所有节点都做好安装准备,从“deployer”节点(可以是contrail controller本身)运行以下命令:

ansible-playbook -e orchestrator=openstack -i inventory/ playbooks/configure_instances.yml
ansible-playbook -e orchestrator=openstack -i inventory/ playbooks/install_openstack.yml
ansible-playbook -e orchestrator=openstack -i inventory/ playbooks/install_k8s.yml
ansible-playbook -e orchestrator=openstack -i inventory/ playbooks/install_contrail.yml

如果一切顺利的话,我们的集群应该可以运行了。

让我们连接到Tungsten Fabric GUI:

我们看到两个虚拟路由器:os-compute和k8s-worker!

我们看一下控制节点:

只有一个控制器!我们“单一网络平面”的关键概念变成了现实。

接下来,我创建了一个虚拟网络:

  • FQ名称:default-domain:k8s-contrail:seamless
  • CIDR:192.168.1.0/24

启动一个连接到该VN的虚拟机:

nova boot --image cirros2 --flavor cirros --nic net-id=<seamless_uuid> vm
(kolla-toolbox)[ansible@os-control /]$ nova list
+--------------------------------------+------+--------+------------+-------------+------------------------+
| ID                                   | Name | Status | Task State | Power State | Networks               |
+--------------------------------------+------+--------+------------+-------------+------------------------+
| 3cf82185-5261-4b35-87bf-4eaa9de3caaf | vm   | ACTIVE | -          | Running     | seamless=192.168.100.3 |
+--------------------------------------+------+--------+------------+-------------+------------------------+

接下来,创建一个连接到该VN的容器:

[root@k8s-master ~]# cat cn.yaml
---
kind: Namespace
apiVersion: v1
metadata:
  name: seamless
  annotations:
    'opencontrail.org/network' : '{"domain":"default-domain", "project": "k8s-contrail", "name":"seamless"}'
  labels:
    name: seamless
---
apiVersion: v1
kind: Pod
metadata:
  name: cont
  namespace: seamless
spec:
  containers:
  - name: cont
    image: alpine
    command: ["tail"]
    args: ["-f", "/dev/null"]
kubectl apply -f vn.yaml
[root@k8s-master ~]# kubectl get pod -n seamless -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE         NOMINATED NODE   READINESS GATES
cont   1/1     Running   0          74s   192.168.100.4   k8s-worker   <none>           <none>
[root@k8s-master ~]# kubectl get -f cn.yaml -o wide
NAME                 STATUS   AGE
namespace/seamless   Active   31m
NAME       READY   STATUS    RESTARTS   AGE   IP              NODE         NOMINATED NODE   READINESS GATES
pod/cont   1/1     Running   0          31m   192.168.100.4   k8s-worker   <none>           <none>

如你所见,由于192.168.100.3已经被VM占用了,pod被分配了192.168.100.4的IP地址。这也是多个集群使用单一网络平面的优势之一。

让我们从GUI中查看一下路由表:

两个IP都有!我们刚刚把一个虚拟机连接到一个工作负载上……而这对underlay是完全透明的!

让我们再到worker节点,查看一下vRouter代理:

(vrouter-agent)[root@k8s-worker /]$ vif --get 3
Vrouter Interface Table
vif0/3      OS: tapeth0-11ccbe NH: 51
            Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:192.168.100.4
            Vrf:4 Mcast Vrf:4 Flags:PL3L2DEr QOS:-1 Ref:6
            RX packets:67  bytes:2814 errors:0
            TX packets:87  bytes:3654 errors:0
            Drops:67
(vrouter-agent)[root@k8s-worker /]$ rt --get 192.168.100.3/32 --vrf 4
Match 192.168.100.3/32 in vRouter inet4 table 0/4/unicast
Flags: L=Label Valid, P=Proxy ARP, T=Trap ARP, F=Flood ARP
vRouter inet4 routing table 0/4/unicast
Destination           PPL        Flags        Label         Nexthop    Stitched MAC(Index)
192.168.100.3/32        0           LP         25             39        2:85:bf:53:6b:67(96024)
(vrouter-agent)[root@k8s-worker /]$ nh --get 39
Id:39         Type:Tunnel         Fmly: AF_INET  Rid:0  Ref_cnt:8          Vrf:0
              Flags:Valid, MPLSoUDP, Etree Root,
              Oif:0 Len:14 Data:56 68 a6 6f 05 ff 56 68 a6 6f 06 f7 08 00
              Sip:192.168.200.14 Dip:192.168.200.13

所有的路由信息都在那里!容器可以通过连接Kubernetes worker节点和OpenStack计算节点的MPLSoUPD隧道到达虚拟机。

这样就可以进行通信了吗?还不行!别忘了安全组还在那里!

虚拟机属于一个OpenStack项目(这里是管理项目),而容器属于另一个项目(映射到Kubernetes命名空间)。每个项目都有自己的安全组。默认情况下,安全组只允许来自属于同一安全组的入口流量。由于两个工作负载的接口被分配到不同的安全组,因此它们之间不允许对话!

为了解决这个问题,我们需要对安全组采取行动。

简单的方法是在两个安全组上都允许来自0.0.0.0/0的入口流量(这是容器安全组,但同样也可以在虚拟机安全组上进行):

另外,我们也可以在入口方向允许特定的安全组。

例如,在k8s-seamless-default-sg(容器所属命名空间/项目的安全组)上,我们允许默认安全组(虚拟机所属OpenStack项目的安全组)。

同样地,也可以在分配给虚拟机接口的安全组上进行:

现在,让我们访问容器,并且ping一下虚拟机:

[root@k8s-worker ~]# docker ps | grep seaml
18c3898a09ac        alpine                                                         "tail -f /dev/null"      9 seconds ago       Up 8 seconds                            k8s_cont_cont_seamless_e4a7ed6d-38e9-11eb-b8fe-5668a66f06f8_0
6bb1c3b40300        k8s.gcr.io/pause:3.1                                           "/pause"                 17 seconds ago      Up 15 seconds                           k8s_POD_cont_seamless_e4a7ed6d-38e9-11eb-b8fe-5668a66f06f8_0
[root@k8s-worker ~]# docker exec -it 18c38 sh
/ # ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:e4:e5:52:ce:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.4/24 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping 192.168.100.3
PING 192.168.100.3 (192.168.100.3): 56 data bytes
64 bytes from 192.168.100.3: seq=0 ttl=64 time=3.813 ms
64 bytes from 192.168.100.3: seq=1 ttl=64 time=1.802 ms
64 bytes from 192.168.100.3: seq=2 ttl=64 time=2.260 ms
64 bytes from 192.168.100.3: seq=3 ttl=64 time=1.945 ms
^C
--- 192.168.100.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.802/2.455/3.813 ms
/ #

就是这样!虚拟机和容器可以互相对话了!

无论你的工作负载是虚拟机还是容器……至少从网络的角度来看,一切都是在Tungsten Fabric的机制下进行的。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Tungsten Fabric如何编排

    OpenStack是虚拟机和容器的领先的开源编排系统。Tungsten Fabric提供了Neutron网络服务的实现,并提供了许多附加功能。

    Tungsten Fabric
  • OpenStack与K8s结合的几种方案之比较

    OpenStack与K8S结合主要有两种方案。一是K8S部署在OpenStack平台之上,二是K8S和OpenStack组件集成。

    小小科
  • Tungsten Fabric与K8s集成指南丨创建隔离命名空间

    K8s与Tungsten Fabric集成后有四种配置模式,分别为:默认模式、自定义隔离模式、命名空间隔离模式、嵌套模式。

    Tungsten Fabric
  • k8s网络开发丨k8s与OpenStack网络如何打通?

    点击上方“腾讯云TStack”关注我们 获取最in云端资讯和海量技术干货 ? ? 本文作者 / ice yao 喜欢看动漫的IT男 还是火影迷、海贼迷、死神...

    腾讯云TStack
  • 四种模式、七大元素:玩转TF+K8s CNI集成部署

    Tungsten Fabric从4.0版本起,就开始支持用于将Kubernetes自动化平台与TF的集成的容器网络接口(CNI)。本文就来介绍基于CNI的TF+...

    Tungsten Fabric
  • 6年!我对赖以挣小钱度日的OpenStack淌过的河...

    看了世民(Sammy Liu)的 OpenStack的八年之痒一文后,作为从2012年起从E版本就开始使用OpenStack的一个相对老手,我倒是想附和一篇文章...

    SammyLiu
  • OpenStack 与 Kubernetes 的共存

    OpenStack是面向资源层的IaaS云平台管理软件,可以帮助用户构建和管理私有云和公有云。

    灵雀云
  • CSDN专访|腾讯的OpenStack实践与创新

    前言: 本文转载自微信公众号OpenStack 文章《用户访谈丨腾讯的OpenStack实践与创新》,来自CSDN专访。 2017年7月24日~25日,2017...

    腾讯云TStack
  • 2017 Openstack Days China | 腾讯的Openstack实践与创新

    本文转载自CSDN 2017年7月24日~25日,2017 OpenStack Days China官方盛典在北京国家会议中心盛大召开。腾讯技术工程事业群企业...

    腾讯技术工程官方号
  • 2017 Openstack Days China | 腾讯的Openstack实践与创新

    本文转载自CSDN 2017年7月24日~25日,2017 OpenStack Days China官方盛典在北京国家会议中心盛大召开。腾讯技术工程事业群企业I...

    腾讯高校合作
  • 干货 | 云计算时代携程的网络架构变迁

    赵亚楠,携程云平台资深架构师。2016 年加入携程云计算部门,先后从事 OpenStack、SDN、容器网络(Mesos、K8S)、容器镜像存储、分布式存储等产...

    携程技术
  • 技术实录 | 灵雀云基于 OVN 的 Kubernetes 网络架构解析

    本文为3月26日灵雀云Kubernetes专家刘梦馨在Dockone社区的主题分享。他从Kubernetes网络的局限性、OVS和OVN网络方案的能力、OVN和...

    灵雀云
  • 基于 OVN 的 Kubernetes 网络

    基于3月26号,在 Dockone 社区的分享整理的内容,效果还不错,最后的QA环节问题超级多,据说是之前最多一次的两倍。这次只是基本概念的介绍,具体我们的架构...

    Oilbeater
  • Kubernetes系列学习文章 - 学习K8S的基础(三)

    | 导语 上一篇文章我们讲解了什么是kubernetes(K8S) ,你对K8S的概念目前已经有个初步的了解。很多同学估计想开始着手学习了,这篇文章我们来了解...

    宝哥@上云专家
  • TF功能开发路线图:盘点2021年Tungsten Fabric聚焦领域

    在Linux基金会主办的“LFN技术会议”上,Tungsten Fabric社区进行了一系列演讲,介绍最新的功能和未来发展方向。今天带来第一篇演讲,看看Tung...

    Tungsten Fabric
  • OpenStack的八年之痒

    2010年10月,OpenStack发布了第一个版本;上个月,发布了它的第18个版本Rocky。几年前气氛火爆,如今却冷冷清清。Rocky版本宣布后,OpenS...

    SammyLiu
  • 看懂云计算、虚拟化和容器,这一篇就够啦!

    作为信息科技发展的主流趋势,它频繁地出现在我们的眼前。伴随它一起出现的,还有这些概念名词——OpenStack、Hypervisor、KVM、Docker、K8...

    鲜枣课堂
  • Kube-OVN 社区规划Roadmap 2021-2022 | What’s the next?

    作为全球首个被CNCF纳入托管的开源CNI网络项目,Kube-OVN已经成为K8s生态中功能最完备、对传统基础设施兼容性最佳的开源网络组件。

    灵雀云
  • 基于Tungsten Fabric打通异构资源网络

    作为开源SDN的代表,不少厂商都基于Tungsten Fabric开发出了成熟的应用方案,华胜天成异构混合云管理平台就是其中一例。由华胜天成自主开发的统一云平台...

    Tungsten Fabric

扫码关注云+社区

领取腾讯云代金券