Kubeadm и kubectl – соединение отклонено

Вопрос или проблема

Я развернул базовый кластер на двух виртуальных машинах (kvm), одна из которых была назначена мастером с контрольной плоскостью на ней, используя kubeadm init – все, кажется, запускается корректно, но когда я пытаюсь выполнить даже самые простые проверки с использованием kubectl, я получаю ошибку отказа в соединении.

ОБНОВЛЕНИЕ 2:

Заработало, но я не понимаю почему – изначально я запускал все как выделенный пользователь с sudo. Как только я перешел в режим root (su root) и повторил шаги, все начало работать. Что привело к изменению, связано ли это с нахождением в окружении root вместо пользователя? Разное домашнее каталог? Рабочий каталог? Я в замешательстве.

ОБНОВЛЕНИЕ 1: Минимальный пример сбоя:

На этот раз я создал еще одну виртуальную машину с Ubuntu 20.04, пытаясь сделать ее репликой Этого Урока как можно ближе к оригинальному примеру, но последний шаг не удается, так же как и моя исходная проблема. Завершено ли это руководство?

Выполнить шаг за шагом:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
apt update
apt install -y kubelet=1.20.0-00 kubeadm=1.20.0-00 kubectl=1.20.0-00
apt-mark hold kubelet kubeadm kubectl
export VERSION=19.03 && curl -sSL get.docker.com | sh

cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

systemctl enable docker
systemctl daemon-reload
systemctl restart docker

kubeadm init --ignore-preflight-errors=all

>>> На этом этапе все проваливается - не хватает какого-то сервиса?

Дополнительная информация о среде:

  • хост – Ubuntu 20.04 LTS, запущен kvm
  • гость (здесь я устанавливаю k8s) – Ubuntu server 22.04
  • сеть хоста на 192.168.x.y
  • мост для ВМ на 10.0.1.x/24
  • UFW неактивен

Сеть:

ip route show
  • по умолчанию через 10.0.1.254 dev ens3 proto static # это часть моста, который подключает мою виртуальную машину к внешнему миру.
  • 10.0.1.0/24 dev ens3 proto kernel scope link src 10.0.1.10 # Это IP-адрес машины. Машины, хостингующие узлы, будут иметь IP, заканчивающиеся на 11, 12, 13 и т.д.
  • 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown # авто-создано докером – никогда не разбирался в современном формате маски сети, поэтому доверяю докеру /16.
    Я ничего с ним не делал.
cat /etc/hosts

Я добавил primary в хосты, остальное авто-создано.

127.0.0.1 localhost
127.0.0.1 primary
127.0.1.1 k8-vm

# Следующие строки желательны для хостов с поддержкой IPv6
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
конфигурация демона докера
cat /etc/docker/daemon.json 
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

me@k8-vm:~$ kubectl get pods

E0117 09:10:43.476675   13492 memcache.go:265] couldn't get current server API group list: Get "https://10.0.1.10:6443/api?timeout=32s": dial tcp 10.0.1.10:6443: connect: connection refused
E0117 09:10:43.477525   13492 memcache.go:265] couldn't get current server API group list: Get "https://10.0.1.10:6443/api?timeout=32s": dial tcp 10.0.1.10:6443: connect: connection refused
E0117 09:10:43.479198   13492 memcache.go:265] couldn't get current server API group list: Get "https://10.0.1.10:6443/api?timeout=32s": dial tcp 10.0.1.10:6443: connect: connection refused
E0117 09:10:43.479754   13492 memcache.go:265] couldn't get current server API group list: Get "https://10.0.1.10:6443/api?timeout=32s": dial tcp 10.0.1.10:6443: connect: connection refused
E0117 09:10:43.481822   13492 memcache.go:265] couldn't get current server API group list: Get "https://10.0.1.10:6443/api?timeout=32s": dial tcp 10.0.1.10:6443: connect: connection refused
The connection to the server 10.0.1.10:6443 was refused - did you specify the right host or port?

Я настроил конфигурацию в ~/.kube/config :

cat ~/.kube/config 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: secret_stuff
    server: https://10.0.1.10:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: secret_stuff
    client-key-data: secret_stuff

Я пробовал сбрасывать таблицы маршрутизации iptables, но что-то восстанавливает их обратно. Подозрительные записи в iptables:

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination         
DROP       all  -- !localhost/8          localhost/8          /* block incoming     localnet connections */ ! ctstate RELATED,ESTABLISHED,DNAT

