去年的时候,我曾经写过如何简单搭建 Kubernetes 集群,当时使用的是官方的工具箱:Kubeadm,这个方案对于只是想试试的同学来说,还是过于复杂。这里介绍一款简单的工具:MicroK8s。

官方给这款工具的人设是“无需运维的 Kubernetes ,服务于工作站、物联网。”最大的价值在于可以快速搭建单节点的容器编排系统,用于生产试验。

官方网站里的文档有简单介绍如何安装使用,但是却未曾考虑安装过程存在网络问题的神州大陆的同学们,本文将结合这种情况聊聊。

写在前面

官方在早些时候宣布接下来将会使用 Containerd 替换 docker

The upcoming release of v1.14 Kubernetes will mark the MicroK8s switch to Containerd and enhanced security. As this is a big step forward we would like to give you a heads up and offer you a preview of what is coming. Give it a test drive with:

snap install microk8s –classic –channel=1.13/edge/secure-containerd

You can read more in our blog 117, and the respective pill request 13 Please, let us know 5 how we can make this transition smoother for you. Thanks

社区里已经有用户咨询/吐槽过了,这里考虑减少变化,暂时还是以使用 docker 作为容器封装的 1.13 ,新版本留给下一篇“折腾”吧。

使用 SNAP 安装 MicroK8S

snapcanonical  公司给出的更“高级”的包管理的解决方案,最早应用在 Ubuntu Phone 上。

使用 snap 安装 K8s 确实很简单,就像下面一样,一条命令解决问题:

但是这条命令如果不是在海外主机上执行,应该会遇到安装缓慢的问题。

想要解决这个问题,暂时只能给 snap 添加代理来解决问题,snap 不会读取系统的环境变量,只读取应用的变量文件。

使用下面的命令可以方便的修改 snap 的环境变量,但是默认编辑器是  nano ,非常难用。

这里可以先更新编辑器为我们熟悉的  vim 

交互式终端需要我们手动输入数字,然后按下回车确认选择:

再次执行上面编辑环境变量的命令,添加一段代理配置:

再次执行安装,安装进度起飞:

如果速度没有变化,可以考虑重载 snap 服务。

如果上面的操作一切顺利,你将会看到类似下面的日志:

执行列表命令,可以看到当前 snap 已经安装好的工具:

之前 独立安装 K8s 需要先安装 docker,而使用 snap 安装的话,这一切都是默认就绪的。

获取 Kubernetes 依赖镜像

想要使用 Kubernetes,除了安装 MicroK8s 外,还需要获取它依赖的工具镜像。然而镜像的获取还是需要费点功夫的,首先获取 1.13 版本的 MicroK8s 代码:

然后获取其中声明的容器镜像列表:

因为官方代码的奔放,我们会获得长得奇形怪状的镜像名称:

根据我们要部署的目标服务器的具体需求,替换掉 $ARCH 变量,去掉无意义的镜像名称,整理好的列表如下:

将上面的列表保存为 package-list.txt 在网络通畅的云服务器上使用下面的脚本,可以将 K8s 依赖的工具镜像离线保存:

将镜像转存待部署服务器的方式多种多样,这里提一种最简单的方案:scp

如果顺利你将看到类似下面的日志:

最后在目标服务器使用 docker load 命令导入镜像即可。

接下来可以正式安装 K8s 啦。

正式开始安装 Kubernetes

使用 MicroK8s 配置各种组件很简单,只需要一条命令:

完整的组件列表可以通过 microk8s.enable --help 来查看:

执行 enable 顺利的话,你将看到类似下面的日志:

使用 microk8s.status 检查各个组件的状态:

但是组件就绪,不代表 K8s 已经安装就绪,使用 microk8s.inspect 排查下安装部署结果:

解决方法很简单,使用 ufw 添加几条规则即可:

再次使用 microk8s.inspect 命令检查,会发现 WARNING 已经消失了。

但是 Kubernetes 真的安装就绪了吗?跟随下一小节寻找答案吧。

解决 Kubernetes 不能正常启动

在上面的操作顺利之后完毕后,使用 microk8s.kubectl get pods 查看当前 Kubernetes pods 状态,如果看到 ContainerCreating ,那么说明 Kubernetes 还需要一些额外的“修补工作”。

使用 microk8s.kubectl get pods --all-namespaces 查看详细的状态,不出意外的话,将看到类似下面的日志输出:

首要的问题就是解决掉这个处于 Pending 状态的容器。使用 microk8s.kubectl describe pod 可以快速查看当前这个问题 pod 的详细状态:

参考日志输出,可以发现,之前整理的依赖镜像列表,还存在“漏网之鱼”: MicroK8s 中还包含未写在程序中,从远程配置中获取的镜像。

对于这种情况,我们只能通过给 docker 添加代理来解决问题(或者手动一个一个来)。

编辑 MicroK8s 使用的 docker 环境变量配置文件 vi /var/snap/microk8s/current/args/dockerd-env,在其中添加代理配置,比如:

接着重启 docker :

这一切就绪之后,执行下面的命令,重置 MicroK8s 并再次尝试安装各种组件:

命令之后完毕之后,片刻之后再次执行 microk8s.kubectl get pods 会发现所有的 pod 的状态就都是 Running:

使用 microk8s.kubectl get pods --all-namespaces 继续进行验证:

如果你看到的结果类似上面这样,说明 Kubernetes 是真的就绪了。

快速创建应用

安都安完了,总得试着玩玩看吧,当然,这里不会随大流的展示下管理后台就匆匆搁笔。

使用 kubectl 基于现成的容器创建一个 deployment:

既然用上了最先进的编排系统,不体验下自动扩容岂不是太可惜了:

将服务暴露出来,创建流量转发:

使用 get 命令查看服务状态:

如果一切顺利的话,你将会看到类似下面的日志输出:

可以看到我们刚刚创建的 Service 地址是 10.11.12.234:31354。使用浏览器访问,可以看到应用已经跑起来啦。

刚刚就绪的应用

本着“谁制造谁收拾”的绿色环保理念,除了“无脑”创建外,我们也需要学会如何治理(销毁),使用 delete 命令,先销毁 deployment :

执行完毕后日志输出会是下面一样:

在销毁 service 前,我们需要使用 get 命令先获取所有的 service 的名称:

得到了 service 名称后,依旧是使用 delete 命令,删除不需要的资源:

执行结果如下:

查看 Dashboard

估计还是有同学会想一窥 Dashboard 的状况。

可以通过 microk8s.config 命令,先获得当前服务器监听的 IP 地址:

可以看到,当前监听的服务 IP 地址为 10.11.12.234,使用 proxy 命令,打开流量转发:

接着访问下面的地址,就能看到我们熟悉的 Dashboard 啦:

熟悉的登陆界面

其他

完整安装下来,连着系统一共花费了接近 8G 的储存空间,所以如果你打算持续使用的话,可以提前规划下磁盘空间,比如参考  迁移 Docker 容器储存位置  把未来持续膨胀的 docker 镜像包地址先做个迁移。

最后

这篇文章成文于一个月之前,由于使用的还是 “Docker” 方案,理论来说时效性还是靠谱的,如果你遇到了什么问题,欢迎讨论沟通。

看着草稿箱堆积越来越多的有趣内容,或许应该考虑“合作撰写”的模式了。

—EOF