Вопрос или проблема
Я развернул базовый кластер на двух виртуальных машинах (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.
- Проверьте статус службы kubelet на узле, запустив следующую команду.
systemctl status kubelet
– Эта команда показывает, когда kubelet не работает или нестабилен. Если kubelet не запущен, попробуйте запустить его с помощью systemctl start kubelet
- Проверьте конфигурацию узла, чтобы убедиться, что он правильно настроен, и проверьте, отключены ли или неправильно настроены какие-либо необходимые 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).
Пример
Рассмотрим сценарий, где были совершены следующие ошибки при настройке кластера:
- Неправильная конфигурация сети: VMs используют мостовую сеть, но iptables или брандмауэр не настроены для разрешения нужных портов.
- Некорректный kubeconfig: файл конфигурации Kubernetes (обычно расположен в ~/.kube/config) может быть настроен неверно, что приводит к попытке подключения к неправильному адресу или с использованием неверных сертификатов.
- Проблемы с kube-apiserver: служба может не запуститься из-за проблем с конфигурацией или зависимостями, таких как контейнерная среда выполнения (например, Docker или containerd).
Применение
Чтобы диагностировать и устранить проблему, следуйте предлагаемым шагам:
-
Проверка состояния kube-apiserver: выполните команду
systemctl status kube-apiserver
на мастер-узле, чтобы убедиться, что служба запущена и не выдает ошибок. -
Проверка конфигурации: убедитесь, что все настройки сети, указанные в
~/.kube/config
, соответствуют IP-адресам мастер-узла и порту 6443. Также проверьте, что сертификаты и ключи в конфигурации корректны. -
Сети и брандмауэр: выполните
ip route show
иiptables -L -n
на обоих виртуальных машинах для диагностики сетевых путей и правил брандмауэра. Убедитесь, что между машинами есть сеть, и необходимые порты (например, 6443, 10250, 10255) не блокируются. -
Логи kubelet и контейнеров: изучите логи kubelet для поиска ошибок, используя команду
journalctl -fu kubelet
. Также проверьте логи контейнеров с помощьюcrictl ps --all
иcrictl logs <container_id>
. -
Конфигурация Cgroups: в зависимости от среды выполнения контейнеров (Docker или Containerd), убедитесь, что настройки Cgroups согласованы с советами в документации Kubernetes. Например, для Containerd установите
SystemdCgroup = true
в конфигурации/etc/containerd/config.toml
. -
Перезапуск службы: попробуйте перезапустить ключевые службы, такие как kubelet и containerd/Docker, с помощью команд
systemctl restart kubelet
иsystemctl restart docker|containerd
. -
Брандмауэр UFW: хотя он у вас отключен, удостоверьтесь, что нет других активных брандмауэров, которые могут блокировать соединения.
Подводя итог, важно уделить внимание деталям конфигурации и сетевых настроек, чтобы устранить проблему с отказом подключения между kubectl и Kubernetes API-сервером.