Kubeadm 1.24 с containerd. Kubeadm init не удался (centos 7)

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

Я пытаюсь установить кластер с одним узлом на CentOS 7, с kubeadm 1.24 и containerd, я следовал инструкциям по установке,

и я выполнил:

containerd config default > /etc/containerd/config.toml

и добавил: SystemdCgroup = true

но команда kubeadm init завершилась неудачно на этапе :

[root@master-node .kube]# kubeadm init
[init] Используемая версия Kubernetes: v1.24.0
[preflight] Запуск предварительных проверок
        [WARNING HTTPProxy]: Соединение с "https://10.XXXXXXXX" использует прокси "http://proxy-XXXXXXXXX.com:8080/". Если это не намеренно, отрегулируйте настройки прокси
        [WARNING HTTPProxyCIDR]: соединение с "10.96.XXXXXXXX" использует прокси "http://proxy-XXXXXXXXX.com:8080/". Это может привести к проблемам с настройкой кластера. Убедитесь, что диапазоны IP для Pod и Services указаны правильно как исключения в настройках прокси
[preflight] Загрузка изображений, необходимых для настройки кластера Kubernetes
[preflight] Это может занять одну-две минуты, в зависимости от скорости вашего интернет-соединения
[preflight] Вы также можете выполнить это действие заранее, используя 'kubeadm config images pull'
[certs] Использование папки certificateDir "/etc/kubernetes/pki"
[certs] Генерация сертификата и ключа "ca"
[certs] Генерация сертификата и ключа "apiserver"
[certs] сертификат для сервиса apiserver подписан для DNS имен [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master-node] и IP [10.96.0.1 10.XXXXXXXX]
[certs] Генерация сертификата и ключа "apiserver-kubelet-client"
[certs] Генерация сертификата и ключа "front-proxy-ca"
[certs] Генерация сертификата и ключа "front-proxy-client"
[certs] Генерация сертификата и ключа "etcd/ca"
[certs] Генерация сертификата и ключа "etcd/server"
[certs] сертификат для сервиса etcd/server подписан для DNS имен [localhost master-node] и IP [10.XXXXXX 127.0.0.1 ::1]
[certs] Генерация сертификата и ключа "etcd/peer"
[certs] сертификат для сервиса etcd/peer подписан для DNS имен [localhost master-node] и IP [10.XXXXXXX 127.0.0.1 ::1]
[certs] Генерация сертификата и ключа "etcd/healthcheck-client"
[certs] Генерация сертификата и ключа "apiserver-etcd-client"
[certs] Генерация ключа и публичного ключа "sa"
[kubeconfig] Использование папки kubeconfig "/etc/kubernetes"
[kubeconfig] Запись файла kubeconfig "admin.conf"
[kubeconfig] Запись файла kubeconfig "kubelet.conf"
[kubeconfig] Запись файла kubeconfig "controller-manager.conf"
[kubeconfig] Запись файла kubeconfig "scheduler.conf"
[kubelet-start] Запись файла окружения kubelet с флагами в файл "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Запись конфигурации kubelet в файл "/var/lib/kubelet/config.yaml"
[kubelet-start] Запуск kubelet
[control-plane] Использование папки манифестов "/etc/kubernetes/manifests"
[control-plane] Создание статического манифеста Pod для "kube-apiserver"
[control-plane] Создание статического манифеста Pod для "kube-controller-manager"
[control-plane] Создание статического манифеста Pod для "kube-scheduler"
[etcd] Создание статического манифеста Pod для локального etcd в "/etc/kubernetes/manifests"
[wait-control-plane] Ожидание загрузки kubelet для управления контрольной плоскостью в виде статических Pods из директории "/etc/kubernetes/manifests". Это может занять до 4m0s
Ожидание загрузки kubelet для управления контрольной плоскостью в виде статических Pods из директории "/etc/kubernetes/manifests". Это может занять до 4m0s
[kubelet-check] Начальное время ожидания 40s истекло.

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

Эта ошибка, вероятно, вызвана:
        - 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 или выше

systemctl status kubelet: активен: работает

и логи: journalctl -xeu kubelet:

