Magnum，想说爱你不容易

2019-12-01 6 分钟阅读时长 OpenStack

OpenStack Magnum 踩坑和吐槽

前言

最近在研究如何在 OpenStack 上搭建 Kubernetes，自然首当其冲地要试试 Magnum。然而一番折腾，最终还是铩羽而归，无功而返。

既然没有成功经验，也只能吐槽吐槽，留作参考。

不好的预兆

开始干活之前首先自然是在网上一通搜索，看看有无成功经验分享。

除了官方主页外，就没有 2 年内的网页。而且没看到成功部署过程的分享，大多数都是一些泛泛介绍。按理说，这时候我就该放弃为妙，但是作为 OpenStack 的几年老兵，就这么不战而退总感觉不甘心。

于是后来看到这篇博文，对比了 Kubernetes 在 OpenStack 上的部署方案。其中给 Magnum 的评价是成熟。既然这样，那就姑且试试吧。

这也得亏 Kolla 部署环境很方便，没费功夫就把 Magnum 服务部署上了。

没有重点的文档

因为没有现成的博客文章可以参考，只能去翻 Magnum 的用户文档。

![magnum 文档](images/magnum 文档.png)

内容比想象的多，但是文章结构却让人无语。没有 step by step 的步骤说明也就罢了，20 几个小节完全平铺开，没有主次分组，其中还夹杂着大量的各种参数选项说明，直接让人看花眼。

尴尬的 COE

![magnum COE](images/magnum COE.png)

Magnum is an OpenStack API service developed by the OpenStack Containers Team making container orchestration engines (COE) such as Docker Swarm, Kubernetes and Apache Mesos available as the first class resources in OpenStack.

所谓 COE，就是容器编排引擎。在前几年确实是一场混战，但是现在 Kubernetes 已经无可争议的赢得了胜利。应该不会再有多少人愿意去投入到 Swarm 或者 Mesos 上了吧。

直接排除掉另外两个，选择 Kubernetes。接下来是选择一个操作系统镜像。

镜像选择

可以看到，支持 Kubernetes 的操作系统只有 2 个，一个是 CoreOS 和 Fedora Atomic。并没有常用的 CentOS 和 Ubuntu 系统。

先是在文档中间很不起眼的地方找到了两个系统镜像的下载链接。

Image (image)
Specified in the ClusterTemplate to indicate the image to boot the servers. The image binary is loaded in Glance with the attribute ‘os_distro = fedora-atomic’. Current supported images are Fedora Atomic (download from Fedora ) and CoreOS (download from CoreOS )

细心的看看这两个镜像链接，一个 URL 里带着 20180419 的时间戳，另一个里则带着 beta 字样。

接下来的操作我已经不抱什么希望，纯粹是为了学习一番了。

CoreOS 踩坑

在容器技术火爆时，经常看到 CoreOS 系统被提及，说它是一个面向容器的 Linux 系统。大名如雷贯耳，却一直没机会接触，就先从它开始吧。

开始就是

 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming
 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch
 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch
 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/osprofiler/profiler.py", line 160, in wrapper
 ERROR oslo_messaging.rpc.server     result = f(*args, **kwargs)
 ERROR oslo_messaging.rpc.server   File "/usr/lib/python2.7/site-packages/Magnum/conductor/handlers/cluster_conductor.py", line 80, in cluster_create
 ERROR oslo_messaging.rpc.server     raise e
 ERROR oslo_messaging.rpc.server InvalidParameterValue: ERROR: The Parameter (octavia_ingress_controller_tag) was not defined in template.

经过查一番代码，查到在 Magnum\drivers\heat\k8s_template_def.py 中，默认会传入参数 ‘octavia_ingress_controller_tag’ ，但是这个参数没有在模板中定义。

模板的位置是 Magnum\drivers\k8s_coreos_v1\templates\kubecluster.yaml，在其中添加了参数定义即可：

  octavia_ingress_controller_tag:
    type: string
    description: Octavia ingress controller docker image tag.
    default: "v1.15.0"

继续，又遭遇 docker_volume_type 参数错误

