关于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

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

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据