Почему kubeadm/kubelet не запускает плоскость управления kubernetes в моем кластере?

Question

Почему kubeadm/kubelet не запускает плоскость управления kubernetes в моем кластере?

Я пытаюсь создать новый кластер kubernetes, следуя стандартным руководствам "kubeadm init", которые можно найти на веб-сайте k8s.

Кажется, что Kubeadm успешно завершает все предполетные проверки и извлекает изображения плоскости управления из Интернета, но затем истекает время ожидания, пока демон kubelet станет здоровым.

Главный узел, на котором я пытаюсь запустить kubeadm, - это машина CentOS 7.8 с установленным Kubernetes 1.18.6 вместе с podman 1.6.4-18 и cri-o 1.14.9-1 в качестве среды выполнения контейнера. Kubeadm извлекает изображения плоскости управления 1.18.8, etcd 3.4.3-0, coredns 1.6.7 и паузу 3.2.

Я запускаю kubeadm с помощью следующей команды:

sudo kubeadm init --apiserver-advertise-address=10.125.231.100 --pod-network-cidr=10.244.0.0/16 --v=5

И ошибка, которую я получаю:

[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refused.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refused.

    Unfortunately, an error has occurred:
        timed out waiting for the condition

Проверка того, с какими контейнерами работают crictl ps -a показывает, что контейнеры не запущены, но crictl images показывает изображения, которые kubeadm извлек из интернета.

Проверка логов кубелет с помощью sudo journalctl -xeu kubelet, Я вижу следующие ошибки:

Sep 03 18:52:09 k8s-master kubelet[32635]: E0903 18:52:09.186939   32635 reflector.go:178] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.125.231.100:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dk8s-master&limit=500&resourceVersion=0: dial tcp 10.125.231.100:6443: connect: connection refused
Sep 03 18:52:09 k8s-master kubelet[32635]: E0903 18:52:09.434226   32635 reflector.go:178] k8s.io/kubernetes/pkg/kubelet/kubelet.go:526: Failed to list *v1.Node: Get https://10.125.231.100:6443/api/v1/nodes?fieldSelector=metadata.name%3Dk8s-master&limit=500&resourceVersion=0: dial tcp 10.125.231.100:6443: connect: connection refused
Sep 03 18:52:13 k8s-master kubelet[32635]: E0903 18:52:13.557632   32635 reflector.go:178] k8s.io/kubernetes/pkg/kubelet/kubelet.go:517: Failed to list *v1.Service: Get https://10.125.231.100:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 10.125.231.100:6443: connect: connection refused
Sep 03 18:52:14 k8s-master kubelet[32635]: W0903 18:52:14.891351   32635 clientconn.go:1208] grpc: addrConn.createTransport failed to connect to {/var/run/crio/crio.sock  <nil> 0 <nil>}: didn't receive server preface in time. Reconnecting...
Sep 03 18:52:14 k8s-master kubelet[32635]: W0903 18:52:14.891422   32635 clientconn.go:1208] grpc: addrConn.createTransport failed to connect to {/var/run/crio/crio.sock  <nil> 0 <nil>}: didn't receive server preface in time. Reconnecting...
Sep 03 18:52:14 k8s-master kubelet[32635]: E0903 18:52:14.891470   32635 remote_runtime.go:81] Version from runtime service failed: rpc error: code = Unavailable desc = timed out waiting for server handshake
Sep 03 18:52:14 k8s-master kubelet[32635]: E0903 18:52:14.891541   32635 kuberuntime_manager.go:197] Get runtime version failed: get remote runtime typed version failed: rpc error: code = Unavailable desc = timed out waiting for server handshake
Sep 03 18:52:14 k8s-master kubelet[32635]: F0903 18:52:14.891571   32635 server.go:274] failed to run Kubelet: failed to create kubelet: get remote runtime typed version failed: rpc error: code = Unavailable desc = timed out waiting for server handshake
Sep 03 18:52:14 k8s-master systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
Sep 03 18:52:14 k8s-master systemd[1]: Unit kubelet.service entered failed state.
Sep 03 18:52:14 k8s-master systemd[1]: kubelet.service failed.

cri-o, похоже, находится в состоянии готовности, о чем свидетельствуют результаты crictl info:

{
  "status": {
    "conditions": [
      {
        "type": "RuntimeReady",
        "status": true,
        "reason": "",
        "message": ""
      },
      {
        "type": "NetworkReady",
        "status": true,
        "reason": "",
        "message": ""
      }
    ]
  }
}

На данный момент я могу только предположить, что изображения плоскости управления не запускаются. Я не понимаю, что проверять дальше, чтобы определить, почему.

Кстати, пытается ли kubeadm или kubelet запустить плоскость управления? Если последнее, меня беспокоит строка с ошибкой:

Sep 03 18:52:14 k8s-master kubelet[32635]: W0903 18:52:14.891422   32635 clientconn.go:1208] grpc: addrConn.createTransport failed to connect to {/var/run/crio/crio.sock  <nil> 0 <nil>}: didn't receive server preface in time. Reconnecting...

Исходя из бревен кубелет. Я протестировал podman, запустив образ контейнера, и, похоже, он работает нормально, но, насколько я понимаю, podman и cri-o не совсем одно и то же.

Мое исследование показало, что проблема может быть вызвана такими вещами, как включение файлов подкачки, но я подтвердил, что файлы подкачки отключены и предварительная проверка подкачки проходит.

Что мне следует проверить для дальнейшей отладки проблемы с не запуском образов плоскости управления, и отвечает ли kubeadm или kubelet за запуск этих контейнеров? В частности, есть ли какие-либо настройки SELinux/Firewall/ другие, которые мне нужно проверить?

0

kubernetes podman linux-containers cri-o

Источник

user2343779 03 сен '20 в 22:09

1 ответ

Другие вопросы по тегам kubernetes podman linux-containers cri-o

user2343779 04 сен '20 в 20:04 2020-09-04 20:04 · Answer 1 · 2020-09-04 20:04

Мы смогли определить, как решить проблему (у которой было несколько причин).

Проблемы:

CRI-O был версии 1.16; нам нужна была 1.18. После исправления этой проблемы путем обновления до cri-o 1.18, kubelet смог связаться с /var/run/crio/crio.sock.
Однако это не удалось с "cgroup не удалось получить срез". Чтобы исправить это, нам просто нужно было обновить аргументы kubelet, чтобы включить--cgroup-driver=systemd