mai 20 17:07:05 master-node kubelet[8685]: E0520 17:07:05.715751    8685 kubelet.go:2344] "Сеть контейнерной среды выполнения не готова" networkReady="NetworkReady=false reason...
mai 20 17:07:05 master-node kubelet[8685]: E0520 17:07:05.809523    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:05 master-node kubelet[8685]: E0520 17:07:05.910121    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.010996    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.111729    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.185461    8685 controller.go:144] не удалось удостовериться в существовании аренды, повторная попытка через 7s, ошибка: Получить "https://10.3...
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.212834    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.313367    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.413857    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: I0520 17:07:06.433963    8685 kubelet_node_status.go:70] "Попытка зарегистрировать узел" node="master-node"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.434313    8685 kubelet_node_status.go:92] "Не удалось зарегистрировать узел с API сервером" err="Post \"https://10....
mai 20 17:07:06 master-node kubelet[8685]: W0520 17:07:06.451759    8685 reflector.go:324] vendor/k8s.io/client-go/informers/factory.go:134: не удалось перечислить *v1.CSIDr
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.451831    8685 reflector.go:138] vendor/k8s.io/client-go/informers/factory.go:134: Не удалось следить за *v1.CSID
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.514443    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.573293    8685 remote_runtime.go:201] "Запуск PodSandbox из службы времени выполнения не удался" err="rpc ошибка: код = Un...
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.573328    8685 kuberuntime_sandbox.go:70] "Не удалось создать песочницу для pod" err="rpc ошибка: код = Неизвестно
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.573353    8685 kuberuntime_manager.go:815] "CreatePodSandbox для pod не удалась" err="rpc ошибка: код = Неизвестно
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.573412    8685 pod_workers.go:951] "Ошибка синхронизации pod, пропускаем" err="не удалось \"CreatePodSandbox\" для \"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.574220    8685 remote_runtime.go:201] "Запуск PodSandbox из службы времени выполнения не удался" err="rpc ошибка: код = Un...
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.574254    8685 kuberuntime_sandbox.go:70] "Не удалось создать песочницу для pod" err="rpc ошибка: код = Неизвестно
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.574279    8685 kuberuntime_manager.go:815] "CreatePodSandbox для pod не удалась" err="rpc ошибка: код = Неизвестно
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.574321    8685 pod_workers.go:951] "Ошибка синхронизации pod, пропускаем" err="не удалось \"CreatePodSandbox\" для \"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.615512    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.716168    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"
mai 20 17:07:06 master-node kubelet[8685]: E0520 17:07:06.816764    8685 kubelet.go:2419] "Ошибка получения узла" err="узел \"master-node\" не найден"

И в /var/log/message: много:

May 22 12:50:00 master-node kubelet: E0522 12:50:00.616324   18961 kubelet.go:2344] "Сеть контейнерной среды выполнения не готова" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"

и

[root@master-node .kube]# systemctl status containerd

● containerd.service - контейнерное время выполнения containerd
   Загружен: загружен (/usr/lib/systemd/system/containerd.service; включен; предустановка: отключена)
  Drop-In: /etc/systemd/system/containerd.service.d
           └─http_proxy.conf
   Активен: активен (работает) с вск. 2022-05-22 12:28:59 CEST; 22 мин. назад
     Документы: https://containerd.io
 Основной PID: 18416 (containerd)
    Задачи: 111
   Память: 414.6M
   CGroup: /system.slice/containerd.service
           ├─18416 /usr/bin/containerd
           └─(другие строки упущены)...

mai 22 12:45:56 master-node containerd[18416]: time=”2022-05-22T12:45:56.146209618+02:00″ уровень=info msg=”StartContainer for \”231b0ecd5ad9e49e2276770f23…9fa23e\””

[root@master-node .kube]# systemctl status kubelet

● kubelet.service - kubelet: Агент узла Kubernetes
   Загружен: загружен (/usr/lib/systemd/system/kubelet.service; включен; предустановка: отключена)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Активен: активен (работает) с вск. 2022-05-22 12:45:55 CEST; 6 мин. назад
     Документы: https://kubernetes.io/docs/
 Основной PID: 18961 (kubelet)
    Задачи: 16
   Память: 44.2M
   CGroup: /system.slice/kubelet.service
           └─18961 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kube...