ERROR Magnum.drivers.heat.driver [req-3481b290-b337-471b-8d39-331beafe8b38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: f367dd40-b240-44d8-aa95-bc93ccf4d529, reason: Resource CREATE
 failed: resources[0]: resources.kube_masters.Property error: resources.docker_volume.properties.volume_type: Error validating value '': The VolumeType () could not be found.

该参数默认没有指定，但是实际 cinder 中也没有定义 volume_type，该参数也不是必选项，所以把它删除

在下面两个文件中，Magnum\drivers\k8s_coreos_v1\templates\kubemaster.yaml 和 Magnum\drivers\k8s_coreos_v1\templates\kubeminion.yaml

  docker_volume:
    type: Magnum::Optional::Cinder::Volume
    properties:
      size: {get_param: docker_volume_size}
      volume_type: {get_param: docker_volume_type}  # <-- 删除此行

连续两个参数错误，抱着再试最后一次的心态，终于第 3 次，参数没再报错，开始了资源创建。一切看上去很顺利，但是最终 kube_master 节点创建超时。

Task create from ResourceGroup "kube_masters" Stack "s3-symp6stjv2g7" [08b5e171-be6f-4519-8541-8396c6660
440] timed out

在一番探索后，判断应该是拉取镜像，安装软件操作超时。但是因为 CoreOS 中的容器引擎并不是大家熟悉的 docker，所以还是只能去找官方文档。

一打开 CoreOS 官网首页就看到被 RedHat 收购的消息，文档页面也在提醒着这一事实。

算了，放弃吧。

Fedora Atomic 踩坑

很多人（包括我自己）都以为 CentOS 是 RedHat 的社区版本，其实 Fedora 才是。但是这里的最大的差别是在 Atomic。这个其实和 CoreOS 一样，代表的是新一代的容器操作系统。

RedHat 收购 CoreOS 后，这两个系统要合并，最终的结果是怎样，还有待观望。

到这里可以看出，Magnum 部署 Kubernetes 所依赖的两个操作系统都有大变化，基础不稳，现有的方案显然不适合再采用了，下面只是为了继续学习。

总的来说，使用 Fedora Atomic 的过程相对比较顺利，虽然也遇到一些错误，但是都能解决。经过一番坎坷，集群已经貌似可用：

[fedora@f-dl52xs5blzid-master-0 ~]$ kubectl get nodes
NAME                      STATUS    ROLES     AGE       VERSION
f-dl52xs5blzid-master-0   Ready     master    9d       v1.11.6
f-dl52xs5blzid-minion-0   Ready     <none>    9d       v1.11.6

然而悲催的是，部署任务的最终状态仍然是失败

为了这最后一步，着实费了一番折腾，然而最终还是没有搞定。😂

问题的关键出在 Heat 上。

Heat 部署软件

大家都知道 Heat 是 OpenStack 原生的编排引擎。用来编排一个环境，批量创建资源确实很方便。

但是一套业务环境光创建虚机、网络、存储这些资源还不够，还需要给虚机安装部署完软件才算完整。所以，Heat 也提供了软件部署相关的资源选项。

OS::Heat::SoftwareComponent
OS::Heat::SoftwareConfig
OS::Heat::SoftwareDeployment
OS::Heat::SoftwareDeploymentGroup

以前一直只是耳闻，没有实际操作过。在网上搜了半天，也没找到很多分享。这回借着机会深扒了一下，给我的感觉就是，这玩意没人用是应该的！

首先要在制作镜像的时候就埋伏好内应，也就是一些钩子脚本，例如下面的 os-collect-config， os-refresh-config， os-apply-config。

# Clone the required repositories. Some of these are also available
# via pypi or as distro packages.
git clone https://opendev.org/openstack/tripleo-image-elements
git clone https://opendev.org/openstack/heat-agents

# Install diskimage-builder from source
sudo pip install git+https://opendev.org/openstack/diskimage-builder

# Required by diskimage-builder to discover element collections
export ELEMENTS_PATH=tripleo-image-elements/elements:heat-agents/

# The base operating system element(s) provided by the diskimage-builder
# elements collection. Other values which may work include:
# centos7, debian, opensuse, rhel, rhel7, or ubuntu
export BASE_ELEMENTS="fedora selinux-permissive"
# Install and configure the os-collect-config agent to poll the metadata
# server (heat service or zaqar message queue and so on) for configuration
# changes to execute
export AGENT_ELEMENTS="os-collect-config os-refresh-config os-apply-config"


# heat-config installs an os-refresh-config script which will invoke the
# appropriate hook to perform configuration. The element heat-config-script
# installs a hook to perform configuration with shell scripts
export DEPLOYMENT_BASE_ELEMENTS="heat-config heat-config-script"

# Install a hook for any other chosen configuration tool(s).
# Elements which install hooks include:
# heat-config-cfn-init, heat-config-puppet, or heat-config-salt
export DEPLOYMENT_TOOL=""

# The name of the qcow2 image to create, and the name of the image
# uploaded to the OpenStack image registry.
export IMAGE_NAME=fedora-software-config

# Create the image
disk-image-create vm $BASE_ELEMENTS $AGENT_ELEMENTS \
     $DEPLOYMENT_BASE_ELEMENTS $DEPLOYMENT_TOOL -o $IMAGE_NAME.qcow2

# Upload the image, assuming valid credentials are already sourced
openstack image create --disk-format qcow2 --container-format bare \
    $IMAGE_NAME < $IMAGE_NAME.qcow2

这些脚本还不是统一维护的，可以看到分散到 heat-agents， tripleo-image-elements 几个代码仓库。

要理解它们做了什么，还得理解 diskimage-builder 的作用和其中所谓 elements 的原理。然后 heat-config， heat-config-script 它们又都做了什么。

这些都是钩子而已，还得继续了解真正的部署脚本是怎么在 Heat 模板中定义并传递进去的。

![What the F**](images/PSZwj0HO_99MC 600×461.png)

本来还打算把 murano 也附带着搞搞的，现在看还是不要了。

结语

首先还是要感谢社区的工作，包括所有的代码和文档。只能说容器编排技术这两年发展和更新的速度太快，原来的架构和实现跟不上变化。

通过这次踩坑，算是彻底放弃使用 Magnum 在 OpenStack 上部署 Kubernetes 了。不过也不是完全没有收获。

在使用 diskimage-builder 的时候发现这个工具在制作镜像方面还是很好用的，有一点 Dockerfile 的感觉。通过在制作镜像阶段把相关软件包安装好，对于国内很多企业里比较糟糕的网络环境，也是非常方便的。

后面有机会我再单独介绍这个工具，并且用它构建内置了 Kubernetes 和 kubeadm 的镜像。

如果本文对你有帮助，请点赞、分享、关注，谢谢！。

OpenStack Kubernetes Magnum