Chain KUBE-FORWARD (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere             ctstate INVALID
Chain KUBE-SERVICES (2 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             10.96.0.1            /* default/kubernetes:https has no endpoints */ reject-with icmp-port-unreachable
REJECT     udp  --  anywhere             10.96.0.10           /* kube-system/kube-dns:dns has no endpoints */ reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             10.96.0.10           /* kube-system/kube-dns:dns-tcp has no endpoints */ reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             10.96.0.10           /* kube-system/kube-dns:metrics has no endpoints */ reject-with icmp-port-unreachable

могут ли iptables блокировать доступ kubectl?


логи, выводы:

me@primary:~$ sudo kubeadm init –apiserver-advertise-address=172.105.148.95 –apiserver-cert-extra-sans=172.105.148.95 –pod-network-cidr=10.13.13.0/16 –node-name primary

[init] Использование версии Kubernetes: v1.29.1
[preflight] Выполнение предварительных проверок
[preflight] Загрузка образов, необходимых для настройки кластера Kubernetes
[preflight] Это может занять минуту или две, в зависимости от скорости вашего интернет-соединения
[preflight] Вы также можете выполнить это действие заранее, используя 'kubeadm config images pull'
W0119 09:35:48.771333    2949 checks.go:835] обнаружено, что образ "registry.k8s.io/pause:3.8" контейнерного времени выполнения не соответствует используемому kubeadm. Рекомендуется использовать "registry.k8s.io/pause:3.9" как образ песочницы CRI.
[certs] Использование каталога сертификатов "/etc/kubernetes/pki"
[certs] Генерация сертификата и ключа "ca"
[certs] Генерация сертификата и ключа "apiserver"
[certs] Сертификат серверного apiserver подписан на DNS-имена [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local primary] и IP-адреса [10.96.0.1 172.105.148.95]
[certs] Генерация сертификата и ключа "apiserver-kubelet-client"
[certs] Генерация сертификата и ключа "front-proxy-ca"
[certs] Генерация сертификата и ключа "front-proxy-client"
[certs] Генерация сертификата и ключа "etcd/ca"
[certs] Генерация сертификата и ключа "etcd/server"
[certs] Сертификат серверного etcd подписан на DNS-имена [localhost primary] и IP-адреса [172.105.148.95 127.0.0.1 ::1]
[certs] Генерация сертификата и ключа "etcd/peer"
[certs] Сертификат аренды etcd подписан на DNS-имена [localhost primary] и IP-адреса [172.105.148.95 127.0.0.1 ::1]
[certs] Генерация сертификата и ключа "etcd/healthcheck-client"

   [certs] Генерация ключа и публичного ключа "sa"
    [kubeconfig] Использование каталога kubeconfig "/etc/kubernetes"
    [kubeconfig] Запись kubeconfig файла "admin.conf"
    [kubeconfig] Запись kubeconfig файла "super-admin.conf"
    [kubeconfig] Запись kubeconfig файла "kubelet.conf"
    [kubeconfig] Запись kubeconfig файла "controller-manager.conf"
    [kubeconfig] Запись kubeconfig файла "scheduler.conf"
    [etcd] Создание статического Pod-манифеста для локального etcd в "/etc/kubernetes/manifests"
    [control-plane] Использование каталога манифестов "/etc/kubernetes/manifests"
    [control-plane] Создание статического Pod-манифеста для "kube-apiserver"
    [control-plane] Создание статического Pod-манифеста для "kube-controller-manager"
    [control-plane] Создание статического Pod-манифеста для "kube-scheduler"
    [kubelet-start] Запись файла среды kubelet с флагами в файл "/var/lib/kubelet/kubeadm-flags.env"
    [kubelet-start] Запись конфигурации kubelet в файл "/var/lib/kubelet/config.yaml"
    [kubelet-start] Запуск kubelet
[wait-control-plane] Ожидание загрузки контрольной плоскости kubelet в виде статических Pod-ов из каталога "/etc/kubernetes/manifests". Это может занять до 4 минут
[kubelet-check] Время начального тайм-аута: 40 секунд прошло.

К сожалению, произошла ошибка:
        истекло время ожидания условия

Эта ошибка, вероятно, вызвана:
        - Kubelet не запущен
        - Kubelet нестабилен из-за неправильной настройки узла каким-то образом (необходимые cgroups отключены)

Если у вас система, работающая на основе systemd, вы можете попробовать устранить ошибку с помощью следующих команд:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Кроме того, может быть, что компонент контрольной плоскости разбился или завершил работу при запуске контейнерного времени выполнения.
Для устранения, перечислите все контейнеры, используя CLI вашего предпочтительного контейнерного времени выполнения.
Вот один из примеров, как вы можете перечислить все работающие контейнеры Kubernetes, используя crictl:
        - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a | grep kube | grep -v pause'
        Как только вы найдете неудачный контейнер, вы можете просмотреть его логи с помощью:
        - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock logs CONTAINERID'
ошибка выполнения фазы wait-control-plane: не удалось инициализировать кластер Kubernetes
Чтобы увидеть трассировку стека этой ошибки, выполните с --v=5 или выше

@user23204747 – отвечая на ваш вопрос:

journalctl -fu kubelet
Jan 19 09:42:58 primary kubelet[3063]: E0119 09:42:58.312695    3063 kubelet_node_status.go:96] "Невозможно зарегистрировать узел с API сервером" err="Post \"https://172.105.148.95:6443/api/v1/nodes\": dial tcp 172.105.148.95:6443: connect: connection refused" node="primary"
Jan 19 09:42:59 primary kubelet[3063]: E0119 09:42:59.476195    3063 event.go:355] "Невозможно записать event (могут повторить попытку после сна)" err="Post \"https://172.105.148.95:6443/api/v1/namespaces/default/events\": dial tcp 172.105.148.95:6443: connect: connection refused" event="&Event{ObjectMeta:{primary.17abb5f60468180b  default    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},InvolvedObject:ObjectReference{Kind:Node,Namespace:,Name:primary,UID:primary,APIVersion:,ResourceVersion:,FieldPath:,},Reason:NodeHasSufficientPID,Message:Node primary status is now: NodeHasSufficientPID,Source:EventSource{Component:kubelet,Host:primary,},FirstTimestamp:2024-01-19 09:35:52.130377739 +0000 UTC m=+0.287533886,LastTimestamp:2024-01-19 09:35:52.130377739 +0000 UTC m=+0.287533886,Count:1,Type:Normal,EventTime:0001-01-01 00:00:00 +0000 UTC,Series:nil,Action:,Related:nil,ReportingController:kubelet,ReportingInstance:primary,}"
Jan 19 09:43:02 primary kubelet[3063]: E0119 09:43:02.208913    3063 eviction_manager.go:282] "Менеджер выселений: не удалось получить сводную статистику" err="не удалось получить информацию об узле: узел \"primary\" не найден"
Jan 19 09:43:05 primary kubelet[3063]: E0119 09:43:05.289531    3063 controller.go:145] "Не удалось обеспечить наличие аренды, будет повторяться" err="Get \"https://172.105.148.95:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/primary?timeout=10s\": dial tcp 172.105.148.95:6443: connect: connection refused" interval="7s"
Jan 19 09:43:05 primary kubelet[3063]: I0119 09:43:05.315765    3063 kubelet_node_status.go:73] "Попытка зарегистрировать узел" node="primary"
Jan 19 09:43:05 primary kubelet[3063]: E0119 09:43:05.424960    3063 kubelet_node_status.go:96] "Не удалось зарегистрировать узел с API сервером" err="Post \"https://172.105.148.95:6443/api/v1/nodes\": dial tcp 172.105.148.95:6443: connect: connection refused" node="primary"
Jan 19 09:43:05 primary kubelet[3063]: W0119 09:43:05.450439    3063 reflector.go:539] vendor/k8s.io/client-go/informers/factory.go:159: не удалось перечислить *v1.Service: Get "https://172.105.148.95:6443/api/v1/services?limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:05 primary kubelet[3063]: E0119 09:43:05.450569    3063 reflector.go:147] vendor/k8s.io/client-go/informers/factory.go:159: Не удалось отслеживать *v1.Service: не удалось перечислить *v1.Service: Get "https://172.105.148.95:6443/api/v1/services?limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:09 primary kubelet[3063]: I0119 09:43:09.129122    3063 scope.go:117] "УдалениеКонтейнера" containerID="af6057fbd0e43b4628685f316cffef08e6ea4a6236223120ce825681b53a45ad"
Jan 19 09:43:09 primary kubelet[3063]: E0119 09:43:09.129843    3063 pod_workers.go:1298] "Ошибка синхронизации pod-а, пропускается" err="не удалось \"StartContainer\" для \"etcd\" с CrashLoopBackOff: \"возврат 5m0s перезапуск неудачного контейнера=etcd pod=etcd-primary_kube-system(b8faf6a4553601b5610c06ed8c93f9e3)\"" pod="kube-system/etcd-primary" podUID="b8faf6a4553601b5610c06ed8c93f9e3"
Jan 19 09:43:09 primary kubelet[3063]: E0119 09:43:09.585849    3063 event.go:355] "Невозможно записать событие (могут повторить попытку после сна)" err="Post \"https://172.105.148.95:6443/api/v1/namespaces/default/events\": dial tcp 172.105.148.95:6443: connect: connection refused" event="&Event{ObjectMeta:{primary.17abb5f60468180b  default    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},InvolvedObject:ObjectReference{Kind:Node,Namespace:,Name:primary,UID:primary,APIVersion:,ResourceVersion:,FieldPath:,},Reason:NodeHasSufficientPID,Message:Node primary status is now: NodeHasSufficientPID,Source:EventSource{Component:kubelet,Host:primary,},FirstTimestamp:2024-01-19 09:35:52.130377739 +0000 UTC m=+0.287533886,LastTimestamp:2024-01-19 09:35:52.130377739 +0000 UTC m=+0.287533886,Count:1,Type:Normal,EventTime:0001-01-01 00:00:00 +0000 UTC,Series:nil,Action:,Related:nil,ReportingController:kubelet,ReportingInstance:primary,}"
Jan 19 09:43:12 primary kubelet[3063]: I0119 09:43:12.128675    3063 scope.go:117] "УдалениеКонтейнера" containerID="a9185c62d88f3192935626d7213b4378816563580b4afa1ac14b74f4029b548c"
Jan 19 09:43:12 primary kubelet[3063]: E0119 09:43:12.209179    3063 eviction_manager.go:282] "Менеджер выселений: не удалось получить сводную статистику" err="не удалось получить информацию об узле: узел \"primary\" не найден"
Jan 19 09:43:12 primary kubelet[3063]: E0119 09:43:12.398807    3063 controller.go:145] "Не удалось обеспечить наличие аренды, будет повторяться" err="Get \"https://172.105.148.95:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/primary?timeout=10s\": dial tcp 172.105.148.95:6443: connect: connection refused" interval="7s"
Jan 19 09:43:12 primary kubelet[3063]: I0119 09:43:12.427248    3063 kubelet_node_status.go:73] "Попытка зарегистрировать узел" node="primary"
Jan 19 09:43:12 primary kubelet[3063]: E0119 09:43:12.551820    3063 kubelet_node_status.go:96] "Не удалось зарегистрировать узел с API сервером" err="Post \"https://172.105.148.95:6443/api/v1/nodes\": dial tcp 172.105.148.95:6443: connect: connection refused" node="primary"
Jan 19 09:43:14 primary kubelet[3063]: W0119 09:43:14.542312    3063 reflector.go:539] vendor/k8s.io/client-go/informers/factory.go:159: не удалось перечислить *v1.CSIDriver: Get "https://172.105.148.95:6443/apis/storage.k8s.io/v1/csidrivers?limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:14 primary kubelet[3063]: E0119 09:43:14.542441    3063 reflector.go:147] vendor/k8s.io/client-go/informers/factory.go:159: Не удалось отслеживать *v1.CSIDriver: не удалось перечислить *v1.CSIDriver: Get "https://172.105.148.95:6443/apis/storage.k8s.io/v1/csidrivers?limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:17 primary kubelet[3063]: W0119 09:43:17.648986    3063 reflector.go:539] vendor/k8s.io/client-go/informers/factory.go:159: не удалось перечислить *v1.RuntimeClass: Get "https://172.105.148.95:6443/apis/node.k8s.io/v1/runtimeclasses?limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:17 primary kubelet[3063]: E0119 09:43:17.649087    3063 reflector.go:147] vendor/k8s.io/client-go/informers/factory.go:159: Не удалось отслеживать *v1.RuntimeClass: не удалось перечислить *v1.RuntimeClass: Get "https://172.105.148.95:6443/apis/node.k8s.io/v1/runtimeclasses?limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:19 primary kubelet[3063]: E0119 09:43:19.507898    3063 controller.go:145] "Не удалось обеспечить наличие аренды, будет повторяться" err="Get \"https://172.105.148.95:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/primary?timeout=10s\": dial tcp 172.105.148.95:6443: connect: connection refused" interval="7s"
Jan 19 09:43:19 primary kubelet[3063]: I0119 09:43:19.554658    3063 kubelet_node_status.go:73] "Попытка зарегистрировать узел" node="primary"
Jan 19 09:43:19 primary kubelet[3063]: E0119 09:43:19.679757    3063 kubelet_node_status.go:96] "Не удалось зарегистрировать узел с API сервером" err="Post \"https://172.105.148.95:6443/api/v1/nodes\": dial tcp 172.105.148.95:6443: connect: connection refused" node="primary"
Jan 19 09:43:19 primary kubelet[3063]: E0119 09:43:19.694847    3063 event.go:355] "Невозможно записать событие (могут повторить попытку после сна)" err="Post \"https://172.105.148.95:6443/api/v1/namespaces/default/events\": dial tcp 172.105.148.95:6443: connect: connection refused" event="&Event{ObjectMeta:{primary.17abb5f60468180b  default    0 0001-01-01 00:00:00 +0000 UTC <nil> <nil> map[] map[] [] [] []},InvolvedObject:ObjectReference{Kind:Node,Namespace:,Name:primary,UID:primary,APIVersion:,ResourceVersion:,FieldPath:,},Reason:NodeHasSufficientPID,Message:Node primary status is now: NodeHasSufficientPID,Source:EventSource{Component:kubelet,Host:primary,},FirstTimestamp:2024-01-19 09:35:52.130377739 +0000 UTC m=+0.287533886,LastTimestamp:2024-01-19 09:35:52.130377739 +0000 UTC m=+0.287533886,Count:1,Type:Normal,EventTime:0001-01-01 00:00:00 +0000 UTC,Series:nil,Action:,Related:nil,ReportingController:kubelet,ReportingInstance:primary,}"
Jan 19 09:43:20 primary kubelet[3063]: W0119 09:43:20.761463    3063 reflector.go:539] vendor/k8s.io/client-go/informers/factory.go:159: не удалось перечислить *v1.Node: Get "https://172.105.148.95:6443/api/v1/nodes?fieldSelector=metadata.name%3Dprimary&limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:20 primary kubelet[3063]: E0119 09:43:20.761607    3063 reflector.go:147] vendor/k8s.io/client-go/informers/factory.go:159: Не удалось отслеживать *v1.Node: не удалось перечислить *v1.Node: Get "https://172.105.148.95:6443/api/v1/nodes?fieldSelector=metadata.name%3Dprimary&limit=500&resourceVersion=0": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:21 primary kubelet[3063]: E0119 09:43:21.126858    3063 certificate_manager.go:562] kubernetes.io/kube-apiserver-client-kubelet: Не удалось запросить подписанный сертификат у управляющей плоскости: не удалось создать запрос на подпись сертификата: Post "https://172.105.148.95:6443/apis/certificates.k8s.io/v1/certificatesigningrequests": dial tcp 172.105.148.95:6443: connect: connection refused
Jan 19 09:43:22 primary kubelet[3063]: E0119 09:43:22.209975    3063 eviction_manager.go:282] "Менеджер выселений: не удалось получить сводную статистику" err="не удалось получить информацию об узле: узел \"primary\" не найден"
Jan 19 09:43:24 primary kubelet[3063]: I0119 09:43:24.129352    3063 scope.go:117] "УдалениеКонтейнера" containerID="af6057fbd0e43b4628685f316cffef08e6ea4a6236223120ce825681b53a45ad"
Jan 19 09:43:24 primary kubelet[3063]: E0119 09:43:24.130066    3063 pod_workers.go:1298] "Ошибка синхронизации pod-а, пропускается" err="не удалось \"StartContainer\" для \"etcd\" с CrashLoopBackOff: \"возврат 5m0s перезапуск неудачного контейнера=etcd pod=etcd-primary_kube-system(b8faf6a4553601b5610c06ed8c93f9e3)\"" pod="kube-system/etcd-primary" podUID="b8faf6a4553601b5610c06ed8c93f9e3"

