悉尼峰会： OpenStack 与 Kubernetes 融合之路

导读

    

      看来， Kubernetes 融合 OpenStack 确实是条门路！从波士顿到悉尼，可见越来越多的使用者已经感受到了二者融合使用的化学反应，相信接下来的两天这个话题还会有更精彩丰富的内容。

澳大利亚悉尼当地时间11月6号上午9点，第16届OpenStack峰会在悉尼国际会议中心盛大开幕，来自全球52个国家2300余名与会者，将就以OpenStack为核心的开放基础架构相关技术和商业实践展开为期三天的讨论。

感谢  EasyStack 王博、Rico、方真、王俊 发自悉尼现场的报道

OpenStack 是私有云底层框架的首选之一。 Kubernetes 就目前趋势来说亦势不可挡。

在上次波士顿峰会时， OpenStack+ Kubernetes 已经是一大议题。半年过后该议题热度不减，这次峰会上不少成果发表也都围绕这个主题。不只是因为这是OpenStack 峰会而能够听到相关主题，更是因为使用者需求进而调研产生的技术与产品，比如怎样运用这些技术来达成软件定义或持续集成等重大工作这样的主题，都是从社区中、使用者那获得的。

从技术方向来说，把 OpenStack 建构于 Kubernetes 之上或是将 Kubernetes 建构于 OpenStack 之上，是两大融合方向。

相信两者最终会融合。

实际上，在 OpenStack 4月的使用者调查中可以看到其实不少的 OpenStack 使用者，在运营环境中用 OpenStack 来管理 COE （K8S， Swarm， Mesos）

（from https://www.openstack.org/assets/survey/April2017SurveyReport.pdf）

推动技术融合，最后会获得的好处是，从 OpenStack 取得硬件资源管理与软件定义能力，从容器化取得内存空间优化、IO 优化（实际测试，在未将硬体优化列入测试范畴下，容器IO延迟约2%，VM 约15%，因此针对高 IO 的微服务应用程序来说有较好的效能提升）。

目前  OpenStack + Kubernetes  架构仍是唯一能让 Kubernetes 享有多租户与软件定义（网络，存储等）的方案。

由以上观察希望能让大家了解 OpenStack+ Kubernetes 技术融合的需求与背景。

此次悉尼峰会，本文章会接续上次峰会，继续讨论关于Kubernetes on OpenStack 的进展与实况。当然也会同步带上 OpenStack on Kubernetes 上的资讯。

就 Kubernetes on OpenStack 这种使用场景，Magnum 无疑是使用最简单功能最全的集群管理工具，同时 Magnum 也是 OpenStack 社区的标准项目，可谓后盾强大。

在 “ Magnum project onboard ” 的 session 中， Mangum PTL Spyros Trigazis  介绍了 Magnum  Project 在 Pike 版本中完成的工作，以及接下来 Queens cycle  的主要工作。

下面笔者挑选一些重要内容与大家分享。

 Pike 中已经完成的工作［1］：

Magnum 部署的 K8S 集群默认包含了 kube-dashboard;

集群默认使用 cAdvisor， node-exporter， Prometheus and Grafana 的组合实现监控;

Magnum 支持为 ETCD 挂载独立的 cinder-volume 以实现 ETCD 数据持久化;

除上述内容外，最想和大家分享的是基于 fedora-atomic 这个 OS 的 Kubernetes  集群的所有组件已实现容器化： https://github.com/projectatomic/atomic-system-containers。包括：Docker daemon，  ETCD ， flanneld， Kube-apiserver etc 。

看到这里大家可能会有疑问：为什么 Docker damon 也容器化了，如果 Docker daemon 不运行的话，这些 Docker image 怎么启动？

这里 fedora-aotmic 利用了现有的几个技术提出一个新名词：System Containers 。原理是 OSTree 存储镜像，Skopeo 拉镜像，runC 跑容器，Systemd 做容器生命周期管理， 所以在 Dockerdaemon 启动之前就可以由 Systemd 管理由 runC 启动容器。

所有组件容器化带来的好处是：每个组件更方便管理和升级。更大的好处是 K8S 集群本身可以实现升级，Cluster upgrade 也正是 Queen cycle 的主要工作 。

Queen 中要做的工作［2］：

Cluster upgrade， 重要的事情说三遍，说三遍，说三遍。

Magnum 要支持 cluster upgrade了。因为 Docker 和 Kubernetes 的快速迭代，升级已成为 K8S 玩家面临的大问题，基于上文的阐述，Cluster upgrade 将支持所有的集群组件升级。升级过程可能会根据 COE Driver 而不同，以 K8S 为例，先升级 master 节点，再升级 nodes 节点，升级过程支持 Rolling update ，即对于 slave 节点，选取一个节点，清空 workload，标记为 unschedulable，删除节点，添加升级后的新节点，标记为 schedulable，再对其他 slave 节点做同样操作。上文提到的  ETCD  数据持久化，为升级扫清了障碍。

