现在容器大火，OpenStack走下坡路, Magnum 作为OpenStack中的容器相关项目最多也就算是不温不火吧。但实际上，很多客户的应用仍然是传统的Web应用，尤其在新西兰市场，很多客户也只是刚刚把应用从物理机迁移到我们的云上，实际使用上也仅仅是租个虚机，然后就不折腾了。离真正的原生云应用，或者容器化都有不短的距离。
架构
本来想先介绍架构，但其实Magnum的架构其实很简单，倒是涉及到容器和虚机网络的网络架构比较复杂。我后面会补一张图来解释网络架构．Magnum的架构简单来说就是通过Heat去安装指定的COE. 周边涉及的网络和存储也都是通过Heat来创建的。
上图引自 Magnum wiki(https://wiki.openstack.org/wiki/Magnum)
基本操作
通常来说，从头创建一个 COE cluster 需要以下步骤：
１. 创建 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 的经验。
- 访问 API/Dashboard
在 Magnum 中访问 k8s API 分两种方式，一种是从虚机内部访问，一种是本机远程访问。从虚机内部访问，没有任何限制，可以直接运行 kubectl 的各种命令。如果是从本机远程访问，则需要先运行eval $(magnum cluster-config <cluster-name>) 获取证书，然后就可以正常运行 kubectl 的各种命令了。
- 确认 k8s API 功能正常
kubectl get pods --all-namespaces
- 确认个 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 -
创建一个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 -
通过 Magnum 按照的k8s 默认会安装 CoreDNS, 运行下面的代码可以验证 DNS 是否正常
kubectl exec busybox nslookup kubernetes
未完待续...