使用Kubernetes, Docker Swarm和Cloudify进行混合容器编排

在本文中，我提出了一个包含Kubernetes和Swarm容器管理的混合VNF编排，以及传统的主机。这个想法是想探索通过这个方案所带来的挑战和机遇。...

作者：Dewayne Filppi

翻译：袁思思

来源：DZone

原文链接：https://dzone.com/articles/hybrid-container-orchestration-with-kubernetes-docker-swarm-and-cloudify

见证工具、体系架构、代码和程序，为容器建立一个混合虚拟网络架构协调。

在NFV（网络功能虚拟化）世界，在Linux主机容器中运行，协调虚拟网络功能（VNFs）是一个新兴挑战。在高响应和密集部署的需求驱动下，并且希望通过现代微服务架构，用户和供应商发现容器有一个有吸引力的前景。在本文中，我提出了一个包含Kubernetes和Swarm容器管理的混合VNF编排，以及传统的主机。这个想法是想探索通过这个方案所带来的挑战和机遇。容器化VNFs世界是有点局限性的（不夸张的说），将运行在Kubernetes或Docker Swarm箱中之外，所以我通过这次标准Linux网络组件容器化版本的探索，Quagga路由和Nginx配置作为一个负载均衡器。

目标架构架构由一些类似的构建模块组成； Kubernetes模板，Kubernetes插件，Docker Swarm模板和部署代理插件。另外，我们使用了一个尚未发布的Docker Swarm插件。

基础的想法是在Docker Swarm上通过一个VNF运行网络通信，然后在Kubernetes运行另一个VNF。在这个例子中，在Swarm上通过一个Nginx容器，通信是负载均衡的，该负载均衡是一对VMs在另一面的容器化Quagga实例。自动化进程

任何自动编排的第一步就是确认创建理想最终状态的步骤（在需要时核实）。Cloudify的最终状态是由TOSCA模板或模板来定义。Kubernetes和Swarm集群是显然需要的，连同必备的网络安装程序。为了反映出一个合理的产品设置，这些集群需要单独部署生命周期，因此作为被单独模板来建模。目前的Kubernetes和Swarm集群模板是一个好的起点，但是需要一些调整。然后第三种模板是需要在每个集群上实际部署和配置的。

Kubernetes集群模板

每当考虑一个由多种模板组成的编排计划，一个考虑的关键因素就是输出。Cloudiy部署代理实现了通过复制配置模板输出的目标，因此所含模板可以执行它所需的任务。在本例中，“所含模板”将服务部署到Kubernetes集群的模板并且（可能）获得目标VMs运行Apache的IP地址。Kubernetes集群URL早已存在于标准Kubernetes模板输出中。为了方便起见， Kubernetes模板将会更改，创建 10.100.102.0/24 网络和Apache VMs。由于启动VMs，模板将访问IPs和子网络（借助一个Cloud API,一个主机IP工具，或者硬编码）。这些可以展示的输出如下：

outputs:

apache_info:

value:

network: {get_property: [ apache_subnet, subnet, cidr ]

ips: {concat: [ {get_attribute: [ apache_host1, ip ] }, "," , {get_attribute: [ apache_host2, ip ] } ] }

除了简单的启动实例，启动Apache网络服务并且提供一个可辨认的 index.html，以便通过 curl来验证负载均衡。另外，为了匹配架构，Kubernetes模板必须变成在 10.100.101.0/24 网络运行集群。为了安装渐变，集群将只有一个节点，将包括Quagga路由和一个连接到 10.100.102.0/24 网络的接口。

VNF准备

Quagga通过操作Linux内核路由表来运作。无特许的容器在它们自己的命名空间中运行，所以不会影响默认表。允许Quagga进入路由表，它必须在特许模式下运行，授权给运行Kubernetes daemon（kubelet）和 --allow-privileged 选项。Kubernetes模板例子已经实现。除了特许模式提供进入主机网络堆栈。这块包含在服务模板的部分。

Docker Swarm模板

目前的Docker Swarm集群模板除了在 10.100.100.0/24 网络定位集群仍然几乎没变，以及有一个10.100.101.0/24网络接口。对于一个OpenStack平台，这将意味着在现有的Kubernetes网络定义一个Port节点，并且定义一个实例和port之间的关系。

当我们期望最终结构，需要注意的是在Swarm主机上没有路由规则来发送通信去1.100.102/24Quagga的路由。这有一些处理静态的方法，但是可能最简单就是增加一个 userdata 部分来增加路径（假设云基础设施）。裸机设置可能使用Fabric插件来远程增加规则。

userdata 像这样（改写）：

userdata: |

ip route add { get_input: [ quagga_net ] } via { get_input: [ quagga_host ] } dev eth1

服务模板

service 模板有义务对两个集群部署微服务（即 VNFs）和正确配置它们。它通过利用一个插件"代理"，Kubernetes和Swarm模板如上所述，并且通过使用Kubernetes和Swarm插件来实际部署。

在Kubernetes上编排Quagga容器

Quagga使用一个原生的描述符部署在Kubernetes。在这个例子里，Quagga仅为了服务静态路由部署。典型的Kubernetes插件，Kubernetes描述符在模板中可能涉及到一些重写及使用的容器可以自我配置的环境变量。在本例中，为了Kubernetes部署Quagga路由通过检查部署代理输出，创建一些静态路由来埋下种子，并且在环境中经过它们到容器。

quagga:

type: cloudify.kubernetes.Microservice

properties:

name: nginx

ssh_username: ubuntu

ssh_keyfilename: /root/.ssh/agent_key.pem

config_files:

- file: resources/kubernetes/pod.yaml

- file: resources/kubernetes/service.yaml

env:

ROUTES: [ {concat: [ get_property: [ kubernetes_proxy, vm_info, apache_subnet ], " dev eth1" ]} ]

relationships:

- type: cloudify.kubernetes.relationships.connected_to_master

target: kubernetes_proxy

Quagga容器部署描述符很简单，但是节点必须通过特许访问运行并且使用主机网络堆栈：

apiVersion: v1

kind: ReplicationController

metadata:

name: quagga

spec:

replicas: 1

selector:

app: quagga

template:

metadata:

name: quagga

labels:

app: quagga

spec:

hostNetwork: true

containers:

- name: quagga

image: dfilppi/quagga

workingDir: /

command: ["bash","start.sh"]

ports:

- containerPort: 2601

hostIP: 0.0.0.0

securityContext:

_privileged: true_

在容器中的初始脚本负责填充静态路由和启动路由器。附注，在实例中假设ip转发已转变。

部署和配置Nginx容器

最后一块拼图就是部署Nginx容器。唯一的重要结构步骤就是提供负载均衡主机列表。方法和在Kubernetes中使用类似（通过在环境变量中配置），但是插件不同。然后Kubernetes插件使用原生Kubernetes描述符，当下Swarm插件版本不能为Swarm处理同等的量(Docker Compose)。反而，在模板中的配置更加明确，通过插件定义cloudify.swarm.Microservice, cloudify.swarm.Container, 和 cloudify.swarm.Port 类型。在本例中，容器接受环境配置和图片参考。

nginx_container:

type: cloudify.swarm.Container

properties:

image: dfilppi/nginx2

entry_point: start.sh

env:

SERVERS: {get_attribute: [kubernetes_proxy,vm_info,ips]}

注意在Swarm集群中 SERVERS 如何定义连接Kubernetes模板动态输出到容器配置。代理模式，混合编排应用离这个深奥的用例很远。它类似于先前的编排中采取的方法，证实了在Kubernetes中由在VMs云上活动引发。

结论

这篇文章演示了Cloudify编排一个服务链，跨越多种容器管理引擎。原因就是在一个“没有标准”的世界中展示了Cloudify的灵活性，那里VNFs可能自认为管理员在它上面运行。在这样的世界，Cloudify可用于编排不同的平台为了交付最终用户解决方案，不管可能出现下一个大事。同样的原则可应用于其他容器和IAAS编排(例如 Swarm, Mesos, Openstack Heat, AWS CloudFormation)。它还允许根据需要编排旧系统和硬件，使用一个标准开放模式(TOSCA)。Cloudif不固执己见的本职也允许针对高性能/裸机平台，特别是对NFV至关重要。这个例子源代码即将来临。

推荐

• NFS over CephFS vs. NFS over RGW
• Docker资源管理探秘：Docker背后的内核Cgroups机制

    关注 博云