在 Kubernetes 上部署 OpenStack 是什么体验

微信扫一扫,分享到朋友圈

在 Kubernetes 上部署 OpenStack 是什么体验

红蓝出 CP,OpenStackKubernetes 在一起会怎样?

背景

从去年开始就想深入地学习 Kubernetes,首先想到是在 OpenStack 上能比较轻松地玩转,所以去 尝试了 Magnum ,但是结果令人失望。

不过随着我搜索到更多的内容,发现一个有趣的事情:

那就是相较于在 OpenStack 之上部署 Kubernetes,通过 Kubernetes 去部署 OpenStack 似乎更流行。

特别当我去研究最近比较热门的边缘计算,发现 OpenStack 社区的两个相关项目,一个是 StarlingX ,一个是 Airship ,它们都是这样做的:先搭建 Kubernetes 集群,然后通过 OpenStack-Helm 部署容器化的 OpenStack。

但是这两个项目都还挺复杂,直接去部署它们遇到了不少坑,做了很多的前置操作,涉及到很多脚本代码,结果到搭建 K8s 步骤上还是卡住了。

于是我决定暂时先不管它们,直接跳到 OpenStack-Helm,至少让我先体验一下基于 Kubernetes 的 OpenStack 到底是啥样。

这样就又回到了起点:我得先有一套 Kubernetes 多节点集群,但是现在只有一套 OpenStack 环境,所以我仍然得先解决在 OpenStack 上搭建 Kubernetes 的问题。

经过了一番摸索,踩了不少坑,最后终于完成了这次尝试。

下面简单地分享下最终的效果,其中的过程涉及较多,后续再择机分享。

整个环境概况

整个环境架构

最上层:一个普通的 OpenStack 环境

在上面的 OpenStack 中用 cirros 镜像创建了一个虚机:

image-20200608163640522

细心的你可能已经发现这里的端口号不是默认的 80,而是比较奇怪的 32557,这是因为这个 openstack 环境是搭建在 Kubernetes 集群上,而且通过 NodePort 暴露的服务。

在页面上查看 openstack 的系统信息:

image-20200608163959155

各个服务的 endpoints URL 都是以 *.openstack.svc.cluster.local 域名的形式,熟悉 Kubernetes 的应该看上去有点眼熟。

OpenStack 在 Kubernetes 中的细节

下面详细地看看 OpenStack 在集群中是怎么一回事:

Helm

全部使用 Helm 部署:

helm list

Ingress

Public接口是通过 Ingress 暴露的:

ingress

Service

更多的内部接口则可以在 service 中看到:

service

注意 horizon-int 对应的就是 Dashboard 服务,它的类型是 NodePort 而且映射的端口号是 32557

DaemonSet

各种 agent 包括计算节点、OVS、Libvirt 等,都是通过 DaemonSet :

daemonsets

StatefulSet

带状态的数据库和消息队列,以 StatefulSet 的形式:

statefulset

Job

还有部署过程中的各种任务,包括初始化数据库,注册 endpoint 等,都是以 job 方式执行的:

job

Pod

最终所有这些 pod 构成了这个 openstack 环境:

pod

PV 和 PVC

当然还要用到持久化的卷存储,即 PersistentVolumeClaimPersistentVolume

pv and pvc

Ceph

持久化存储由 ceph 提供,它们同样部署在当前集群中 :

ceph

中间层:Kubernetes on OpenStack

这个 Kubernetes 集群有 4 个节点,1 个 master 节点,3 个 worker 节点:

nodes

4 个节点都是底层 OpenStack 环境提供的虚机:

vm 实例

在 openstack 中部署 Kubernetes 的方案很多,在尝试了其中的一些(包括 magnum)之后,最终使用基于 Ansible 的 Kubespray 部署。为了简化操作,这套 Kubernetes 集群也并没有对接底层的 OpenStack。

手动创建了虚机之后,完成这样一套集群大概需要 20 分钟:

kubespray playbook

这里最初的 node-4 不幸被折腾挂了,所以上面显示的是后面新增的 node-5

最下层:基于 Kolla 的 OpenStack

最底层的 openstack 是搭建在一台物理服务器上的 All-In-One 环境,使用 Kolla 作为部署工具。

Kolla 使用容器来部署 OpenStack,所以可以通过 docker ps 查看服务:

openstack in docker

总结和思考

OpenStack 和 Kubernetes 的关系

红蓝组CP

一直以来 OpenStack 作为 IaaS 层,用来管理底层计算资源,而 Kubernetes 则被视作 PaaS 层,来管理应用和容器。在通常的架构图中,OpenStack 都是处在 Kubernetes 的下层,作为云计算平台提供诸如持久卷、负载均衡等资源。

事实上,OpenStack 系统本身就是一个微服务的架构,使用容器化部署,进而使用 Kubernetes 来管理已经是大势所趋。通过 Kubernetes 强大的容器编排能力,长久以来被诟病的 OpenStack 的部署难,升级难等问题可以得到有效解决。 在这次测试中,当中途遇到错误时,处理方式非常「简单粗暴」,直接删掉重来。管理面要求高可用?直接改 replicas 就行。Kubernetes 和 Helm 的强大功能令人印象深刻。

同时现在可以无缝引入云原生社区强大生态,例如 Prometheus,ELK 等,想用的话基本就是一键部署和接入。

由于 Kubernetes 基于云的设计,在私有云场景下,OpenStack 仍然是 Cloud Provider 的不二选择。不仅可以提供可用于部署集群的 Node 实例(虚机或裸金属),也能补充底层网络/存储资源的管理能力。

关于实际应用的思考

因为环境所限,这里最上层 OpenStack 已经是二次虚拟化了,显然没有实用价值,实际应用中需要有所变化。

我能想到的可行方案:

  • 以虚拟机为主要工作负载的,容器作为补充的,可以考虑保留下面两层,通过 OpenStack 提供基于虚机的 Kubernetes 集群和容器服务。

  • 以容器为主要工作负载的,可以考虑仅使用上面两层,在裸机上部署 Kubernetes。这样部署在上层的 OpenStack 就是一个用来供给虚机的服务,本质和部署一个网站没啥区别。

  • 结合我们前面介绍的裸金属技术,保留所有三层,底层的 OpenStack 只负责提供裸金属实例,这样上面两层的作用和上一个方案类似。

当然,显而易见的,这样一套架构最大的问题就是太过于复杂。同时引入两套技术栈,对团队的要求较高。如果非要二选一,大多数的小公司会作何选择不言而喻。

你对 Kubernetes 和 OpenStack 之间关系有何想法,欢迎在评论区讨论。

感谢你的阅读,请继续关注「云计算实验室」

本文使用 mdnice 排版

Redmi最便宜智能电视A32明天首销:仅售799元

上一篇

《我想进大厂》之MQ夺命连环11问

下一篇

你也可能喜欢

在 Kubernetes 上部署 OpenStack 是什么体验

长按储存图像,分享给朋友