podUID=”b8faf6a4553601b5610c06ed8c93f9e3″

Вывод CRI:

sudo crictl ps --all
WARN[0000] подключение времени выполнения с использованием стандартных конечных точек: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. Поскольку стандартные настройки в настоящее время устарели, вы должны установить конечную точку вместо этого.
ERRO[0000] проверить подключение сервиса: проверить CRI v1 API времени выполнения для конечной точки "unix:///var/run/dockershim.sock": rpc ошибка: код = недоступно desc = ошибка подключения: desc = "transport: ошибка при наборе номера: наберите unix /var/run/dockershim.sock: connect: нет такого файла или каталога"
WARN[0000] подключение изображения с использованием стандартных конечных точек: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. Поскольку стандартные настройки в настоящее время устарели, вы должны установить конечную точку вместо этого.
ERRO[0000] проверить подключение сервиса: проверить CRI v1 API изображения для конечной точки "unix:///var/run/dockershim.sock": rpc ошибка: код = недоступно desc = ошибка подключения: desc = "transport: ошибка при наборе номера: наберите unix /var/run/dockershim.sock: connect: нет такого файла или каталога"
CONTAINER           IMAGE               CREATED              STATE               NAME                      ATTEMPT             POD ID              POD
58dcdbbbbdb57       53b148a9d1963       Примерно минуту назад   Exited              kube-apiserver            17                  aa7a744e3afca       kube-apiserver-primary
af6057fbd0e43       a0eed15eed449       3 минуты назад        Exited              etcd                      19                  12ffe5fa72b5c       etcd-primary
a20b25ee9f45e       406945b511542       3 минуты назад        Running             kube-scheduler            5                   507b8c9d8b7ab       kube-scheduler-primary
049545de2ba82       79d451ca186a6       3 минуты назад        Running             kube-controller-manager   4                   75616efa726fd       kube-controller-manager-primary
8fbf3e41714a7       79d451ca186a6       8 минут назад        Exited              kube-controller-manager   3                   ae5e4208a01ef       kube-controller-manager-primary
4b13c766ae730       406945b511542       8 минут назад        Exited              kube-scheduler            4                   7e4f0405277e4       kube-scheduler-primary

