Kubernetes - ошибка загрузки crisocket: время ожидания ожидания истекло

Question

Я пытаюсь создать шаблон для кластера Kubernetes, имеющего 1 мастер и 2 рабочих узла.Я установил все программное обеспечение pre-req и запустил инициализацию kubeadmn на своем главном узле.Но когда я пытаюсь запустить соединение kubeadmn, которое я получаю как вывод команды init, я получаю сообщение об ошибке.

[discovery] Попытка подключения к серверу API "10.31.2.33:6443" [discovery] Создан клиент обнаружения информации о кластере, запрашивающий информацию у "https://10.31.2.33:6443" [discovery] Запрос информацииот "https://10.31.2.33:6443" еще раз для проверки TLS по закрепленному общедоступному ключу [обнаружение] Подпись и содержимое информации кластера действительны, а сертификат TLS проверяется по привязанным корням, будет использовать API-сервер" 10.31.2.33:6443 "[обнаружение] Успешноустановлено соединение с API-сервером «10.31.2.33:6443» [kubelet] Загрузка конфигурации для kubelet из ConfigMap «kubelet-config-1.12» в пространстве имен системы kube [kubelet] Запись конфигурации kubelet в файл "/ var / lib /kubelet / config.yaml "[kubelet] Запись файла среды kubelet с флагами в файл" /var/lib/kubelet/kubeadm-flags.env "[preflight] Активация службы kubelet [tlsbootstrap] Ожидание, пока kubelet выполнит загрузочную TLS-загрузку... [patchnode] Загрузка информации о сокете CRI "/var/run/dockershim.sock" в узел AОбъект PI "" в виде ошибки аннотации при загрузке crisocket: истекло время ожидания условия

Я выполнил замену -a перед запуском этого на workdernode2

Мне удалось запуститьобъединение один раз, но после этого, как часть скрипта, я запустил сброс kubeadmn, а затем инициализировать и соединиться несколько раз, когда это начало появляться.

Не могу понять, что или где я делаю ошибку.

Моим основным намерением является поместить все команды в форме сценария оболочки (на мастер-узле), чтобы его можно было запустить в кластере для создания сети.

Answer 1

У меня возникла следующая проблема после перезагрузки узла:

[kubelet] Creating a ConfigMap "kubelet-config-1.13" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8smaster" as an annotation
[kubelet-check] Initial timeout of 40s passed.
error execution phase upload-config/kubelet: Error writing Crisocket information for the control-plane node: timed out waiting for the condition

Действия по устранению этой проблемы:

1. Проверьте имя хоста еще раз, после перезагрузки он можетизменились.

sudo vi /etc/hostname sudo vi /etc/hosts

Выполните следующие действия по очистке

Код:

sudo kubeadm reset
rm -rf /var/lib/cni/
sudo rm -rf /var/lib/cni/

systemctl daemon-reload

systemctl restart kubelet

sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X

Выполнить действие init со специальным тегом, как показано ниже

Код

sudo kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=10.10.10.2 --ignore-preflight-errors=all    

(где 10.10.10.2 - это IP главного узла, а 192.168.0.0/16 - эточастная подсеть, назначенная для Pods)

Answer 2

У меня была такая же проблема в Ubuntu 16.04 amd64, исправлена ​​с помощью этих команд:

swapoff -a    # will turn off the swap 
kubeadm reset
systemctl daemon-reload
systemctl restart kubelet
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X  # will reset iptables

Также посмотрите на эту проблему в GubeHub своп kubeadm по связанной проблеме где люди все еще сообщают о наличии проблемы после выключения свопа.

Вы также можете попробовать добавить - fail-swap-on = false флаг в файл / etc / default / kubelet, однако в моем случае это не помогло.

Кажется, это исправлено в последней версии k8, потому что после обновления кластера я не испытывал этого.