Я пытался создать кластер Kubernetes с помощью kubeadm. Я раскрутил сервер Ubuntu 18.04, установил докер (убедился, что docker.service запущен), установил kubeadm kubelet и kubectl.
Ниже приведены шаги, которые я сделал:
sudo apt-получить обновление
sudo apt-get установить docker.io -y
sudo systemctl включить докер
sudo systemctl запустить докер
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-ключ добавить
sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
sudo apt-get установить kubeadm kubelet kubectl -y
sudo apt-mark удерживать kubeadm kubelet kubectl
версия kubeadm
обмен âa
sudo hostnamectl set-hostname master-node
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
Однажды после того, как я побежал sudo kubeadm init --pod-network-cidr=10.244.0.0/16, я получил следующую ошибку:
root@ip-172-31-10-50:/home/ubuntu# sudo kubeadm init --pod-network-cidr=192.168.0.0/16
[init] Использование версии Kubernetes: v1.23.1
[preflight] Запуск проверки перед полетом
[preflight] Извлечение изображений, необходимых для настройки кластера Kubernetes
[предварительная проверка] Это может занять минуту или две, в зависимости от скорости вашего интернет-соединения.
[preflight] Вы также можете выполнить это действие заранее, используя «вытягивание образов конфигурации kubeadm»
[certs] Использование папки certificateDir «/etc/kubernetes/pki»
[certs] Использование существующего центра сертификации CA
[certs] Использование существующего сертификата и ключа apiserver на диске
[certs] Использование существующего сертификата и ключа apiserver-kubelet-client на диске
[certs] Использование существующего центра сертификации front-proxy-ca
[certs] Использование существующего сертификата и ключа переднего прокси-клиента на диске
[certs] Использование существующего центра сертификации etcd/ca
[certs] Использование существующего сертификата etcd/server и ключа на диске
[certs] Использование существующего сертификата etcd/peer и ключа на диске
[certs] Использование существующего сертификата и ключа etcd/healthcheck-client на диске
[certs] Использование существующего сертификата и ключа apiserver-etcd-client на диске
[сертификаты] Использование существующего ключа «sa»
[kubeconfig] Использование папки kubeconfig «/etc/kubernetes»
[kubeconfig] Использование существующего файла kubeconfig: «/etc/kubernetes/admin.conf»
[kubeconfig] Использование существующего файла kubeconfig: «/etc/kubernetes/kubelet.conf»
[kubeconfig] Использование существующего файла kubeconfig: «/etc/kubernetes/controller-manager.conf»
[kubeconfig] Использование существующего файла kubeconfig: «/etc/kubernetes/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] Создание статического манифеста пода для «kube-apiserver»
[control-plane] Создание статического манифеста пода для «kube-controller-manager»
[control-plane] Создание статического манифеста Pod для «kube-scheduler»
[etcd] Создание статического манифеста Pod для локального etcd в «/etc/kubernetes/manifests»
[wait-control-plane] Ожидание загрузки kubelet плоскости управления в виде статических подов из каталога «/etc/kubernetes/manifests». Это может занять до 4 минут
[kubelet-check] Первоначальный тайм-аут в 40 секунд пройден.
[kubelet-check] Похоже, kubelet не работает или не работает.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http://localhost:10248/healthz', завершился ошибкой: Get "http://localhost:10248/healthz": наберите tcp 127.0.0.1:10248: подключитесь : В соединении отказано.
я пытался бежать kubectl init --pod-network-cidr с использованием CIDR Фланеля (10.244.0.0/16) а также CIDR Калико (192.168.0.0/16). Однако я получил ту же ошибку.
Кроме того, я заметил, что состояние Кубелет в моем экземпляре EC2 колебался. Когда я побежал статус systemctl kubelet.service, иногда он не работал, а иногда работал Kubelet. Это происходит автоматически. Думаю, это то, что терпит неудачу кубектл инициализация с тех пор kubelet-check четко говорит: «Похоже, что kubelet не работает или не исправен»
После запуска статус systemctl kubelet.service, Ошибка:
root@ip-172-31-10-50:/home/ubuntu# статус systemctl kubelet.service
kubelet.service — kubelet: агент узла Kubernetes
Загружено: загружено (/lib/systemd/system/kubelet.service; включено; предустановка поставщика: включена)
Вставка: /etc/systemd/system/kubelet.service.d
ââ10-kubeadm.conf
Активно: активация (автоматический перезапуск) (Результат: код выхода) со среды 2021-12-29 17:52:35 UTC; 3 с назад
Документы: https://kubernetes.io/docs/home/
Процесс: 22901 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (код=выход, статус=1/FAILURE)
Основной PID: 22901 (код=выход, статус=1/ОШИБКА)
И когда я продолжаю бежать статус systemctl kubelet.service, через несколько секунд кажется, что kubectl.service работает, а через несколько секунд снова происходит сбой.
...пропуская...
kubelet.service — kubelet: агент узла Kubernetes
Загружено: загружено (/lib/systemd/system/kubelet.service; включено; предустановка поставщика: включена)
Вставка: /etc/systemd/system/kubelet.service.d
ââ10-kubeadm.conf
Активно: активно (работает) с чт 30 декабря 2021 г., 18:50:49 UTC; 125 мс назад
Документы: https://kubernetes.io/docs/home/
Основной PID: 12895 (кубелет)
Заданий: 9 (лимит: 4686)
Группа CG: /system.slice/kubelet.service
ââ12895 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf > --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib /кубелет/конф
Я не уверен, почему kubelet колеблется таким образом.
Кто-нибудь знает, как это исправить?