基于OpenStack和Kubernetes构建组合云平台——网络集成方案综述

一谈到云计算，大家都会自然想到三种云服务的模型：基础设施即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）。OpenStack已经成为私有云IaaS的标准，而PaaS层虽然有很多可选技术，但已经确定统一的是一定会基于容器技术，并且一定会架构在某种容器编排管理系统之上。在主流的容器编排管理系统Kubernetes、Mesos和Swarm中，Kubernetes以它活跃的社区，完整强大的功能和社区领导者富有远见的设计而得到越来越多的企业青睐。我们基于OpenStack和Kubernetes研发了全球首个实现容器和虚拟机组合服务、统一管理的容器云平台。在本文中我们将分享我们在集成OpenStack和Kubernetes过程中的网络集成方案的经验总结。

Kubernetes的优秀设计

图 1 Kubernetes集群的架构

在我们介绍网络方案之前，先向大家简单介绍一下Kubernetes的基础构架。
一个Kubernetes集群是由分布式存储（etcd），服务节点（Minion）和控制节点（Master）构成的。所有的集群状态都保存在etcd中，Master节点上则运行集群的管理控制模块。Minion节点是真正运行应用容器的主机节点，在每个Minion节点上都会运行一个Kubelet代理，控制该节点上的容器、镜像和存储卷等。

支持多容器的微服务实例

Kubernetes有很多基本概念，最重要的也是最基础的是Pod。Pod是一个运行部署的最小单元，他是可以支持多容器的。为什么要有多容器？比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。

自动提供微服务的高可用

Kubernetes集群自动提供微服务的高可用能力，由复制控制器（Replication Controller）即RC进行支持。RC通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。

微服务在集群内部的负载均衡

在Kubernetes内部，一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。在Kubernetes中真正对应一个微服务的概念是服务（Service），每个服务会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个微服务。

图 2 Kubernetes集群内的负载均衡

在Kubernetes集群中，集群管理员管理的是一系列抽象资源，例如对应一个微服务的抽象资源就是Service；对应一个微服务实例的抽象资源就是Pod。从Service到Pod的数据转发是通过Kubernetes集群中的负载均衡器，即kube-proxy实现的。Kube-proxy是一个分布式代理服务器，在Kubernetes的每个Minion节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多&