Clusternode replacement， 替换集群中的指定节点，当发现集群中某个节点工作异常且没法修复，那我们可以通过删除这个节点用新节点代替的方式来解决。目前Heat已经支持删除集群中的指定节点，Magnum 需要做的是添加这个 API ，同时将 Heat 的操作结果和新的集群节点信息同步到 Magnum 数据库。

clusterhealing， 集群自愈，COE 可以周期性地监控并检测到集群的非健康状态，可以自动触发或者通过用户手动触发非健康节点的替换。

上述工作都是 target 到 Q 版本的 BP ，这些功能相当令人期待。从这些功能来看，Magnum 将不再只负责 create 和 delete，而是尽职尽责地管理 cluster 的整个生命周期，请大家为即将到来的 Q 版本 Magnum 打 call 。

［1］https://docs.openstack.org/releasenotes/magnum/pike.html

［2］https://blueprints.launchpad.net/magnum/queens

在技术议程 “ Putting OpenStack on Kubernetes： What tools can we use？ ” 中 Flavio （OpenStack TC）讨论到 OpenStack onKubernetes 的技术融合部分。讨论我们可以使用什么工具，来完成秒级上线操作、服务生命周期管理、弹性调度，以及更好的升级条件等。

下面介绍 OpenStack on Kubernetes 架构的需求与现有工具。

OpenStack-helm 与 Kolla-Kubernetes 都是许多人可能知道的方法，但是在议程中， Flavio 分享的是第三个选择，TripleO。目前 TripleO 正在进行几项工作，要将底层变成 Kubernetes。他建议大家要思考与注意几项要点：

1.使用 K8s 后，势必要多运维一套分布式系统；

2.注意网络创建，OpenStack 实际环境向来不只一段网络，虽然 K8s 最近已经新增多网段支持，但仍需小心使用，因为成熟度还须调校。

3.IPv6 部分 K8s 目前刚宣布支持，但毕竟是新功能，使用前建议先测试。

4.Kubernetes cluster HA 目前仍未在社区支持。

另外建议，将节点命名或标记加上各自功能，让使用者知道实际节点用途。节点上则可以根据标记运行个别服务。

还有善用 ConfigMaps 来存放 OpenStack 布署时的设定参数。

最后建议将 NameSpace 区隔以作分离环境用途。

在技术议程 “ Building OpenStack on Kubernetes for Zero Downtime Large-scaleProduction SaaS ” 中，来自 Workday 的两位演讲人分享了他们在Kubernetes 上构建生产级 OpenStack 的经验，为上个议程的融合部署观点做了精彩的实践注解。

在他们的部署中，主要解决了 OpenStack 部署和运行过程中以下几个问题：系统高可用高可靠，简化 HA 部署，CICD，无宕机平滑升级，可根据业务需求伸缩。

同时，生产部署还考虑安全、认证、容器镜像的安全扫描，集中式的日志管理以及服务 SLA 等问题。

Workday OpenStack 的架构如下图所示，区分了有状态服务和无状态服务。例如mariadb 使用了 galera 集群方案等。而 OpenStack 的各种无状态服务加入到容器管理相对更容易。

借助 Kubernetes，Helm 以及 Ansible，解决了大部分编排和部署的问题。

另一方面，需要搭建一套完整的 CICD 流程来自动化构建。

整个构建流程如下图所示：通过更新 rpm 到 yum repo ，用于构建 Docker 镜像。借助 Kolla 的能力，构建镜像并上传至内部镜像仓库，可以用于接下来的部署以及测试工作。构建好的 Container 镜像的部署是通过 OpenStack-Helm 来进行的。

最后，演讲者基于他们的使用经验给出了一些好的建议。例如，从 Source 构建container 而不是从 binary package 来构建；妥善管理密码等机密信息；复用现有的编排工具（Kubernetes）而不是完全从头开始构建。

 Workday 在生产级部署 OpenStack on Kubernetes 的经验，对于其他希望基于Kubernetes 构建OpenStack云的厂商有非常重要的借鉴意义，显示了 OpenStack on Kubernetes 落地的巨大潜力所在，也让我们看到了更多可改进和完善的地方。

悉尼峰会第一天，就强烈地感受到了 OpenStack + Kubernetes 的融合热度依旧，势不可挡。从波士顿到悉尼，可见越来越多的使用者已经感受到了二者融合使用的化学反应，相信接下来的两天这个话题还会有更精彩丰富的内容。

再次感谢  EasyStack 工程师们 发自悉尼现场的报道

投稿邮箱：openstackcn@sina.cn