Логи контейнеров:
Они немного запутаны, но в конце концов он продолжает выдавать одно и то же сообщение об ошибке, как будто пытается повторно и терпит неудачу

W0119 09:43:29.388741       1 logging.go:59] [основное] [Канал #1 ПодКанал #2] grpc: addrConn.createTransport не удалось подключиться к {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", }. Ошибка: ошибка подключения: desc = "transport: ошибка при наборе номера: наберите tcp 127.0.0.1:2379: connect: отклонено соединение"
W0119 09:43:30.103643       1 logging.go:59] [основное] [Канал #3 ПодКанал #4] grpc: addrConn.createTransport не удалось подключиться к {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", }. Ошибка: ошибка подключения: desc = "transport: ошибка при наборе номера: наберите tcp 127.0.0.1:2379: connect: отклонено соединение"
F0119 09:43:33.102160       1 instance.go:290] Ошибка при создании аренды: ошибка создания фабрики хранения: срок ожидания превышен
статус kubelet:
sudo systemctl status kubelet
● kubelet.service - kubelet: Агент Узла Kubernetes
     Loaded: загружено (/lib/systemd/system/kubelet.service; включено; стандартная настройка поставщика: включено)
    Drop-In: /etc/systemd/system/kubelet.service.d
             └─10-kubeadm.conf
     Active: активно (запущено) с 19 янв. 2024 г. 13:36:51 UTC; 12 минут назад
       Docs: https://kubernetes.io/docs/home/
   Main PID: 8539 (kubelet)
      Tasks: 12 (ограничение: 37581)
     Memory: 33.6M
        CPU: 19.659s
     CGroup: /system.slice/kubelet.service
             └─8539 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock --pod-infra-container-image=registry.k8s.io/p>

