关于kubernetes:使用-KubeKey-搭建-KubernetesKubeSphere-环境的心路累历程

明天要干嘛？

明天我要给 KubeKey 挑个刺！

身为一个 KubeSphere Community Member，至今为止我竟然没有用过 KubeKey，是不是很过分？说进去都感觉没脸在 KubeSphere 社区立足啊！

想当年开始玩 KubeSphere 时，每走一步我都感觉“不谐和”。虽说 KubeSphere 早曾经有了足够的知名度和大量的企业用户，然而我总能挑出“刺”，天天给 KubeSphere 社区提意见建议……

没错，最终他们“受不了”了，决定邀请我退出 KubeSphere 社区，成为一名光彩的 Member！

当初我本人也搞开源社区了。自从开始治理 DevStream 开源社区后，我根本就没有精力参加 KubeSphere 社区了。哎，一颗躁动的心，一双不安分的手！我得做点啥，然而开发我是没精力参加了，要不，施展一下我的“臭故障”– 早期的强迫症和极致的细节洞察力，去挑挑刺吧！

没错！

我决定试用一下 KubeKey！一方面把这些“刺”反馈给 KubeSphere 社区，帮忙他们进一步欠缺 KubeKey 的应用体验！另外一方面在这个过程中相熟 KubeKey 的用法，看下能不能找到 DevStream 和 KubeSphere 合作的点，比方用 DevStream 简化 KubeSphere 的装置部署和配置过程。

在哪里干？

KubeSphere 社区给了我一个开发机，一台 Linux vm，酷！我就在这个 Linux vm 上“干”它吧！

从哪里开始干？

这还不简略，README 文档呀！

疾速开干！

咱们在文档里找 Quick Start，没错，有，大抵长这样：

