首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

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

2020-05-22

面向边际的轻量级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,也的确无法获取注册的节点信息:

客户的虚拟机环境运用某私有云,从反应看有过VM重复整理的操作,不过具体操作无法完好恢复。

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信息是否合法,这时node-passwd就粉墨登场了。

这个进程大致是这样的,agent先生成一个随机passwd,并把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和server上的node-paswd:

$ cat /etc/rancher/node/password

47211f28f469622cccf893071dbda698

$ hostname

xxxxxxx

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文件,那么问题很可能是VM重建或许手动操作删去的这个文件。由于agent上删去了password,agent再次注册时会从头生成password,就导致了新的password和server上原先存储的不一致。

处理办法能够有三种:

原则上不主张用户去触碰文中说到的这些文件,尽量把控制权交给k3s,即便咱们整理agent节点,也尽量使用k3s内置的脚本。假如碰到此类问题,能够参阅本文的原理介绍去剖析,并经过已知的处理方案去修正它。

热门文章

随机推荐

推荐文章