CrashLoopBackOff для kube-scheduler из-за отсутствия токена службы

У меня проблема с моим кластером 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 где он должен храниться (путь на хосте или внутри контейнера) и как мне его восстановить?

Я использую версию 1.15.4 на всех моих узлах, которые были настроены с использованием kubeadm. Я тупо обновил кластер с тех пор, как эта ошибка впервые началась (я читал, что это может быть ошибка в версии, которую я использовал). Раньше я использовал версию 1.14.*.

Любая помощь будет принята с благодарностью; все работает на этом кластере, и я чувствую, что мои руки были отрезаны без него.

Заранее спасибо,

Гарри

Источник

3 ответа

Решение

Оказывается, поскольку капсула kube-scheduler, то /var/run/secrets/kubernetes.io/serviceaccount/token журналы относятся к монтируется из /etc/kubernetes/scheduler.conf на главном узле.

По какой-то причине это был совершенно пустой файл в моем кластере. Я регенерировал его, следуя инструкциям для kube-scheduler в Kubernetes на собственном горьком опыте:

Я запустил следующее в /etc/kubernetes/pki каталог (где остались исходные центры сертификации):

{

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.

Затем мне нужно было сгенерировать новый файл конфигурации, используя приведенные здесь инструкции.

Я побежал:

{
  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.

Тогда это был просто случай чтения логов из модуля (kubectl logs kube-scheduler-xxxxxxx -n kube-system), который будет жаловаться на различные вещи, отсутствующие в файле конфигурации.

Это были блоки "кластеры" и "контексты" YAML, которые я скопировал из одного из других файлов конфигурации в том же каталоге (после проверки, что все они идентичны).

После копирования в scheduler.conf ошибки прекратились, и все вернулось к жизни.

Источник

По умолчанию /var/run/secrets/kubernetes.io/serviceaccount/token монтируется в каждом модуле и содержит токен аутентификации для доступа к вашему серверу Kubernetes API.

Вы можете отключить его установку, указав automountServiceAccountToken: falseв конфигурации развертывания. Некоторые инструменты, такие какterraformс помощью Kubernetes Provider также отключите монтирование токена по умолчанию. Наterraform это можно включить, добавив automount_service_account_token = true к спецификации развертывания.

Источник

У меня была такая же проблема с 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>
Источник
Другие вопросы по тегам