抛砖引玉

环境

  • centos 7 amd64 两台
  • kubernetes 1.10

伴随着k8s1.10版本的发布,前天先在一台机器上搭建了k8s单机版集群,即既是master,也是node,按照经验,将 kubeadm init 提示的 kubeadm join 记录下来,方便未来新增集群集工作节点(机器)时,可以直接复用,紧接着就部署dashboard、heapster、ElasticSearch、Redis、dotnet 微服务等等,一气呵成,集群状态良好,因为之前测试环境搞过k8s,呵呵 ...... 。过了两天公司购买的第二胎服务器到了,那么就顺其自然的在上面执行之前记录的 kubeadm join 脚本,结果如下:

1082769-20180419223604899-927162748.png
看到这个提示信息,我完全100%地相信,node 已经加入集群,并且只要等一会儿,通过 kubectl get nodes 就可以看到 node is ready,嘿嘿
过一会儿,又过一会,再过一会儿 ...... ,可是
1082769-20180419223620907-836055526.png

西天取经,历经九九八十一难

然后,开启重试模式,发扬程序员不掘不挠的传统精神:

  1. kubectl reset
  2. kubectl join ......
  3. kubectl get nodes

进入重试死循环N次,耐性真好,哈哈。明明提示 This node has joined the cluster ,为什么实际情况是这样呢,难道这就是理想和现实的差距,其实这就是 ,out了吧。我想了又想,看了又看,没有一点点错误、警告之类的信息,无从下手啊,肿么办呢,最后还是把关注点放在了kubelet(谁叫你是 node agent,肯定拿你开刀啊,呵呵)上,于是开始查看kuberlet的日志:

1082769-20180419223225108-2009996918.png

看到了吧

error: failed to run Kubelet: failed to create kubelet:
misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
原来这个小问题啊,哎。。。。。。,我又再一次相信了这个k8s的提示信息,然后开始修正bug了

1082769-20180419223235203-163097599.png

1082769-20180419223230012-76345352.png

信了你的邪哦,为什么 kubelet cgroup driverdocker cgroup driver 一模一样,刚刚,kubelet 日志里面不是。。。明明。。。却。。。,淡定,这可能是幻觉,好吧。到底什么是真的,什么是假的,能不能给一个准确的提示信息,既然也不是kubelet的问题,又是最新的版本,也没有资料可查,当下实在没辙了,那就去 kubernets#62776Issues吧,于是乎,就这样下班了。。。。

1082769-20180419231940106-1926249618.png

第二天,第一件事情就是查看昨天提的问题是否有人回答了,结果看到被一个印度阿三给关闭了

1082769-20180419232224358-1769835361.png

哎,和昨天预料的结果一眼,好像有点诸葛了吧,嘿嘿,那还是靠自己吧,又想了又想,看了又看,真的是没有一点点防备啊,期间检查了 kubeadmkubectlkubelet,也查看来了各种配置;也想过是不是master提前安装的一些东西影响了,因为以前都是 kubeadm init 后,然后就马上 ·kubeadm join;还想过是不是环境的问题,因为之前的测试环境一直是Ubuntu 16.4,现在的主机环境是 CentOS 7。本想着今天上午,搞不定,就按照测试环境的步骤,重来来过,然后,还是不肯放弃(天生就是当程序员的料子啊,就是头有点冷,呵呵),于是从另外的角度去思考,怀疑是不是记录的 'kube join token=.... ',有问题啊(之前为什么没怀疑,是因为我是直接复制 kubeadm init 打印出来的原生脚本,而且测试环境一点问题都没有。),于是开始顺藤摸瓜,排查第一个参数 token,执行命令 kubeadm token list

1082769-20180419223220321-57253019.png

修成正果,立地成佛

真是抛开云雾见天明,不容易啊,众里寻她千百度,原来她在灯火阑珊处。。。。。哎,不去搞文学,可惜了,呵呵。
于是乎,通过 kubeadm create token 重新创建了一个 token,然后,重新执行 kubeadm join,再次查看 kubectl get nodes

1082769-20180420085742511-297952121.png

成功了,终于成功了,这是搞 kubernetes 以来,踩的最迷糊的一次坑,最后自己回答了自己的 kubernets#62776 ,顺便也给kubernetes 提了一下建议,希望提示信息能够准确些,他们的一小步,就是我们的一大步啊。。。。。

1082769-20180419235208628-159670398.png

普惠

默认情况下,通过 kubeadm create token 创建的 token ,过期时间是24小时,这就是为什么过了一天无法再次使用之前记录的 kube join 原生脚本的原因,也可以运行 kubeadm token create --ttl 0生成一个永不过期的 token,详情请参考:kubeadm-token,了解了原因才能够举一反三,带着思考学习k8s,才不会觉得乏味,希望把这个分享给大家,更希望把整个思考过程分享给大家,往往结果很简单,过程确如同西天取经,只要是程序员,都有同感吧。如果有什么疑问,或者想要交流的东西欢迎评论区留言,楼主会一一回复的哦。

如果你觉得本篇文章对您有帮助的话,感谢您的【推荐】,这将成为我继续写作的动力

如果你对 kubernets 和 dotnet 感兴趣的话可以关注我,我会定期的在博客分享我的学习心得

转载于:https://www.cnblogs.com/justmine/p/8886675.html

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