故障定位

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

  • 从K8s镜像仓库（registry.k8s.io）拉取镜像。

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

    1. sed -i'' -e "s#registry.k8s.io#registry.aliyuncs.com/google_containers#g" artifacts/deploy/karmada-etcd.yaml
    2. sed -i'' -e "s#registry.k8s.io#registry.aliyuncs.com/google_containers#g" artifacts/deploy/karmada-apiserver.yaml
    3. sed -i'' -e "s#registry.k8s.io#registry.aliyuncs.com/google_containers#g" artifacts/deploy/kube-controller-manager.yaml

  • 在中国大陆下载 Golang 软件包，并在安装前运行以下命令。

    1. export GOPROXY=https://goproxy.cn

成员集群健康检查不工作

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

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

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

  • 登录到成员集群 apiserver 所在的节点上
  • 使用tcpkill命令来关闭 TCP 连接。
  1. # ens192 是成员集群用来与 karmada 通信的网卡的名字 
  2. 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安装日志中发现以下报错信息：

  1. 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一直崩溃，查看组件的日志时发现以下错误日志：

  1. 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"}
  2. I1121 06:33:46.167045       1 webhook.go:113] registering webhooks to the webhook server
  3. I1121 06:33:46.169425       1 internal.go:362] "Starting server" path="/metrics" kind="metrics" addr="[::]:8080"
  4. I1121 06:33:46.169569       1 internal.go:362] "Starting server" kind="health probe" addr="[::]:8000"
  5. I1121 06:33:46.169670       1 shared_informer.go:285] caches populated
  6. I1121 06:33:46.169828       1 internal.go:567] "Stopping and waiting for non leader election runnables"
  7. I1121 06:33:46.169848       1 internal.go:571] "Stopping and waiting for leader election runnables"
  8. I1121 06:33:46.169856       1 internal.go:577] "Stopping and waiting for caches"
  9. I1121 06:33:46.169883       1 internal.go:581] "Stopping and waiting for webhooks"
  10. I1121 06:33:46.169899       1 internal.go:585] "Wait completed, proceeding to shutdown the manager"
  11. E1121 06:33:46.169909       1 webhook.go:132] webhook server exits unexpectedly: too many open files
  12. E1121 06:33:46.169926       1 run.go:74] "command failed" err="too many open files"

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

  1. sysctl fs.inotify.max_user_watches=16384
  2. sysctl -w fs.inotify.max_user_watches=100000
  3. 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，可以参考此处进行操作。

因 “cluster(s) did not have the API resource” 调度失败

Karmada 的 detector 组件对于资源模板只关注 karmada-apiserver 首选版本。

假设 karmada-apiserver 是 v1.25 版本，则其 HPA 资源同时具有 autoscaling/v1 和 autoscaling/v2 版本。 但是，由于 HPA 的首选版本是 autoscaling/v2，因此 detector 只会 list/watch autoscaling/v2 版本的 HPA。 如果用户创建的是 autoscaling/v1 版本的 HPA 资源模板，kubernetes 会产生这两个版本 HPA 的创建事件， 但 detector 只监听和处理 autoscaling/v2 版本 HPA 的创建事件。

在此背景下，您需要注意以下两点：

  • 在编写 PropagationPolicy 时，其 resourceSelector 字段仅支持筛选该资源的首选版本。
  • 成员集群 apiserver 也应支持该资源的首选版本。

更详细地说，还是以 HPA 为例，您被推荐在资源模板和 PropagationPolicy 中都使用 HPA 首选版本，即 autoscaling/v2，例如：

propagate autoscaling/v2 by select autoscaling/v2

  1. apiVersion: autoscaling/v2
  2. kind: HorizontalPodAutoscaler
  3. metadata:
  4.   name: test-hpa
  5.   namespace: default
  6. spec:
  7.   behavior:
  8.     scaleUp:
  9.       policies:
  10.         - type: Percent
  11.           value: 100
  12.           periodSeconds: 15
  13.         - type: Pods
  14.           value: 4
  15.           periodSeconds: 15
  16.       selectPolicy: Max
  17.       stabilizationWindowSeconds: 0
  18.   maxReplicas: 10
  19.   minReplicas: 1
  20.   scaleTargetRef:
  21.     apiVersion: apps/v1
  22.     kind: Deployment
  23.     name: d1
  24. ---
  25. apiVersion: policy.karmada.io/v1alpha1
  26. kind: PropagationPolicy
  27. metadata:
  28.   name: tetst-hpa-pp
  29. spec:
  30.   placement:
  31.     clusterAffinity:
  32.       clusterNames:
  33.         - member1
  34.   resourceSelectors:
  35.     - apiVersion: autoscaling/v2
  36.       kind: HorizontalPodAutoscaler
  37.       name: test-hpa
  38.       namespace: default

然而，如果您坚持要使用 autoscaling/v1 版本的 HPA 资源模板，通过在 PropagationPolicy 中的 resourceSelector 字段声明 筛选版本为 autoscaling/v2 的 HPA 资源，也能实现成功分发，例如：

propagate autoscaling/v1 by select autoscaling/v2

  1. apiVersion: autoscaling/v1
  2. kind: HorizontalPodAutoscaler
  3. metadata:
  4.   name: test-hpa
  5. spec:
  6.   maxReplicas: 5
  7.   minReplicas: 1
  8.   scaleTargetRef:
  9.     apiVersion: apps/v1
  10.     kind: Deployment
  11.     name: nginx
  12.   targetCPUUtilizationPercentage: 10
  13. ---
  14. apiVersion: policy.karmada.io/v1alpha1
  15. kind: PropagationPolicy
  16. metadata:
  17.   name: test-hpa-pp
  18. spec:
  19.   placement:
  20.     clusterAffinity:
  21.       clusterNames:
  22.         - member1
  23.   resourceSelectors:
  24.     - apiVersion: autoscaling/v2
  25.       kind: HorizontalPodAutoscaler
  26.       name: test-hpa
  27.       namespace: default

最终，Karmada 会将 autoscaling/v2 版本的 HPA 下发到成员集群 ，如果您的成员集群不支持 autoscaling/v2 版本的 HPA， 您会得到例如 “cluster(s) did not have the API resource” 的调度失败报错事件。