mai 22 12:51:25 master-node kubelet[18961]: E0522 12:51:25.632732   18961 kubelet.go:2344] "Сеть контейнерной среды выполнения не готова" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"
mai 22 12:51:30 master-node kubelet[18961]: E0522 12:51:30.633996   18961 kubelet.go:2344] "Сеть контейнерной среды выполнения не готова" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"
```

и

[root@master-node yum.repos.d]# rpm -qa|grep containerd
containerd.io-1.6.4-3.1.el7.x86_64

[root@master-node yum.repos.d]# rpm -qa |grep kube
kubeadm-1.24.0-0.x86_64
kubectl-1.24.0-0.x86_64
kubelet-1.24.0-0.x86_64
kubernetes-cni-0.8.7-0.x86_64

Также я пытался установить Calico:

[root@master-node .kube]# kubectl apply -f calico.yaml
Соединение с сервером localhost:8080 было отказано - вы указали правильный хост или порт?

и

[root@master-node ~]# cat /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

# Примечание: этот drop-in работает только с kubeadm и kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
Environment="KUBELET_KUBEADM_ARGS=--node-ip=10.XXXXXX --container-runtime=remote --container-runtime-endpoint=/run/containerd/containerd.sock --cgroup-driver=systemd
# Это файл, который "kubeadm init" и "kubeadm join" создают во время выполнения, заполняя переменную KUBELET_KUBEADM_ARGS динамически
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# Это файл, который пользователь может использовать для переопределений аргументов kubelet в качестве последнего средства. Предпочтительно, чтобы пользователь использовал
# объект .NodeRegistration.KubeletExtraArgs в конфигурационных файлах. KUBELET_EXTRA_ARGS должны загружаться из этого файла.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

Я не могу понять, если:

[редактировать: я отвечаю на свои вопросы ниже]

  • из-за containerd, мне нужно запустить kubeadm init --config.yaml? ответ: => [НЕТ]
  • если я должен сначала установить CNI, такой как Calico? ответ: => [НЕТ, kubeadm init может быть выполнен без него]

[редактировать] та же установка работает с google dns и без корпоративного прокси.

Убедитесь, что containerd работает перед запуском kubeadm. Если у вас есть nerdctl, попробуйте:

nerdctl run -it --rm gcr.io/google-samples/env-show:1.1

Проблемы? Возможно, интеграция CRI не настроена. Попробуйте:

containerd config default > /etc/containerd/config.toml 
systemctl restart containerd

Это должно помочь вам разобраться, но вам может потребоваться предоставить больше информации для отладки.

Я следовал этим шагам:
https://computingforgeeks.com/install-kubernetes-cluster-on-centos-with-kubeadm/
успешно на домашнем компьютере с той же ОС :

  • виртуальная машина с минимальной CentOS 7,
  • с containerd,
  • kubeadm 1.24.
    единственные отличия - отсутствие корпоративного прокси, отсутствие корпоративного DNS, так что я предполагаю, что проблема связана с прокси и DNS.

kubeadm init прошел успешно, и главный узел работает

единственная адаптация, которую я сделал, была в файле: /etc/yum.repos.d/kubernetes.repo
чтобы установить это на 0 = "repo_gpgcheck=0"

Теперь мне нужно выяснить, почему это не работает с корпоративным прокси.

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

Kubeadm 1.24 с containerd: Решение проблем на CentOS 7

Установка и настройка Kubernetes на CentOS 7 с использованием kubeadm 1.24 и containerd может вызвать несколько распространенных проблем, особенно в условиях, когда используется корпоративный прокси-сервер. В данной статье мы рассмотрим основные шаги, которые помогут вам устранить неполадки и успешно выполнить команду kubeadm init.

1. Предварительные условия

Перед тем как запустить kubeadm init, убедитесь, что у вас установлены все необходимые компоненты, такие как docker, containerd, kubeadm, kubectl и kubelet. Также убедитесь, что версии всех компонентов совместимы. Вы можете проверить установленные версии, используя команды:

rpm -qa | grep kube
rpm -qa | grep containerd

2. Настройка containerd

Ваша команда containerd config default > /etc/containerd/config.toml создаёт шаблон конфигурации, и вы правильно устанавливали значение SystemdCgroup = true. После внесения изменений обязательно перезапустите containerd:

systemctl restart containerd

Чтобы проверить, работает ли containerd корректно, вы можете запустить тестовый контейнер:

nerdctl run -it --rm gcr.io/google-samples/env-show:1.1

3. Конфигурация проксирования

На основании ваших логов, система использует прокси для подключения к API серверу. Это может привести к ошибкам при инициализации кластера. Важно убедиться, что адреса вашего кластера окружены в исключения для прокси.

Перейдите к настройке прокси. Проверьте файл /etc/systemd/system/kubelet.service.d/http_proxy.conf и убедитесь, что ваши диапазоны IP (например, 10.96.0.0/12 для сервисов Kubernetes) включены в список исключений прокси. Также проверьте, добавлены ли адреса вашего кластера:

export NO_PROXY=localhost,127.0.0.1,10.32.0.0/12,10.96.0.0/12,<IP вашего master узла>

4. Проверка kubelet

Если команда kubeadm init завершается с ошибкой "timed out waiting for the condition", это может указывать на то, что kubelet не работает должным образом. Используйте следующие команды для диагностики состояния kubelet:

systemctl status kubelet
journalctl -xeu kubelet

Если kubelet работает, но выдаёт ошибки "Container runtime network not ready", ваши проблемы могут быть связаны с неправильной настройкой сетевого плагина. Убедитесь, что вы не пытаетесь установить CNI, как Calico, до завершения инициализации кластера.

5. Установка CNI

Установка сетевого плагина не требуется до завершения kubeadm init. После успешной инициализации кластера вы сможете установить CNI, выполнив команду:

kubectl apply -f <путь к вашему cni.yaml>

6. Итоговая проверка

После устранения всех полученных выше проблем, попробуйте снова запустить kubeadm init. Если всё делает правильно, вы должны увидеть сообщение об успешной инициализации кластера.

Заключение

Реализация Kubernetes кластера на CentOS 7 может быть сложной задачей, особенно в условиях использования корпоративного прокси. Придерживайтесь представленных рекомендаций, и вам удастся успешно провести настройку. Если проблемы продолжаются, собирайте журналы и проверяйте каждую настройку снова. Удачи в работе с Kubernetes!

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

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