k8s踩坑记 - kubeadm join 之 token 失效

小灰灰 2021-12-01 10:44 266阅读 0赞

尊重原创，转载自：https://blog.csdn.net/YoungAngelGirl/article/details/80031884\#commentBox

## 抛砖引玉 ##

环境  
\* 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 driver` 和 `docker cgroup driver` 一模一样，刚刚，`kubelet` 日志里面不是。。。明明。。。却。。。，淡定，这可能是幻觉，好吧。到底什么是真的，什么是假的，能不能给一个准确的提示信息，既然也不是kubelet的问题，又是最新的版本，也没有资料可查，当下实在没辙了，那就去 [kubernets\#62776][kubernets_62776] 提 `Issues`吧，于是乎，就这样下班了。。。。

![1082769-20180419231940106-1926249618.png][]

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

![1082769-20180419232224358-1769835361.png][]

哎，和昨天预料的结果一眼，好像有点诸葛了吧，嘿嘿，那还是靠自己吧，又想了又想，看了又看，真的是没有一点点防备啊，期间检查了 `kubeadm`、`kubectl`、`kubelet`，也查看来了各种配置；也想过是不是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][kubernets_62776] ，顺便也给`kubernetes` 提了一下建议，希望提示信息能够准确些，他们的一小步，就是我们的一大步啊。。。。。

![1082769-20180419235208628-159670398.png][]

--------------------

# 作者简洁 #

> 作者：小碗汤，一位热爱、认真写作的小伙，目前维护原创公众号：『我的小碗汤』，专注于写golang、docker、kubernetes等知识等提升硬实力的文章，期待你的关注。 转载说明：务必注明来源（注明：来源于公众号：我的小碗汤， 作者：小碗汤）

[1082769-20180419223604899-927162748.png]: /images/20211201/6cb4d981f9ec4b098833145226d6cb86.png
[1082769-20180419223620907-836055526.png]: /images/20211201/7ce6a4eb91bc45569bd48ecc154f0964.png
[1082769-20180419223225108-2009996918.png]: /images/20211201/bbd8bd8cc32b4db998790dc452493b53.png
[1082769-20180419223235203-163097599.png]: /images/20211201/5372bd2df74f48af8ee77106debe3f5c.png
[1082769-20180419223230012-76345352.png]: /images/20211201/ad1356a654b54ffe96affbf74bc67fa7.png
[kubernets_62776]: https://github.com/kubernetes/kubernetes/issues/62776
[1082769-20180419231940106-1926249618.png]: /images/20211201/0b32c0071218405e971bd7b888c7700e.png
[1082769-20180419232224358-1769835361.png]: /images/20211201/12f5ad6905914c85bc716f119eb7566c.png
[1082769-20180419223220321-57253019.png]: /images/20211201/cffde0b9aa6c4db9800435468ad23cf9.png
[1082769-20180420085742511-297952121.png]: /images/20211201/d25eb873a6a647e3be9c5c37562d5630.png
[1082769-20180419235208628-159670398.png]: /images/20211201/bfd252619e5e487bad4748e94e27d143.png