k3s原理分析丨如何搞定k3s node注册失败问题

前 言

面向边缘的轻量级K8S发行版k3s于去年2月底发布后，备受关注，在发布后的10个月时间里，Github Star达11,000颗。于去年11月中旬已经GA。但正如你所知，没有一个产品是十全十美的，k3s在客户落地实践的过程当中也暴露过一些不足。在k3s技术团队的专业技术支持下，许多问题获得了改善和解决。

咱们精选了一些在实际生产环境中的问题处理案例，分享给正在使用k3s的你。但愿k3s技术团队的经验可以为你带来参考，也但愿你能够参与进来和咱们一块儿探索切磋。毕竟，寻找答案的路途永远没有终点。

本文将分享k3s产品中关于node注册失败的排查记录。

排查记录

问题描述

k3s版本：v1.17.2+k3s1

k3s agent向server注册时，日志出现明显报错：

同时，在k3s server上查询node，也确实没法获取注册的节点信息（只有一个server节点）：

客户的虚拟机环境使用某私有云，从反馈看有过VM反复清理的操做，不过具体操做没法完整复原。

基本原理

Agent注册的过程是十分复杂的，总的来讲有两个目的：

• 启动kubelet等服务，链接到server节点上的api-server服务，这是k8s集群必须的

• 创建websocket tunnel，用于k3s的server和agent同步一些信息

咱们在注册agent时只提供了server地址和node-token，agent是如何一步一步完成注册的？首先看node-token的格式：

这里的user和password会对应k3s api-server中basic auth的配置，k3s api-server启动时会设置一个特殊的authentication方式就是basic auth，对应文件在server节点的/var/lib/rancher/k3s/server/cred/passwd中：

1a51f67d17af05b6f48357f46a9c6833,server,server,k3s:server
0050004354d29b565f4a8bf2faba769e,admin,admin,system:masters
1a51f67d17af05b6f48357f46a9c6833,node,node,k3s:agent

由此agent端经过解析node-token，能够得到一个和k3s api-server通讯的受权，受权方式是basic auth。

了解node-token的做用，咱们就能够解开agent注册过程的序幕，参考下图：

以黄色文本框顺序为例，前三步是为了获得启动kubelet服务各类依赖信息，最后一步创建websocket通道。咱们能够只关心前面三步，最重要的是api-server的地址，还有各类k8s组件通讯的tls证书，因为那些证书是在server上签发，因此agent须要经过一些API请求获取，这些证书大体有：

/v1-k3s/serving-kubelet.crt
/v1-k3s/client-kubelet.crt
/v1-k3s/client-kube-proxy.crt
/v1-k3s/client-k3s-controller.crt
/v1-k3s/client-ca.crt
/v1-k3s/server-ca.crt
...

这些证书中kubelet两个证书最为特殊，因为kubelet在每一个节点都运行，因此安全须要咱们须要给每一个kubelet node都单独签发证书（node-name做为签发依据）。涉及到单独签发就须要验证node信息是否合法，这时node-passwd就粉墨登场了。

这个过程大体是这样的，agent先生成一个随机passwd（/etc/rancher/node/password），并把node-name和node-passwd信息做为证书请求的request header发给k3s server，因为agent会向server申请两个kubelet证书，因此会收到两个带有此header的请求。若是agent首次注册，server收到第一个请求后，会把这个node-name和node-passwd解析出来存储到/var/lib/rancher/k3s/server/cred/node-passwd中，收到第二个请求后会读取node-passwd文件与header信息校验，信息不一致则会403拒绝请求。若是agent重复注册时，server会直接比对request header内容和本地信息，信息不一致也会403拒绝请求。

缘由分析

了解基本原理后，咱们再回到问题自己，agent在注册时报出的错误日志以下：

level=error msg="Node password rejected, duplicate hostname or contents of '/etc/rancher/node/password' may not match server nod
e-passwd entry, try enabling a unique node name with the --with-node-id flag"

查找代码出处，确实发现这是在申请kubelet证书时，k3s server返回的403致使的：

对比agent上的node-passwd（/etc/rancher/node/password）和server上的node-paswd：

# agent
$ cat /etc/rancher/node/password
47211f28f469622cccf893071dbda698
$ hostname
xxxxxxx

# server
cat /var/lib/rancher/k3s/server/cred/node-passwd
31567be88e5408a31cbd036fc9b37975,ip-172-31-13-54,ip-172-31-13-54,
cf3f4f37042c05c631e07b0c0abc528f,xxxxx,xxxxxx,

Agent node对应的passwd和server中存储的hostname对应的passwd不一致，按照咱们前面说的基本原理，就会出现403的错误日志。

解决方案

为何会出现passwd不一致呢？正常来讲若是用k3s-agent-uninstall.sh来清理安装过的agent node，并不会删除password文件（/etc/rancher/node/password），那么问题极可能是VM重建或者手动操做删除的这个文件。由于agent上删除了password，agent再次注册时会从新生成password，就致使了新的password和server上原先存储的不一致。

解决办法能够有三种：

• 手动在agent上建立password，内容和server中存储保持一致

• 修改了server中的原始内容，让password和agent上新生成的保持一致

• 能够试试agent注册时使用--with-node-id，这样server中认为这彻底是新node，不会用原始信息比对

总 结

原则上不建议用户去触碰文中提到的这些文件，尽可能把控制权交给k3s，即便咱们清理agent节点，也尽可能利用k3s内置的脚本。若是碰到此类问题，能够参考本文的原理介绍去分析，并经过已知的解决方案去修复它。