Jan 19 13:49:18 primary kubelet[8539]: W0119 13:49:18.366543    8539 reflector.go:535] vendor/k8s.io/client-go/informers/factory.go:150: не удалось перечислить *v1.Service: Get "https://master-node:6443/api/v1/services?limit=500&resourceVersion=0": dial tcp: поиск master-node на 127.0.0.53:53: сервер м>
Jan 19 13:49:18 primary kubelet[8539]: E0119 13:49:18.366695    8539 reflector.go:147] vendor/k8s.io/client-go/informers/factory.go:150: Не удалось отслеживать *v1.Service: не удалось перечислить *v1.Service: Get "https://master-node:6443/api/v1/services?limit=500&resourceVersion=0": dial tcp: поиск master-no>
Jan 19 13:49:19 primary kubelet[8539]: E0119 13:49:19.481598    8539 controller.go:146] "Не удалось обеспечить наличие аренды, будет повторяться" err="Get \"https://master-node:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/primary?timeout=10s\": dial tcp: поиск master-node на 127.0.0.53:>
Jan 19 13:49:19 primary kubelet[8539]: I0119 13:49:19.902400    8539 kubelet_node_status.go:70] "Попытка зарегистрировать узел" node="primary"
Jan 19 13:49:19 primary kubelet[8539]: E0119 13:49:19.904293    8539 kubelet_node_status.go:92] "Не удалось зарегистрировать узел с API сервером" err="Post \"https://master-node:6443/api/v1/nodes\": dial tcp: поиск master-node на 127.0.0.53:53: сервер плохо работает" node="primary"
Jan 19 13:49:21 primary kubelet[8539]: E0119 13:49:21.741936    8539 eviction_manager.go:258] "Менеджер выселений: не удалось получить сводную статистику" err="не удалось получить информацию об узле: узел \"primary\" не найден"
Jan 19 13:49:26 primary kubelet[8539]: E0119 13:49:26.261529    8539 event.go:289] Невозможно записать событие: '&v1.Event{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"primary.17abc31ca21e74b4", GenerateName:"", Namespace:"default", SelfLink:"", UID:"", ResourceVersion:>
Jan 19 13:49:26 primary kubelet[8539]: E0119 13:49:26.483811    8539 controller.go:146] "Не удалось обеспечить наличие аренды, будет повторяться" err="Get \"https://master-node:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/primary?timeout=10s\": dial tcp: поиск master-node на 127.0.0.53:>
Jan 19 13:49:26 primary kubelet[8539]: I0119 13:49:26.907141    8539 kubelet_node_status.go:70] "Попытка зарегистрировать узел" node="primary"
Jan 19 13:49:26 primary kubelet[8539]: E0119 13:49:26.909431    8539 kubelet_node_status.go:92] "Не удалось зарегистрировать узел с API сервером" err="Post \"https://master-node:6443/api/v1/nodes\": dial tcp: поиск master-node на 127.0.0.53:53: сервер плохо работает" node="primary"

