使用 KubeKey 搭建 Kubernetes/KubeSphere 环境的“心路(累)历程“

今天要干嘛？

今天我要给 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？望而却步啊！

解决依赖问题再继续干！

回到文档，其实仔细看可以在