Вопрос или проблема
Кластер Kubernetes работал нормально ранее. Начались проблемы с выполнением команд kubectl после перезагрузки мастер-узла (1.0.0.0). При выполнении команды kubectl get nodes я получаю следующую ошибку.
# kubectl get nodes
The connection to the server 1.0.0.0:6443 was refused - did you specify the right host or port?
При подключении к мастер-узлу (1.0.0.0) порт 6443 не открыт для приёма соединений. netstat -lntp|grep 6443 не даёт никакого вывода. Сервис kubelet в рабочем состоянии, вывод systemctl status kubelet не показывает ничего подозрительного.
Попробовал перезапустить сервис kubelet, но безуспешно. Также пробовал swapoff -a перед перезапуском сервиса kubelet.
Я упускаю какой-то другой сервис, который принимает соединения на порту 6443, или это работа kubelet, но он не выполняет её? Пожалуйста, помогите.
Примечание: IP-адрес замаскирован как 1.0.0.0, фактический IP отличается. Везде используется только Centos.
Проверьте возможные решения ниже:
Сначала просмотрите журналы вывода journalctl -xeu kubelet, проверьте, если error while dialing dial unix /var/run/cri-dockerd.sock: connect: no such file or directory, затем перезапустите и включите cri-dockerd службы как показано ниже:
sudo systemctl enable cri-dockerd.service
sudo systemctl restart cri-dockerd.service then
sudo systemctl start kubelet
Это может сработать, пожалуйста, пройдите по ссылке на github для получения дополнительной информации.
1) Переменная окружения Kubeconfig, вероятно, не установлена. export KUBECONFIG=/etc/kubernetes/admin.conf или $HOME/.kube/config
2) В домашнем каталоге пользователя нет файла .kube/config. Если у вас нет .kube или файла config
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf HOME/.kube/config sudo chown $(id -u):$(id -g)
$HOME/.kube/config
Также вы можете экспортировать переменную KUBECONFIG таким образом:
export KUBECONFIG=$HOME/.kube/config
3) Сервер/порт, указанный в конфигурационном файле выше, неверен. Совпадает ли он с IP/именем хоста мастер-сервера? если нет, скопировали вы его? Возможно, стоит это исправить.
Вы можете получить имя хоста, выполнив команду hostname в вашей командной строке. или ifconfig для IP.
4) Сервис Docker может быть отключен, поэтому pod kubeapi не работает
sudo systemctl start docker
sudo systemctl start kubelet
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):(id -g) $HOME/.kube/config
5) Сервис kubelet может быть отключен. Это может быть связано с тем, что swap включен:
- sudo -i
- swapoff -a
- exit
- strace -eopenat kubectl version
и вы можете снова ввести kubectl get nodes, как показано ниже.
6) Может быть другая причина ‘недостаточно места на диске’:
Проверьте “df -h”, нет overlay или shm (монтированы на /var/lib/docker…), пока вы не увеличите свободное место на диске.
7) Следуйте приведенному ниже подобному процессу для решения вашей проблемы
мастер
kubeadm reset kubeadm init –pod-network-cidr=192.168.0.0/16 –apiserver-advertise-address=192.168.211.40 — kubernetes-version=v1.18.0
kubeadm join 192.168.211.40:6443 --token s7apx1.mlxn2jkid6n99fr0 \
--discovery-token-ca-cert-hash sha256:2fa9da39110d02efaf4f8781aa50dd25cce9be524618dc7ab91a53e81c5c22f8
$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
node1
$ kubeadm reset
$ kubeadm join 192.168.211.40:6443 --token s7apx1.mlxn2jkid6n99fr0 \
--discovery-token-ca-cert-hash sha256:2fa9da39110d02efaf4f8781aa50dd25cce9be524618dc7ab91a53e81c5c22f8
node2
$ kubeadm reset
$ kubeadm join 192.168.211.40:6443 --token s7apx1.mlxn2jkid6n99fr0 \
--discovery-token-ca-cert-hash sha256:2fa9da39110d02efaf4f8781aa50dd25cce9be524618dc7ab91a53e81c5c22f8
мастер
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
master Ready master 5m18s v1.18.6
node1 Ready <none> 81s v1.18.6
node2 Ready <none> 43s v1.18.6
$ scp /root/.kube/config [email protected]:/root/.kube/config
$ scp /root/.kube/config [email protected]:/root/.kube/config
8) Пожалуйста, попробуйте это, если у вас все еще есть проблема:
iptables может вызвать проблемы после перезагрузки вашей инстанции.
sudo su
iptables -P INPUT ACCEPT ALL
iptables -F
Также обратитесь к этому документу, в котором описываются шаги для устранения ошибки kubectl для получения дополнительной информации.
Также проверьте это подобное SO для получения дополнительной информации.
попробуйте sudo nano /etc/containerd/config.toml Затем найдите SystemdCgroup и измените его значение с false на true
sudo systemctl restart containerd;sudo reboot Проверьте подробности: https://gjhenrique.com/cgroups-k8s/ https://discuss.kubernetes.io/t/why-does-etcd-fail-with-debian-bullseye-kernel/19696
.
Ответ или решение
Когда Kubernetes-кластер, который ранее работал исправно, начинает выдавать ошибку "connection to the server refused", несмотря на то, что Kubelet находится в состоянии "running", это может указывать на несколько потенциальных проблем. Давайте рассмотрим, что может вызвать такие сбои и как их исправить.
Факторы и решения
Фактор 1: Неверные настройки Kubeconfig
Первым делом, проверьте, правильно ли установлена переменная окружения KUBECONFIG. Она должна вести к файлу admin.conf на мастер-узле:
export KUBECONFIG=/etc/kubernetes/admin.confЕсли у вас отсутствует файл .kube/config в домашнем каталоге, создайте его следующим образом:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/configФактор 2: Проблемы с kube-apiserver
Если при проверке порта 6443 с помощью netstat вы не видите его в списке, это может указывать на то, что kube-apiserver не запущен. Проверьте состояние компонентов Kubernetes на мастер-узле:
sudo systemctl status kube-apiserverЕсли сервис не запущен, попробуйте его перезапустить:
sudo systemctl restart kube-apiserverФактор 3: Docker или Containerd
Убедитесь, что Docker или Containerd работает корректно, так как они необходимы для запуска Kubernetes:
sudo systemctl status docker
sudo systemctl restart dockerЕсли вы используете Containerd, проверьте следующий файл:
sudo nano /etc/containerd/config.tomlУбедитесь, что параметр SystemdCgroup установлен в true и перезапустите Containerd:
SystemdCgroup = true
sudo systemctl restart containerd
sudo rebootФактор 4: Проблемы с iptables
После перезагрузки возможно возникновение проблем с iptables, что может блокировать соединение по порту 6443:
sudo iptables -P INPUT ACCEPT
sudo iptables -FФактор 5: Перезапуск Kubectl и Kubelet
После выполнения вышеизложенных шагов, выполните перезапуск kubectl и kubelet для гарантии:
sudo systemctl restart kubeletФактор 6: Проверка дискового пространства
Недостаток дискового пространства может вызвать сбои в работе Kubernetes. Проверьте его с помощью:
df -hЕсли свободного места недостаточно, увеличьте его.
Завершение
После выполнения всех этапов проверьте снова через:
kubectl get nodesЕсли проблема не была решена, возможно потребуется перепроверить процедуру инициирования kubeadm или обратиться к документации и сообществам Kubernetes для получения более детализированной информации.
Эти шаги должны помочь в выявлении и устранении проблемы с отказом соединения на порту 6443, что повысит стабильность и работоспособность вашего Kubernetes-кластера.