导入K8s集群,cluster-agent报错:panic: runtime error: slice bounds out of range [:3] with capacity 0

我有个k8s集群,是以导入的形式添加进的rancher,之前rancher是2.4.8,现在是升级到了2.5.11。 升级完以后cattle-cluster-agent无限重启,升级rancher前,在rancher上是可用的

  • Docker version: 19.03.12
  • kubernetes version: 1.18.14
  • 操作系统: CentOS Linux release 7.9.2009 (Core)
  • 内核版本:3.10.0-1160.15.2.el7.x86_64
  • rancher版本:2.5.11

/uploads/question/20211227/5c4927d537ed50d024151f2828170435.png
/uploads/question/20211227/9717e2ed819c5bbae1b24488f1e3d012.png
/uploads/question/20211227/ab9496425263d750e577ccc70b05f2ea.png

troubleshooting:
我尝试过使用kubectl delete -f 把rancher的相关配置信息给删除,并重新导入进rancher,还是出现一样的报错
/uploads/question/20211227/35e78382d1c29deb3e9f4231c0d50019.png

已邀请:

怀疑cluster-agent所在下游集群中,存在一些helm2 release的脏数据。一般helm2 release以confimap或者secret方式保存。


可以先确认一下保存在哪里,分别探测一下:


kubectl get cm -A -l OWNER=TILLER
kubectl get secret -A -l OWNER=TILLER

如果,发现保存在configmap中,可以用以下脚本探测一下脏数据来自于哪一条:


#!/bin/bash

helm2_releases=$(kubectl get configmaps -A -l OWNER=TILLER -o=jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{"\n"}{end}')

for release in $helm2_releases; do
ns=$(echo $release | cut -f1 -d,)
name=$(echo $release | cut -f2 -d,)
kubectl get cm -n $ns $name -o jsonpath='{.data.release}' | base64 -d | gunzip > /dev/null
if [[ $? != "0" ]]; then
echo "Got a dirty data: $ns--$name"
fi
done

这个脚本是只读的,绝对安全。

没有存在OWNER=TILLER 这个label的secret


使用脚本获取OWNER=TILLER label的cm出现报错
/uploads/answer/20211227/218f210dfb13e888fcf437b5375b68b7.png

kubectl get cm -n $ns $name -o jsonpath='{.data}' | jq '.release' | sed -e "s/^\"//" -e "s/\"//" | base64 -d | gunzip > /dev/null这一步有问题
/uploads/answer/20211227/54be496fe4d806507210066316e5c6b5.png

/uploads/answer/20211227/ce5de72b3ccd1c4fd866041038425ee0.png

我调整脚本重新尝试后,只有一个cm报错了,但是 通过我查看这个cm的data部分内容发现,它是没有被base64编码的。所以我理解来看这个报错应该是正常的。 似乎不是这个cm的问题
/uploads/answer/20211227/d41ad8fd677f382e4389675c709731bd.png
/uploads/answer/20211227/6bc1435efd5d5a51bc213e4d8766beef.png
/uploads/answer/20211227/1e984c17bdd9392baf075728ff75ba36.png

就是这个cm的问题,因为cluster-agent程序里面执行的逻辑是:


base64 decode;
根据步骤1的数据,判断是否gzip;
如果gzip,则解压;
如果没有gzip,则不解压;

如果这个cm内容没有被base64,那在第一步decode是返回的是空的slice。基于空的slice判断数据是否有gzip header,就出现了panic。


我已经向社区提交了Draft PR来修复这个问题:https://github.com/rancher/rancher/pull/35972


在修复之前,你可以临时干掉这个有问题的configmap。

要回复问题请先登录注册