Я бы сначала проверил, запущен ли pod apiserver, чтобы исключить проблемы на этом конце. Попробуйте ниже на узле контрольной плоскости.

Во-первых, есть ли что-то подозрительное в логах kubelet?

journalctl -fu kubelet

Затем логи контейнерного времени выполнения для pod-а.

sudo crictl ps --all  # получите container_id
sudo crictl logs container_id

Вы не включили полную команду kubeadm init, которую вы выполнили, поэтому убедитесь, что вы правильно установили --apiserver-advertise-address.

Ошибка connection refused обычно означает, что запрос достигает сервера, но на указанном порте нет работающего сервиса. Вы уверены, что api-сервер запущен на вашем мастер-узле? Чтобы проверить статус сервера kube-api, используйте следующую команду:

Systemctl status kube-apiserver
  • Поскольку файл kubeconfig расположен в \~/.kube/config, убедитесь, что установлен переменную окружения KUBECONFIG, указывающую на правильный файл.

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

  • Проверьте файервол и группы безопасности. Убедитесь, что необходимые порты для взаимодействия с API Kubernetes открыты. По умолчанию сервер API Kubernetes прослушивает порт 6443.

  • Если у вас есть подозрения на подозрительные записи в iptables, проверьте правила iptables, используя следующую команду

