跳转到文档内容
版本:v1.9

故障定位

我在安装 Karmada 时无法访问一些资源

  • 从K8s镜像仓库(registry.k8s.io)拉取镜像。

    你可以运行以下命令来改变中国大陆的镜像仓库。

    sed -i'' -e "s#registry.k8s.io#registry.aliyuncs.com/google_containers#g" artifacts/deploy/karmada-etcd.yaml
    sed -i'' -e "s#registry.k8s.io#registry.aliyuncs.com/google_containers#g" artifacts/deploy/karmada-apiserver.yaml
    sed -i'' -e "s#registry.k8s.io#registry.aliyuncs.com/google_containers#g" artifacts/deploy/kube-controller-manager.yaml
  • 在中国大陆下载 Golang 软件包,并在安装前运行以下命令。

    export GOPROXY=https://goproxy.cn

成员集群健康检查不工作

如果你的环境与下面类似。

用推送模式将成员集群注册到 karmada 后,使用 kubectl get cluster,发现集群状态已经就绪。 然后,通过打开成员集群和 karmada 之间的防火墙,等待了很长时间后,集群状态也是就绪,没有变为失败。

问题的原因是,防火墙没有关闭成员集群和 karmada 之间已经存在的 TCP 连接。

  • 登录到成员集群 apiserver 所在的节点上
  • 使用tcpkill命令来关闭 TCP 连接。
# ens192 是成员集群用来与 karmada 通信的网卡的名字 
tcpkill -9 -i ens192 src host ${KARMADA_APISERVER_IP} and dst port ${MEMBER_CLUTER_APISERVER_IP}。

x509:使用karmadactl init时报certificate signed by unknown authority

使用karmadactl init命令安装Karmada时,在init安装日志中发现以下报错信息:

deploy.go:55] Post "https://192.168.24.211:32443/api/v1/namespaces": x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "karmada")

问题原因:之前在集群上安装过Karmada,karmada-etcd使用hostpath方式挂载本地存储,卸载时数据有残留,需要清理默认路径/var/lib/karmada-etcd下的文件。如果使用了karmadactl --etcd-data参数,请删除相应的目录。

相关Issue:#1467#2504

karmada-webhook因为"too many open files"错误一直崩溃

当使用hack/local-up-karmada安装Karmada时, karmada-webhook一直崩溃,查看组件的日志时发现以下错误日志:

I1121 06:33:46.144605       1 webhook.go:83] karmada-webhook version: version.Info{GitVersion:"v1.3.0-425-gf7cac365", GitCommit:"f7cac365d743e5e40493f9ad90352f30123f7f1d", GitTreeState:"dirty", BuildDate:"2022-11-21T06:25:19Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"linux/amd64"}
I1121 06:33:46.167045 1 webhook.go:113] registering webhooks to the webhook server
I1121 06:33:46.169425 1 internal.go:362] "Starting server" path="/metrics" kind="metrics" addr="[::]:8080"
I1121 06:33:46.169569 1 internal.go:362] "Starting server" kind="health probe" addr="[::]:8000"
I1121 06:33:46.169670 1 shared_informer.go:285] caches populated
I1121 06:33:46.169828 1 internal.go:567] "Stopping and waiting for non leader election runnables"
I1121 06:33:46.169848 1 internal.go:571] "Stopping and waiting for leader election runnables"
I1121 06:33:46.169856 1 internal.go:577] "Stopping and waiting for caches"
I1121 06:33:46.169883 1 internal.go:581] "Stopping and waiting for webhooks"
I1121 06:33:46.169899 1 internal.go:585] "Wait completed, proceeding to shutdown the manager"
E1121 06:33:46.169909 1 webhook.go:132] webhook server exits unexpectedly: too many open files
E1121 06:33:46.169926 1 run.go:74] "command failed" err="too many open files"

这是一个资源耗尽问题。 你可以通过以下命令修复:

sysctl fs.inotify.max_user_watches=16384
sysctl -w fs.inotify.max_user_watches=100000
sysctl -w fs.inotify.max_user_instances=100000

相关Issue:https://github.com/kubernetes-sigs/kind/issues/2928

部署在 Karmada 控制面上的 ServiceAccount 无法生成 token Secret

Kubernetes 社区为了提高 token 使用的安全性和可扩展性,提出了KEP-1205,该提案旨在引入一种新的机制来使用 ServiceAccount token,而不是直接将 ServiceAccount 生成的 Secret 挂载到 Pod 中,具体方式见ServiceAccount automation。这个特性名为BoundServiceAccountTokenVolume,在 Kubernetes 1.22 版本中已经 GA。

随着BoundServiceAccountTokenVolume特性的GA,Kubernetes 社区认为已经没必要为 ServiceAccount 自动生成 token 了,因为这样并不安全,于是又提出了KEP-2799,这个 KEP 的一个目的是不再为 ServiceAccount 自动生成 token Secret,另外一个目的是要清除未被使用的 ServiceAccount 产生的 token Secret。

对于第一个目的,社区提供了LegacyServiceAccountTokenNoAutoGeneration特性开关,该特性开关在 Kubernetes 1.24 版本中已进入 Beta 阶段,这也正是 Karmada 控制面无法生成 token Secret 的原因。当然了,如果用户仍想使用之前的方式,为 ServiceAccount 生成 Secret,可以参考此处进行操作。