Magnum 入坑指南之一

Friday 23 June 2017 Magnum, OpenStack, Architecture, Kubernetes

现在容器大火,OpenStack走下坡路, Magnum 作为OpenStack中的容器相关项目最多也就算是不温不火吧。但实际上,很多客户的应用仍然是传统的Web应用,尤其在新西兰市场,很多客户也只是刚刚把应用从物理机迁移到我们的云上,实际使用上也仅仅是租个虚机,然后就不折腾了。离真正的原生云应用,或者容器化都有不短的距离。

架构

本来想先介绍架构,但其实Magnum的架构其实很简单,倒是涉及到容器和虚机网络的网络架构比较复杂。我后面会补一张图来解释网络架构.Magnum的架构简单来说就是通过Heat去安装指定的COE. 周边涉及的网络和存储也都是通过Heat来创建的。

上图引自 Magnum wiki(https://wiki.openstack.org/wiki/Magnum)

基本操作

通常来说,从头创建一个 COE cluster 需要以下步骤:

1. 创建 keypair

openstack keypair create feilong --public-key .ssh/id_rsa.pub


2. 创建需要的镜像

openstack image create fedora-atomic --disk-format qcow2 --container-format bare --property os_distro=fedora-atomic --file ./Fedora-Atomic-26-20170723.0.x86_64.qcow2


创建镜像时注意指定 os_distro 属性,大小写敏感,目前支持的情况如下表所示:

+-------------------+-------------------------+
| COE | os_distro |
+-------------------+-------------------------+
| Kubernetes | fedora-atomic, coreos |
+-------------------+-------------------------+
| Swarm | fedora-atomic |
+-------------------+-------------------------+
| Mesos | ubuntu |
+-------------------+-------------------------+


3. Create cluster template

openstack coe cluster template create --name k8s --image 2a21599f-a42f-4b12-9888-ae0600168f3c --keypair feilong --flavor c1.c1r2 --master-flavor c1.c1r2 --coe kubernetes --external-network public --fixed-network <NETWORK ID>


4. Create cluster

openstack coe cluster create --name k8scluster --cluster-template k8s --node-count 1 --timeout 30 --label kube_tag=v1.9.3


Debug

Magnum的debug 分两部分,一部分是OpenStack层面的debug, 一部分是COE层面的debug。

先说 OpenStack 层面的 debug, 如果是 devstack, 那么目前 devstack里的服务都是通过sytemd管理,那么起停相关服务的命令需要通过:

systemctl restart/start/stop devstack@magnum-api


而查看 log,则需要通过 journalctl

journalctl -u devstack@magnum-api


OpenStack 部分的debug 比较简单,和debug OpenStack其他服务基本一致。Magnum 里遇到问题通常是在虚机里实际部署 COE 时失败,这时就需要 ssh 到虚机里去查看失败的原因.Magnum 中 COE的部署是通过 Heat的 Software Deployment执行的。Heat 会将事先准备好的脚本按顺序拷贝到虚机中,具体存放在 /var/lib/cloud/instances/<instance_id>/scripts 因此debug起来也比较简单,如果在 /var/log/cloud-init-output.log/var/log/cloud-init.log 中看到某个脚本比如 part-008 失败了,那么只需要手工执行 part-008 这个脚本,向里面加入简单的log 即可很容易的分析出失败的原因。

此外,还有一部分脚本是通过 heat-container-agent 来运行的,这部分脚本存放在 /var/lib/heat-config/heat-config-script, 而如果想查看这些脚本执行的log情况,则需要通过 journalctl -u heat-container-agent

至此,假设你已经解决了所有的问题,在OpenStack 能看到COE Cluster 成功创建,状态为 Create Complete。那么基本上意味着 OpenStack部分是正常的。运行 openstack coe cluster list 得到运行结果应该是这样的:

feilong@feilong-ThinkPad-X1-Carbon-2nd:~/devstack$ openstack coe cluster list
+--------------------------------------+------------+---------+------------+--------------+-----------------+
| uuid | name | keypair | node_count | master_count | status |
+--------------------------------------+------------+---------+------------+--------------+-----------------+
| 9147e750-164a-4f4d-83cc-e5bf994b8098 | k8scluster | feilong | 1 | 1 | CREATE_COMPLETE |
+--------------------------------------+------------+---------+------------+--------------+-----------------+
feilong@feilong-ThinkPad-X1-Carbon-2nd:~/devstack$ openstack coe cluster show k8scluster
+---------------------+------------------------------------------------------------+
| Field | Value |
+---------------------+------------------------------------------------------------+
| status | CREATE_COMPLETE |
| cluster_template_id | a6822337-1f5b-4266-8967-ff99d8cdb82c |
| node_addresses | [u'172.24.4.13'] |
| uuid | 9147e750-164a-4f4d-83cc-e5bf994b8098 |
| stack_id | a5aa62ee-fb44-4d76-b225-38811adab0a9 |
| status_reason | Stack CREATE completed successfully |
| created_at | 2018-02-23T02:30:50+00:00 |
| updated_at | 2018-02-23T02:42:59+00:00 |
| coe_version | v1.9.3 |
| labels | {u'kube_tag': u'v1.9.3'} |
| faults | |
| keypair | feilong |
| api_address | https://172.24.4.3:6443 |
| master_addresses | [u'172.24.4.3'] |
| create_timeout | 120 |
| node_count | 1 |
| discovery_url | https://discovery.etcd.io/b1c310361853d748444c2c48a814ce4d |
| master_count | 1 |
| container_version | 1.12.6 |
| name | k8scluster |
| master_flavor_id | ds1G |
| flavor_id | ds1G |
+---------------------+------------------------------------------------------------+


接下来,则需要验证 Kubernetes 自身的功能。这部分其实是最复杂的,当然也可能因为我个人对 k8s 还不够熟悉,而对 OpenStack 本身已经比较熟悉的关系。下面是我总结的在 debug k8s 基本功能时的一些简单的汇总。后面会陆续再单独开篇记录我学习 k8s 的经验。

  1. 访问 API/Dashboard

在 Magnum 中访问 k8s API 分两种方式,一种是从虚机内部访问,一种是本机远程访问。从虚机内部访问,没有任何限制,可以直接运行 kubectl 的各种命令。如果是从本机远程访问,则需要先运行eval $(magnum cluster-config <cluster-name>) 获取证书,然后就可以正常运行 kubectl 的各种命令了。

  1. 确认 k8s API 功能正常
    kubectl get pods --all-namespaces

  2. 确认个 minion/worker 节点状态正常
    [fedora@k8scluster-llrejue2ujzv-master-0 ~]$ kubectl get nodes
    NAME STATUS ROLES AGE VERSION
    k8scluster-llrejue2ujzv-minion-0 Ready <none> 3d v1.9.3

  3. 创建一个pod, 确认能够可以正常分配 IP,可以用下面的 yaml 文件创建一个 pod, 把下面的内容保存为文件 busybox.yaml

    apiVersion: v1
    kind: Pod
    metadata:
    name: busybox
    namespace: default
    spec:
    containers:
    - image: busybox
    command:
    - sleep
    - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
    restartPolicy: Always

    接下来运行 kubectl create -f busybox.yaml 即可成功创建一个 pod

  4. 通过 Magnum 按照的k8s 默认会安装 CoreDNS, 运行下面的代码可以验证 DNS 是否正常

    kubectl exec busybox nslookup kubernetes

    未完待续...