iptables -L -n – Вы можете искать любые правила, которые могут помешать взаимодействию с API Kubernetes. Временно сбросить правила можно с помощью команды iptables -F

  • Проверьте статус kube-proxy на мастер-узле, используя kubectl -n kube-system get pods -l k8s-app=kube-proxy.

РЕДАКТИРОВАНИЕ

Эта ошибка, вероятно, вызвана: - Kubelet не запущен - Kubelet нестабилен из-за неправильной настройки узла каким-то образом (необходимые cgroups отключены)

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

  1. Проверьте статус службы kubelet на узле, запустив следующую команду.

systemctl status kubelet – Эта команда показывает, когда kubelet не работает или нестабилен. Если kubelet не запущен, попробуйте запустить его с помощью systemctl start kubelet

  1. Проверьте конфигурацию узла, чтобы убедиться, что он правильно настроен, и проверьте, отключены ли или неправильно настроены какие-либо необходимые cgroups.

A. Если вы используете containerd в качестве cri, следуйте следующим командам
измените это SystemdCgroup = false на SystemdCgroup = true

sudo systemctl restart containerd
sudo systemctl restart kubelet

перезагрузите машину (может быть, необязательно)

B. Если вы используете docker в качестве cri, следуйте этим командам
откройте vi /etc/docker/daemon.json
измените это [“native.cgroupdriver=systemd”] на “exec-opts”: [“native.cgroupdriver=cgroupfs”],

