Из-за чего инициализация кластера завершается ошибкой?

Ссылка скопирована
haproxy kubernetes
1 ответ

По вводным: пытаюсь инициализировать мастер ноду Kubernetes: 

kubeadm init --pod-network-cidr=172.16.0.0/16 \ --control-plane-endpoint "10.2.26.17:6443" \ --upload-certs

Где10.2.26.17Сейчас ситуация такая: - VIP haproxy. Но инициализация завершается ошибкой:

Последняя часть лога

I0116 09:48:46.551386 105111 envvar.go:172] "Feature gate default state" feature="InformerResourceVersion" enabled=false I0116 09:48:46.551532 105111 envvar.go:172] "Feature gate default state" feature="WatchListClient" enabled=false I0116 09:48:46.551582 105111 envvar.go:172] "Feature gate default state" feature="ClientsAllowCBOR" enabled=false I0116 09:48:46.551618 105111 envvar.go:172] "Feature gate default state" feature="ClientsPreferCBOR" enabled=false I0116 09:48:46.551658 105111 envvar.go:172] "Feature gate default state" feature="InOrderInformers" enabled=true [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests" [kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s [kubelet-check] The kubelet is healthy after 501.675827ms [control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s [control-plane-check] Checking kube-apiserver at https://10.1.62.52:6443/livez [control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz [control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez [control-plane-check] kube-controller-manager is not healthy after 4m0.000626064s [control-plane-check] kube-scheduler is not healthy after 4m0.000944424s [control-plane-check] kube-apiserver is not healthy after 4m0.000945396s A control plane component may have crashed or exited when started by the container runtime. To troubleshoot, list all containers using your preferred container runtimes CLI. Here is one example how you may list all running Kubernetes containers by using crictl: - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a | grep kube | grep -v pause' Once you have found the failing container, you can inspect its logs with: - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock logs CONTAINERID' error: error execution phase wait-control-plane: failed while waiting for the control plane to start: [kube-controller-manager check failed at https://127.0.0.1:10257/healthz: Get "https://127.0.0.1:10257/healthz": dial tcp 127.0.0.1:10257: connect: connection refused, kube-scheduler check failed at https://127.0.0.1:10259/livez: Get "https://127.0.0.1:10259/livez": dial tcp 127.0.0.1:10259: connect: connection refused, kube-apiserver check failed at https://10.1.62.52:6443/livez: client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline] k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1 k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:262 k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:450 k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:234 k8s.io/kubernetes/cmd/kubeadm/app/cmd.newCmdInit.func1 k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:135 github.com/spf13/cobra.(*Command).execute github.com/spf13/cobra@v1.9.1/command.go:1015 github.com/spf13/cobra.(*Command).ExecuteC github.com/spf13/cobra@v1.9.1/command.go:1148 github.com/spf13/cobra.(*Command).Execute github.com/spf13/cobra@v1.9.1/command.go:1071 k8s.io/kubernetes/cmd/kubeadm/app.Run k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 main.main k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:25 runtime.main runtime/proc.go:285 runtime.goexit runtime/asm_amd64.s:1693
Нужно решить такую задачу?

Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.

Заказать помощь
Лучший ответ
1
Юрий Linux Ответ

Ошибка инициализации кластера с HAProxy обычно возникает не из-за самого Kubernetes, а из-за того, что control-plane во время bootstrap не может стабильно достучаться до API endpoint. Если вы запускаете kubeadm через виртуальный адрес или DNS, который смотрит на HAProxy, этот адрес должен быть доступен уже в момент инициализации первого master-узла.

Проверьте три вещи: HAProxy запущен, backend указывает на правильный порт kube-apiserver, а endpoint из controlPlaneEndpoint резолвится и открывается с самого узла, где выполняется kubeadm init. Частая ошибка — указывать VIP/домен, который ведёт на HAProxy, но сам HAProxy ещё считает backend недоступным, потому что apiserver ещё не поднялся.

ss -lntp | grep 6443
curl -k https://127.0.0.1:6443/healthz
curl -k https://cluster-api.example.local:6443/healthz
journalctl -u kubelet -n 120 --no-pager
crictl ps -a | grep kube-apiserver

ss -lntp | grep 6443 curl -k https://127.0.0.1:6443/healthz curl -k https://cluster-api.example.local:6443/healthz journalctl -u kubelet -n 120 --no-pager crictl ps -a | grep kube-apiserver

Если это первый control-plane, для HAProxy backend можно временно направить на этот же узел, но нужно учитывать порядок запуска. Иногда проще сначала поднять первый master с endpoint, который уже указывает на будущий балансировщик, затем добавить остальные master-узлы. Важно, чтобы имя endpoint и сертификаты совпадали: домен или IP балансировщика должен попасть в SAN сертификата apiserver.

Минимальная конфигурация HAProxy для проверки выглядит так:

frontend kube_api
    bind *:6443
    mode tcp
    default_backend kube_api_backends
 
backend kube_api_backends
    mode tcp
    option tcp-check
    server master1 10.0.0.11:6443 check

frontend kube_api bind *:6443 mode tcp default_backend kube_api_backends backend kube_api_backends mode tcp option tcp-check server master1 10.0.0.11:6443 check

Если HAProxy находится на тех же master-узлах, следите за конфликтом портов. HAProxy не должен занимать тот же интерфейс и порт, на котором kube-apiserver должен слушать локально. Для локальной схемы чаще используют отдельный VIP через keepalived и HAProxy на каждом master, либо отдельную пару балансировщиков.

Итог: смотрите не только сообщение kubeadm, а цепочку endpoint → HAProxy → backend → kubelet → static pod kube-apiserver. В 80% случаев проблема в недоступном controlPlaneEndpoint, неправильном SAN, конфликте порта 6443 или в том, что HAProxy включён в схему раньше, чем появился живой backend.

Другие ответы (0)

Пока нет других ответов. Будьте первым, кто поможет автору.

Ответить на вопрос

комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вам также может быть интересно

VPN Как правильно настроить vless для Android TV? 1 ответ Pyrogram Как правильно зарегистрировать юзер бота в Telegram? 1 ответ печатные-платы Как заставить запускаться программу M3.exe от компании Hanxing AOI в инспекционной машине на Windows 7 Pro? 1 ответ Аккумуляторные батареи Почему при зарядке автостарта слышен писк, где искать причину? 1 ответ