{{<

开炮！

看到这个日志，是不是看着特地像“no errors, no warnings”，一派祥和，歌舞升平，马上能够用 kubectl 命令看下簇新的 Kubernetes 集群了！（不要和我杠单节点 k8s 环境是不是集群，官网称之为“单节点集群”）

我就不演示 kubectl get xxx 了，后果惨不忍睹！咱们认真看这个输入日志，对，细品，有没有发现这里用了几行 非 error 级别的日志通知咱们须要先装置：

• conntrack
• socat

给 KubeKey 的倡议 1：这里是不是用 error level logs 更正当一些？

给 KubeKey 的倡议 2：能不能日志里间接通知用户须要先装置 conntrack 和 socat，并且同时打印出装置命令？（我晓得 centos 和 ubuntu 装置形式不一样，不过可选的命令汇合其实很无限，kk 获取零碎类型也很容易，给用户更敌对的提醒其实很容易做到）

给 KubeKey 的倡议 3：表格里那么多项没有 y 的，到底哪些是必须有的哪些是不必须的？这个后果让用户看得心慌：我须要先装置那么多货色能力开始用 kk？望而生畏啊！

解决依赖问题再持续干！

回到文档，其实认真看能够在这里发现前置依赖，就是这段文字太长了，让人有点没急躁认真看完。

还是 Google 大法好用！咱们照着这个思路执行上面命令：

yum -y install conntrack-tools
yum -y install socat

不出意外的话这一步很难失败。对，如果你失败了，那就是意外。真的失败了，那就是 yum 配置问题了，明确怎么解决吧？

而后继续执行 ./kk create cluster，看下能不能失去谐和的输入。（记得如果环境不够“迷信”，要先执行export KKZONE=cn，否则你会在某一步卡半天，卡到狐疑人生，无奈判断是网络太慢还是网络不通）

给 KubeKey 的倡议 4：当命令卡住的时候，比方镜像下载太慢时，有没有超时逻辑？或者能不能定时输入一个日志通知用户“没有卡死”？或者显示一下下载的进度条？总之不要长时间没有日志，用户会忍不住去 Ctrl+c，而后一脸迷茫，下一步干啥？

比方才谐和了，不过第一行日志很不谐和。

如果 Failed 影响大，比方会让某个性能不可用，那么应该用 error 级别，这样我会尝试去修复；反之 WARN 级别的意思就是“你能够疏忽，疏忽也能用”。OK，我抉择疏忽。（我不肯定真的疏忽，然而很多用户必定会这样想。）

给 KubeKey 的倡议 5：尽量避免 WARN 日志，尤其是 WARN 配合 Failed 一起用，让用户又感觉这个谬误很重大，又感觉能够疏忽。

接着就看网络环境了。

顺利的话，最初能够看到这样的日志：

Installation is complete.

Please check the result using the command:

    kubectl get pod -A

让咱们执行 kubectl get pod -A，看下“豌豆荚”们是不是失常：

$ kubectl get pod -A
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-75ddb95444-6dg9b   1/1     Running   0          30m
kube-system   calico-node-rqqrk                          1/1     Running   0          30m
kube-system   coredns-5495dd7c88-9hlrp                   1/1     Running   0          30m
kube-system   coredns-5495dd7c88-nlp5d                   1/1     Running   0          30m
kube-system   kube-apiserver-i-hmqwjh0m                  1/1     Running   0          30m
kube-system   kube-controller-manager-i-hmqwjh0m         1/1     Running   0          30m
kube-system   kube-proxy-x69p9                           1/1     Running   0          30m
kube-system   kube-scheduler-i-hmqwjh0m                  1/1     Running   0          30m
kube-system   nodelocaldns-vd77n                         1/1     Running   0          30m

我勒个乖乖，Amazing 啊！清一色的 Running、1/1 且 0 restarts，堪称完满！

如何干翻重来？

装好了，而后呢？

干翻重来吧，因为间接执行 ./kk create cluster 并不带 KubeSphere。咱们体验过 k8s 的装置过程了，整体还是挺简略易用的。下面试下带 KubeSphere 的玩法吧。

干翻操作：

./kk delete cluster

执行完这个命令后，k8s 集群会被删掉。当然，对应的 kubectl 和 docker images 我不心愿被删掉，事实证明 KubeKey 也不会把它们删掉。对，我验证了：

连着 KubeSphere 一起干！

命令是如此的简略，只须要加一个 flag 就够了：

./kk create config --with-kubesphere

干不过，输了。

后果不漂亮啊：

{{<

我。。。

你。。。

你给我一个 WARN 后就间接挂了？

给 KubeKey 的倡议 6：WARN 日志后面提到了，这里再次印证我的观点，日志级别要谨严，WARN 要少用。

这个谬误，，，看起来是要 Google 一会了。然而我懒啊！这不就是和 docker 装置形式无关嘛（我猜可能和版本也有关系），我卸掉 docker，让 KubeKey 来装置总行了吧！

给 KubeKey 的倡议 7：如果你们晓得这个谬误的解决方案，请把办法（或者参考资料链接）贴到日志里，不要期待用户能够轻松 Google 一下解决。当然，我不能承受你说我解决不了，哈哈，不过当初是早晨 10:30 分，我想快点打完出工了，不查了。

其实这个机子原本没有 docker，为什么我会提前装置呢？因为我勤奋？不存在的。我是被这段内容误导的：

看这个缩进级别，你瞟一眼，是不是最显眼的是上面的 Note？Note 里说先装置 docker，而后如果你很相熟 docker，是不是就棘手先装了 docker 在持续看文档？

对，我就跪在了这里。装了 docker 才发现，这个 Note 是针对 Build Binary from Source Code 的 Note。。。

给 KubeKey 的倡议 8：这里的文档也优化下吧，让 Note 看起来不那么像全局 Note。

另起炉灶，持续干！

上来就是一套组合拳：

yum remove docker
./kk create cluster --with-kubesphere

不出我所料，谬误绕过去了！

对，我就是这么心安理得，能够忍住不去查后面这个谬误是怎么回事，我抉择绕过后早晨还是能够睡得香喷喷！我置信 KubeSphere 社区过几天会通知我答案的。

截图看不到成果，大家脑补一下下面这个箭头会左右挪动，对，动静的！太可恶了吧！今天我要去问下谁写的这个代码，真是个可恶的程序员！

在等这个箭头停下来的工夫里，再给 KubeKey 加一个倡议吧：

给 KubeKey 的倡议 9：这里的文档也优化下吧，格调统一更优雅，要么都写一个“示例”版本，要么都用 [version] 占位。

给 KubeKey 的倡议 10：y 和 yes 在用户用意里相对是截然不同，要不要兼容下？包含大小写（我没有测试大小写是不是兼容）

给 KubeKey 的倡议 11：如果一次装置长时间卡住，可能是网络问题。这时候如果 Ctrl+c 而后从新执行装置，会呈现这种状况，没错，两个 ks-installer。当然，我晓得须要先 delete 一下就能绕过去，然而或者 kk 可能辨认到用户没有 delete 并且给出提醒，那就更“优雅”了。

再次另起炉灶，持续干！

因为我用的云主机，后面装置过程太久，我去洗了个澡，回来后终端断开连接了。没错，再次进去的时候我遗记执行 export KKZONE=cn 了，所以失败了一次。再次执行的时候遗记 delete 了，所以再失败了一次。

于是，我要 delete 了：

惨不忍睹，惨无人道啊！！！

你给我装的 docker 呀，怎么还能有这个谬误？

同样，你通知我 WARN，我是不会上心的。

忽视

and

持续！

好玩的事件是，这次看着错误信息仿佛，，，和后面没啥区别呀。。。然而没有间接退出程序，而是持续往下走了！好吧，我是不会去钻研这个谬误的！

又到了这个“可恶到爆”的箭头了，持续漫长的期待吧～

不对劲啊，为什么那么久，是不是挂了？

好吧，唤醒一下我沉睡多年（精确说是大半年）的 k8s 排错技能！

我看到了 ks-installer pod 的谬误 events 信息：

有意思，这是个大 bug 了吧，镜像不存在？我得去问一下内部人员：

给 KubeKey 的倡议 11：对着文档走不通装置过程，这算大 bug 了，不必我细说怎么 fix 了吧。

一鼓作气，再而衰，三而竭，竭前最初挣扎着干一次

没力量打“组合拳”了，一条简略的命令，而后小拳拳敲个回车：

./kk create cluster --with-kubesphere v3.2.1

好家伙，一把给我整到了早晨 11 点。。。我不要体面的啊，我在家办公还要加班啊，我是朝十晚四午休三小时的男人啊……

不过说实话，看到这个相熟的日志，还是很亲切的！毕竟去年不晓得看了多少遍这个日志！（别不信，我是深度玩过的，有视频为证）

持续看下 pod

很谐和！Amazing 啊！

（其实没有特地谐和，restarts 不是全 0。不过没关系，我晓得这不影响性能，只是装置过程还有优化的空间而已。）

你想看最初的 Dashboard？我也想！

不过我没有 ELB，着急期待中……（委托大佬给我配置 ELB 去了）

半小时后……

登录页面来了！

进去后，相熟的感觉，相熟的滋味！

前面我肯定要再写几篇文章介绍下 KubeSphere 怎么玩！当年那一堆笔记，那些付在 KubeSphere 上的青春，不写点啥惋惜了！

最初的总结

1. 官网文档比 GitHub 的 README 更适宜“普通用户”；
2. 好困啊！！！我要睡觉了，总结啥嘛，没啥好总结的。

最初的最初

转载请注明出处！

更多我的文章，请移步我的集体网站：https://www.danielhu.cn

更多 DevStream 团队的文章，请移步 DevStream 博客网站：https://blog.devstream.io

想要及时收到我的最新文章，请关注我的集体公众号：胡说云原生