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

Question

我的 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 是什么，它应该存储在哪里（是主机上的路径还是容器内的路径）以及如何重新生成它？

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

任何帮助将不胜感激；一切都在这个集群上运行，我觉得我的手臂已经被切断了。

提前致谢，

哈利

Answer 1

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

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

Answer 2

事实证明，由于 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.pem 和kube-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 的“集群”和“上下文”块（在验证它们都相同之后）。

将这些复制到scheduler.conf 后，错误停止了，一切都恢复了活力。

Answer 3

我在使用 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>