CrashLoopBackOff для kube-планировщика из-за отсутствия служебного токена - PullRequest
Новая
       46

CrashLoopBackOff для kube-планировщика из-за отсутствия служебного токена

0 голосов
/ 11 октября 2019

У меня проблема с моим кластером Kubernetes, где мой модуль kube-планировщика застрял в состоянии '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. *.

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

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

Гарри

Ответы [ 2 ]

1 голос
/ 11 октября 2019

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

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

0 голосов
/ 14 октября 2019

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

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

Я запустил следующее в каталоге /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.

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

Irun: 

{
  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 ошибки прекратились, и все вернулось к жизни.

...