sudo systemctl daemon-reload
sudo systemctl restart kubelet

перезагрузите машину (может быть, необязательно)

.

Ответ или решение

Проблема, с которой вы столкнулись при взаимодействии kubeadm и kubectl, связана с ошибкой "connection refused". Это распространенная ситуация при настройке Kubernetes, и для её решения требуется внимательно разобраться в конфигурации и сетевых аспектах окружения.

Теория

Сначала давайте разберемся, что такое kubeadm и kubectl и как они взаимодействуют. Kubeadm обеспечивает основные функции для развертывания кластеров Kubernetes. Он инициализирует управляющую плоскость и может добавлять узлы в кластер. Kubectl, в свою очередь, это командная утилита, которая используется для взаимодействия с кластером Kubernetes. Обе утилиты должны корректно взаимодействовать друг с другом, чтобы обеспечить полное функционирование кластера.

Ошибка "connection refused" обычно указывает на то, что запрос доходит до сервера, но на указанном порте не работает необходимая служба. В контексте Kubernetes это может означать, что kube-apiserver не запущен или не принимает соединения на ожидаемом порту (обычно 6443).

Пример

Рассмотрим сценарий, где были совершены следующие ошибки при настройке кластера:

  1. Неправильная конфигурация сети: VMs используют мостовую сеть, но iptables или брандмауэр не настроены для разрешения нужных портов.
  2. Некорректный kubeconfig: файл конфигурации Kubernetes (обычно расположен в ~/.kube/config) может быть настроен неверно, что приводит к попытке подключения к неправильному адресу или с использованием неверных сертификатов.
  3. Проблемы с kube-apiserver: служба может не запуститься из-за проблем с конфигурацией или зависимостями, таких как контейнерная среда выполнения (например, Docker или containerd).

Применение

Чтобы диагностировать и устранить проблему, следуйте предлагаемым шагам:

  1. Проверка состояния kube-apiserver: выполните команду systemctl status kube-apiserver на мастер-узле, чтобы убедиться, что служба запущена и не выдает ошибок.

  2. Проверка конфигурации: убедитесь, что все настройки сети, указанные в ~/.kube/config, соответствуют IP-адресам мастер-узла и порту 6443. Также проверьте, что сертификаты и ключи в конфигурации корректны.

  3. Сети и брандмауэр: выполните ip route show и iptables -L -n на обоих виртуальных машинах для диагностики сетевых путей и правил брандмауэра. Убедитесь, что между машинами есть сеть, и необходимые порты (например, 6443, 10250, 10255) не блокируются.

  4. Логи kubelet и контейнеров: изучите логи kubelet для поиска ошибок, используя команду journalctl -fu kubelet. Также проверьте логи контейнеров с помощью crictl ps --all и crictl logs <container_id>.

  5. Конфигурация Cgroups: в зависимости от среды выполнения контейнеров (Docker или Containerd), убедитесь, что настройки Cgroups согласованы с советами в документации Kubernetes. Например, для Containerd установите SystemdCgroup = true в конфигурации /etc/containerd/config.toml.

  6. Перезапуск службы: попробуйте перезапустить ключевые службы, такие как kubelet и containerd/Docker, с помощью команд systemctl restart kubelet и systemctl restart docker|containerd.

  7. Брандмауэр UFW: хотя он у вас отключен, удостоверьтесь, что нет других активных брандмауэров, которые могут блокировать соединения.

Подводя итог, важно уделить внимание деталям конфигурации и сетевых настроек, чтобы устранить проблему с отказом подключения между kubectl и Kubernetes API-сервером.

Оцените материал
Добавить комментарий

Капча загружается...