利用K8S助力OpenStack生产环境部署简要分析

问题:

    openstack与k8s组合一直是个头疼的问题，特别是利用k8s去部署openstack环境。由于openstack是一套iaas，与服务器硬件、系统软件交互较多，本身的部署也要花大量的心思去设计一套方案，拿社区的部署工具，即使是fuel，也无法满足真正的生产需求。如何将openstack服务容器化，利用k8s真正做到快速部署，一直是个难题。

难点解决:

    Q1：如何完成openstack依赖组件（如mysql、rabbitmq）的部署？  A：建议在没有专业团队维护的情况下，还是不要容器化，这些服务内部有自身高可用设计，且为非无状态服务，暴力不可取。

    Q2：如何规划k8s网络插件及node间组网？ A：由于生产环境的openstack也有sdn，网络复杂，最简单的方法，就是不依靠插件，完全使用hostnet的方法。暴露物理机网络给pod，以便服务能够访问管理、业务、存储三个网络。

    Q3：服务负载均衡设计？ A：负载均衡不依赖K8S，还是继续使用HAProxy+KeepAlived的方案。与web pod服务不用，生产环境会详细规划方案，具体服务落到哪些节点都是固定的。另外不用service，减轻网络插件带来的不稳定性。

    Q4：如何同步数据库和创建keystone中的认证信息？ A：这里利用一个restartPolicy为Never的POD（取名为bootstrap），启动后执行脚本完成操作。

    Q5：需要使用的POD的kind类型？ A：api服务使用daemonset，保证落到对应的标签；rpc服务使用deployment，方便伸缩；nova-compute、ironic-conductor这种依赖hostname服务，也应该使用daemonset。

    Q6：服务运行日志怎么办？ A：日志一律挂在主机的/var/log/openstack下，方便查看和ELK分析。

    Q7：openstack配置文件怎么修改？ A：由于同一pod不同node下的容器组件配置文件可能还是不同的，设计了一个config节点，容器启动后利用脚本拉取conf文件模板，并进行修改。

设计:

K8S YAML设计(以具有代表性的cinder为例) ：

cinder-bootstrap.yaml

bootstrap服务用于同步数据库及创建endpoint，需要与管理网通信，label选择只有管理网的core，运行一次即可。

cinder-api.yaml

cinder-api服务需要与管理网通信，label选择有管理网的core，使用DaemonSet。

cinder-volume.yaml

cinder-volume服务与存储网通信，label选择有管理、业务、存储三网的business，使用Deployment。

DockerFile设计(和上述cinder对应)：

cinder-bootstrap/Dockerfile：

cinder-bootstrap.sh即为拉取配置模板，同步数据库，创建keystone信息的脚本，不展示了，点到为止。

cinder-api/Dockerfile：

cinder-api.sh即为拉取配置模板，改修配置文件，执行cinder-api命令的脚本。

生产环境设计：

    这是一个ironic环境的方案（部分线段没有画完）。可以看到，k8s-api周围是部署时所需的网络（电口），生产环境运行是可以去掉的，即整个openstack环境不依赖该k8s节点是否正常。

总结：

设计优势

1. 部署、恢复速度快：准备好非openstack组件外（mysql、rabbitmq、haproxy、keepalived等），使用k8s的pod、deployment、daemonset实现自动化部署和高速回溯。

2. 服务及主机监控：主机信息（cpu、内存、文件系统、网络）使用kubelet的cAdvisor监控，通过web展示；openstack服务使用heapster监控，通过k8s dashboard展示，方便运维。

3. 服务高可用、弹性伸缩、快速扩容：openstack进程服务使用k8s的failover机制（包括容器异常重启及故障迁移），弹性伸缩改进了例如nova-scheduler、cinder-volume这些依赖rpc服务的高可用方式，daemonset负责API节点以及nova-compute、ironic-conductor节点的快速扩容。

4. 可视化容器仓库及滚动升级：使用harbor作为容器提供，提供portal界面；k8s的滚动升级能够在尽可能保证服务的情况下，逐步升级版本。

5. Config配置文件节点：所有配置文件放在同一目录下，使用git控制版本，k8s重建服务即可更新配置。

6. 日志分析：所有openstack日志都放在控制节点的/var/log/openstack下，使用logstash的daemonset，配合es、kibana分析，快速定位问题。

7. CICD：修改配置文件{通过修改config节点配置文件->git commit->k8s重建服务}；版本升级{新版本rpm包更新至源->运维节点生成最新容器镜像、打tag、上传至harbor仓库->k8s滚动升级}；错误回退{k8s能够滚动回退到历史版本}。

缺点

比较适合生产环境，测试环境调试代码比较繁琐。