由于缺少服务令牌,kube-scheduler 的 CrashLoopBackOff

CrashLoopBackOff for kube-scheduler Due to Missing Service Token

我的 Kubernetes 集群有问题,我的 kube-scheduler pod 卡在 'CrashLoopBackOff' 状态,我无法纠正它。日志抱怨缺少服务令牌:

kubectl logs kube-scheduler-master -n kube-system
I1011 09:01:04.309289       1 serving.go:319] Generated self-signed cert in-memory
W1011 09:01:20.579733       1 authentication.go:387] failed to read in-cluster kubeconfig for delegated authentication: open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory
W1011 09:01:20.579889       1 authentication.go:249] No authentication-kubeconfig provided in order to lookup client-ca-file in configmap/extension-apiserver-authentication in kube-system, so client certificate authentication won't work.
W1011 09:01:20.579917       1 authentication.go:252] No authentication-kubeconfig provided in order to lookup requestheader-client-ca-file in configmap/extension-apiserver-authentication in kube-system, so request-header client certificate authentication won't work.
W1011 09:01:20.579990       1 authorization.go:177] failed to read in-cluster kubeconfig for delegated authorization: open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory
W1011 09:01:20.580040       1 authorization.go:146] No authorization-kubeconfig provided, so SubjectAccessReview of authorization tokens won't work.
invalid configuration: no configuration has been provided

任何人都可以解释一下 /var/run/secrets/kubernetes.io/serviceaccount/token 是什么,它应该存储在哪里(是主机上的路径还是容器内的路径)以及我该如何重新生成它?

我的所有节点都是 运行 版本 1.15.4,这些节点是使用 kubeadm 设置的。自从这个错误第一次出现以来,我 愚蠢地 升级了集群(我读到它可能是我使用的版本中的一个错误)。我之前使用的是 1.14.*.

版本

如有任何帮助,我们将不胜感激;一切都在这个集群上运行,我觉得没有它我的手臂已经被切断了。

提前致谢,

哈利

默认情况下 /var/run/secrets/kubernetes.io/serviceaccount/token 安装在每个 pod 中并包含用于访问您的 Kubernetes API 服务器的身份验证令牌。

您可以通过在部署配置中指定 automountServiceAccountToken: false 来禁用安装它。一些工具,如 terraform with Kubernetes provisioner 也默认禁用挂载令牌。在 terraform 上,可以通过将 automount_service_account_token = true 添加到部署规范来重新启用。

事实证明,由于 pod 是 kube-scheduler,日志所指的 /var/run/secrets/kubernetes.io/serviceaccount/token 是从主节点上的 /etc/kubernetes/scheduler.conf 安装的。

无论出于何种原因,这在我的集群中都是一个完全空的文件。我按照 Kubernetes the hard way:

上的 kube-scheduler 说明重新生成了它

我 运行 /etc/kubernetes/pki 目录中的以下内容(原始 CA 保留的位置):

{

cat > kube-scheduler-csr.json <<EOF
{
  "CN": "system:kube-scheduler",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-scheduler",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-scheduler-csr.json | cfssljson -bare kube-scheduler

}

生成 kube-scheduler-key.pemkube-scheduler.pem

接下来,我需要使用指令 here.

生成新的配置文件

我运行:

{
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config set-credentials system:kube-scheduler \
    --client-certificate=kube-scheduler.pem \
    --client-key=kube-scheduler-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-scheduler \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config use-context default --kubeconfig=kube-scheduler.kubeconfig
}

生成 kube-scheduler.kubeconfig,我重命名并移动到 /etc/kubernetes/scheduler.conf

这只是一个从 pod (kubectl logs kube-scheduler-xxxxxxx -n kube-system) 读取日志的情况,它会抱怨配置文件中缺少各种东西。

这些是我从同一目录中的其他配置文件之一复制的 YAML 的 'clusters' 和 'contexts' 块(在验证它们完全相同之后)。

将这些复制到 scheduler.conf 后,错误停止,一切恢复正常。

我在使用 Kubernetes v13 时遇到了同样的问题。 我用以下命令修复了它。

空 scheduler.conf 文件会导致 panic: runtime error: invalid memory address or nil pointer dereference.

所以,我们将其删除。

$ rm /etc/kubernetes/scheduler.conf

并重新生成 scheduler.conf。

$ kubeadm init phase kubeconfig scheduler --apiserver-advertise-address <YOUR_IP>