Question

我的Kubernetes集群出现问题，我的kube-scheduler吊舱卡在“ 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安装在每个吊舱中，并包含用于访问Kubernetes API服务器的身份验证令牌。

您可以通过在部署配置中指定automountServiceAccountToken: false来禁用安装。带有Kubernetes设置程序的terraform之类的某些工具也默认情况下会禁用挂载令牌。在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>

由于缺少服务令牌而导致kube-scheduler发生CrashLoopBackOff

3 个答案: