Kubeadm: Изменение главного IP-адреса

Это не ограничение kubeadm, а просто общие меры безопасности.
Сертификат подписан для {your-old-IP-here}, и безопасная связь с {your-new-ip-here} невозможна.

Вы можете заранее добавить больше IP-адресов в сертификат ...

Благодарю за ваш ответ.

Поскольку IP-адреса назначаются облачным провайдером, предварительное создание сертификата будет работать, только если я могу установить для него подстановочный знак. (Извините, я ничего не знаю о сертификатах.)

Я упустил из виду, что kubeadm reset действительно существует, поскольку он не упоминается в справочнике . Сброс и инициализация сработали для меня достаточно хорошо, и я думаю, что я не буду выключать главную машину - я полагаю, что моя проблема редка и далека от каких-либо производственных сценариев использования. Тем не менее, мне интересно, есть ли способ лучше. Думаю, я мог бы имитировать шаги kubeadm reset , но сохранить папку данных etcd, чтобы сохранить настройку кластера?

В любом случае, спасибо за всю проделанную работу над kubeadm! Волшебно видеть, как кластер появляется за считанные минуты - я использую Kubernetes с 0.14, в производстве с 1.0.

@analytik у меня точно такая же проблема, как и у вас. Моя корпоративная сеть блокирует gcr.io. Итак, я использую ключ для установки. Однако IP-адрес провайдера постоянно меняется и не находится под моим контролем. Так что даже я ищу решение. Даже если я оставлю свой ключ подключенным, иногда из-за сети сбрасывает изменения IP. Есть ли у вас какое-нибудь решение? Как ты с этим справляешься?
@luxas, не могли бы вы посоветовать, как я могу продолжить? Я новичок в K8S. Совершенно потерялся с такой конфигурацией. Не могли бы вы сообщить мне, как я могу исправить эту проблему с динамическим IP?

Как вы, ребята, справляетесь с измененным главным IP-адресом?

Есть ли обновления по этой проблеме?

Здесь та же проблема. Любая документация для продолжения модификации главного IP без сброса всего кластера, пожалуйста?

Я смог добиться этого:

• замена IP-адреса во всех конфигурационных файлах в / etc / kubernetes
• резервное копирование / etc / kubernetes / pki
• идентификация сертификатов в / etc / kubernetes / pki, которые имеют старый IP-адрес в качестве альтернативного имени [1]
• удаление сертификата и ключа для каждого из них (для меня это были просто apiserver и etcd / peer)
• регенерация сертификатов с использованием kubeadm alpha phase certs [2]
• идентификация configmap в пространстве имен kube-system которое ссылается на старый IP [3]
• редактирование этих конфигурационных карт вручную
• перезапуск kubelet и docker (для принудительного воссоздания всех контейнеров)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Вау, я не знал об этих командах. Отличная информация, которая сделала свое дело. Спасибо !

есть ли способ найти конфигурационные карты вручную и изменить их?

Я надеюсь, что kubeadm сможет осветить этот процесс в следующем выпуске.

@patricklucas серьезно, спасибо за эту

Для тех, кто ищет еще большей ясности, вот мой опыт:

1. замените IP-адрес во всех файлах конфигурации в /etc/kubernetes
bash oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. резервное копирование /etc/kubernetes/pki
bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. идентификация сертификатов в /etc/kubernetes/pki которые имеют старый IP-адрес в качестве альтернативного имени (это можно очистить)
   bash cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. определите configmap в пространстве имен kube-system которое ссылается на старый IP, отредактируйте их:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. изменить IP-адрес (через cli или gui для вашего дистрибутива)

6. удалите как сертификат, так и ключ для каждого из них, идентифицированного grep на предыдущем шаге, повторно создайте эти сертификаты

   ПРИМЕЧАНИЕ: перед воссозданием сертификатов через kubeadm admin phase certs ... вам необходимо применить новый IP-адрес.

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. перезапустить кубелет и докер
   bash sudo systemctl restart kubelet sudo systemctl restart docker
8. скопировать новую конфигурацию
   bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

еще одно замечание: изменение сертификатов было возможно в автономном режиме, указав версию k8s в файле конфигурации: https://github.com/kubernetes/kubernetes/issues/54188#issuecomment -418880831

@weisjohn Не могли бы вы также обновить свой комментарий, отметив, что:

kubectl edit cm -nkube-public cluster-info

для кубеадм тоже нужен?

В противном случае мои команды kubeadm join продолжают давать сбой из-за использования старого / неправильного IP-адреса apiserver на полпути.

Спасибо!

Я применил все шаги от @weisjohn (https://github.com/kubernetes/kubeadm/issues/338#issuecomment-418879755) и @michaelfig (https://github.com/kubernetes/kubeadm/issues/ 338 # issuecomment-428340099), чтобы заменить адрес везде.

Это позволяет кубернетам использовать вновь созданный адрес VPC на eth1 вместо общедоступного IP-адреса на eth0. Тем не менее, когда я запускаю kubeadm upgrade diff v1.12.3 он все равно хочет вернуть изменения в --advertise-address в /etc/kubernetes/manifests/kube-apiserver.yaml .

Какие-нибудь подсказки?

Даже в kubectl get all --export=true --all-namespaces -o yaml старого IP нигде нет

Обновление: оказывается, что kubeadm upgrade diff действительно предлагал изменение, но kubeadm upgrade apply самом деле вообще не изменил адрес. (одна из многих ошибок Kubernetes 1.13 вроде исправлений)

@weisjohn Спасибо за

@patricklucas серьезно, спасибо за эту

Для тех, кто ищет еще большей ясности, вот мой опыт:

1. замените IP-адрес во всех файлах конфигурации в /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. резервное копирование /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. идентификация сертификатов в /etc/kubernetes/pki которые имеют старый IP-адрес в качестве альтернативного имени (это можно очистить)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. определите configmap в пространстве имен kube-system которое ссылается на старый IP, отредактируйте их:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. изменить IP-адрес (через cli или gui для вашего дистрибутива)

6. удалите как сертификат, так и ключ для каждого из них, идентифицированного grep на предыдущем шаге, повторно создайте эти сертификаты

   ПРИМЕЧАНИЕ: перед воссозданием сертификатов через kubeadm admin phase certs ... вам необходимо применить новый IP-адрес.

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. перезапустить кубелет и докер
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. скопировать новую конфигурацию
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

Спасибо за шаги.
Можете ли вы подробнее рассказать о том, какие изменения нам нужно сделать на главном узле и после этого, какую процедуру нам нужно применить для старого рабочего узла, чтобы присоединиться к этому перенастроенному главному узлу?

Заранее спасибо :)

Возможно, стоит упомянуть, что при перемещении главного IP-адреса в частную сеть также может быть полезно обновить оверлейную сеть. Calico не использовал интерфейс VPC, пока не был привязан к этому интерфейсу:

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

kubeadm альфа-фаза сертификаты apiserver

@weisjohn kubeadm alpha phase certs apiserver не работает в v1.13.0, показывая: «Эта команда не предназначена для запуска сама по себе. См. список доступных подкоманд». есть ли обновленные комментарии?

в 1.13 команда называется kubeadm init phase certs apiserver :
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

Очень полезные шаги для исправления - спасибо @patricklucas и @weisjohn !

Один дополнительный совет, если, как и я, вы начинаете с состояния, в котором IP-адрес уже изменился, поэтому вы не можете связаться с api-сервером для изменения конфигурационных карт на шаге 4:
Сертификат api-server подписан для имени хоста kubernetes , поэтому вы можете добавить его в качестве псевдонима к новому IP-адресу в /etc/hosts затем выполнить kubectl --server=https://kubernetes:6443 ... .

@bboreham @weisjohn @patricklucas Большое спасибо за ваш опыт. Не могли бы вы посоветовать, что мне делать на рабочих узлах после изменения ip на главном узле?
Удалить / добавить в кластер? Или просто измените _ / etc / kubernetes / kubelet.conf_ и _ / etc / kubernetes / pki / ca.crt_ вручную?

Я знаю, что это старая проблема, но, возможно, мой комментарий будет кому-то полезен.
К сожалению, решение, предложенное @patricklucas и @weisjohn, у меня не сработало, поэтому я создал свое:

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

@ valerius257 спасибо, мужик, ты спасаешь наши выходные)

Спасибо @ valerius257 👍
Я перепробовал все рецензии / инструкции от @weisjohn . Они не работали для моего кластера. Хорошо то, что в этих инструкциях освещаются некоторые ключевые аспекты сертификатов и ключей, а также сроки, которые необходимо учитывать.

Инструкция, упомянутая @ valerius257, работала без проблем, пока я не столкнулся с проблемами, которые очень специфичны для моего главного узла kubeadm. Я пытался восстановить главный узел kubeadm, чей IP был изменен.

Продолжение публикации шагов, упомянутых @ valerius257
Я использовал плагин flannel n / w на одном главном узле.
Проблема с фланелью: kube-flannel-ds-xxxx не удалось перезапустить контейнер
Состояние модуля: CrashLoopBackOff. Из-за этого другие модули, такие как core-dns-xxx, также не работают.

Решение: поскольку я инициировал кластер с помощью kubeadm init с cidr n / w (когда IP был старым или во время ввода в эксплуатацию главного узла), следующий шаг стер настройки cidr из "/ etc / kubernetes / manifest / kube-controller-manager .yaml "файл.
kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd.

Следовательно, если вы инициировали главный узел kubeadm (с первым IP-адресом) с помощью команды "kubeadm init --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16" ", то разместите выделение новый IP, вы должны выполнить следующую команду с --pod-network-cidr = 10.244.0.0 / 16.
"kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd --token {{kubeadm_token}} --pod-network-cidr = 10.244.0.0 / 16"

Или измените файл "/etc/kubernetes/manifests/kube-controller-manager.yaml, включив следующие параметры, если они отсутствуют в Spec: container : command:"

• --allocate-node-cidrs = истина
• --cluster-cidr = 10.244.0.0 / 16
  
  
  
  • --node-cidr-mask-size = 24
    
    Ссылка: https://github.com/coreos/flannel/issues/728 , прочтите решение от @wkjun
    
    После внесения указанных выше изменений
    
    systemctl stop kubelet docker
    
    спать 20
    
    systemctl запускает docker kubelet
    
    Убедитесь, что все стручки включены и работают, включая фланелевые.
    
    kubect получить pods -n kube-system
  
  

Выпуск 2:
Все поды в пространстве имен приложения или в kube-системе начинают показывать ошибки в командах описания подов, например:
«Предупреждение FailedScheduling, узлы планировщика по умолчанию 0/1 доступны: 1 узел (-а) имел порчи, которые модуль не переносил».
Выполните команду: kubectl taint nodes --all node-role.kubernetes.io/master-
описать все поды, запущенные в рабочей области приложений или в пространстве имен kube-system, упомянутые ошибки не будут наблюдаться. В кластере с несколькими узлами вам, возможно, придется проявлять особую осторожность.

@patricklucas серьезно, спасибо за эту

Для тех, кто ищет еще большей ясности, вот мой опыт:

1. замените IP-адрес во всех файлах конфигурации в /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. резервное копирование /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. идентификация сертификатов в /etc/kubernetes/pki которые имеют старый IP-адрес в качестве альтернативного имени (это можно очистить)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. определите configmap в пространстве имен kube-system которое ссылается на старый IP, отредактируйте их:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. изменить IP-адрес (через cli или gui для вашего дистрибутива)

6. удалите как сертификат, так и ключ для каждого из них, идентифицированного grep на предыдущем шаге, повторно создайте эти сертификаты

   ПРИМЕЧАНИЕ: перед воссозданием сертификатов через kubeadm admin phase certs ... вам необходимо применить новый IP-адрес.

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. перезапустить кубелет и докер
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. скопировать новую конфигурацию
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

вместо newip какой ip дать?
можем ли мы создать собственный IP-адрес?

@VipinKrizz контекст этой проблемы заключается в том, что IP-адрес уже изменился из-за факторов внутри инфраструктуры. Никто не может ответить, какой IP-адрес вам следует использовать, кроме тех, кто знаком с вашей конкретной настройкой.

Может быть, вы найдете кого-нибудь, с кем можно поговорить об этом в Slack? Вопросы Kubeadm - не то место.

@ valerius257 большое спасибо за этот сценарий, теперь я вижу ряд недостатков в моем подходе. Могу подтвердить, что ваше решение сработало, однако есть много мелких граней (как и во всех k8s). Мне пришлось повторно применить все исправления к включенным службам / встроенным модулям, DNS, специальным классам хранения и т. Д.

Но да, ваш сценарий спас мне сегодня бекон.

@ valerius257 Я последовал за вашим шагом, но получаю проблему ниже

root @ ubuntu : / etc / kubernetes / pki # kubeadm init --ignore-preflight-errors = DirAvailable - var-lib-etcd
W0122 10: 15: 34.819150 102032 version.go: 101] не удалось получить версию Kubernetes из Интернета: невозможно получить URL-адрес « https://dl.k8s.io/release/stable-1.txt »: получить https: //dl.k8s.io/release/stable-1.txt : наберите tcp: lookup dl.k8s.io на 127.0.0.53:53: неправильное поведение сервера
W0122 10: 15: 34.819340 102032 version.go: 102] возврат к версии локального клиента: v1.16.3
[init] Использование версии Kubernetes: v1.16.3
[предполетная] Проведение предполетных проверок
[ПРЕДУПРЕЖДЕНИЕ IsDockerSystemdCheck]: обнаружил "cgroupfs" как драйвер контрольной группы Docker. Рекомендуемый драйвер - «systemd». Следуйте инструкциям на странице https://kubernetes.io/docs/setup/cri/.
[ПРЕДУПРЕЖДЕНИЕ DirAvailable - var-lib-etcd]: / var / lib / etcd не пуст
[предварительная проверка] Получение образов, необходимых для настройки кластера Kubernetes
[предварительная проверка] Это может занять минуту или две, в зависимости от скорости вашего интернет-соединения.
[предварительная проверка] Вы также можете выполнить это действие заранее, используя 'kubeadm config images pull'
[kubelet-start] Запись файла среды kubelet с флагами в файл "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Запись конфигурации kubelet в файл "/var/lib/kubelet/config.yaml"
[kubelet-start] Активация сервиса kubelet
[сертификаты] Использование папки certificateDir "/ etc / kubernetes / pki"
[сертификаты] Использование существующего центра сертификации CA
[certs] Создание сертификата и ключа apiserver
[certs] сертификат обслуживания apiserver подписан для имен DNS [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] и IP-адресов [10.96.0.1 192.168.120.137]
[сертификаты] Использование существующего сертификата apiserver-kubelet-client и ключа на диске
[сертификаты] Использование существующего центра сертификации front-proxy-ca
[сертификаты] Использование существующего сертификата и ключа внешнего прокси-клиента на диске
[сертификаты] Использование существующего центра сертификации etcd / ca
[сертификаты] Использование существующего сертификата etcd / server и ключа на диске
[certs] Создание сертификата и ключа etcd / peer
[certs] Сертификат обслуживания etcd / peer подписан для имен DNS [ubuntu localhost] и IP-адресов [192.168.120.137 127.0.0.1 :: 1]
[сертификаты] Использование существующего сертификата etcd / healthcheck-client и ключа на диске
[сертификаты] Использование существующего сертификата apiserver-etcd-client и ключа на диске
[сертификаты] Использование существующего ключа "sa"
[kubeconfig] Использование папки kubeconfig "/ etc / kubernetes"
[kubeconfig] Написание файла kubeconfig "admin.conf"
[kubeconfig] Запись файла kubeconfig "kubelet.conf"
[kubeconfig] Написание файла kubeconfig "controller-manager.conf"
[kubeconfig] Написание файла kubeconfig "scheduler.conf"
[control-plane] Использование папки манифеста "/ etc / kubernetes / manifestests"
[control-plane] Создание статического манифеста Pod для "kube-apiserver"
[control-plane] Создание статического манифеста Pod для «kube-controller-manager»
[control-plane] Создание статического манифеста Pod для "kube-scheduler"
[etcd] Создание статического манифеста Pod для локального etcd в "/ etc / kubernetes / manifest"
[wait-control-plane] Ожидание, пока кубелет загрузит плоскость управления как статические поды из каталога "/ etc / kubernetes / manifest". Это может занять до 4 мин. 0 сек.
[kubelet-check] Первоначальный таймаут 40 секунд истек.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http: // localhost : 10248 / healthz', завершился ошибкой: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection отказался.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http: // localhost : 10248 / healthz', завершился ошибкой: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection отказался.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http: // localhost : 10248 / healthz', завершился ошибкой: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection отказался.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http: // localhost : 10248 / healthz', завершился ошибкой: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection отказался.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http: // localhost : 10248 / healthz', завершился ошибкой: Get http: // localhost : 10248 / healthz: dial tcp 127.0.0.1:10248: connect: connection отказался.

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

Эта ошибка, вероятно, вызвана:
- Кубелет не работает
- Кубелет неисправен из-за неправильной конфигурации узла (обязательные контрольные группы отключены)

Если вы работаете в системе с питанием от systemd, вы можете попытаться устранить ошибку с помощью следующих команд:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Кроме того, компонент плоскости управления мог дать сбой или выйти из строя при запуске средой выполнения контейнера.
Для устранения неполадок перечислите все контейнеры с помощью CLI предпочитаемой среды выполнения контейнеров, например docker.
Вот один пример того, как вы можете перечислить все контейнеры Kubernetes, запущенные в докере:
- 'docker ps -a | grep kube | grep -v pause '
После того, как вы нашли отказавший контейнер, вы можете проверить его журналы с помощью:
- 'docker logs CONTAINERID'
фаза выполнения ошибки wait-control-plane: не удалось инициализировать кластер Kubernetes
Чтобы увидеть трассировку стека для этой ошибки, выполните с --v = 5 или выше

любезно помогите

Я смог добиться этого:

• замена IP-адреса во всех конфигурационных файлах в / etc / kubernetes
• резервное копирование / etc / kubernetes / pki
• идентификация сертификатов в / etc / kubernetes / pki, которые имеют старый IP-адрес в качестве альтернативного имени [1]
• удаление сертификата и ключа для каждого из них (для меня это были просто apiserver и etcd / peer)
• регенерация сертификатов с использованием kubeadm alpha phase certs [2]
• идентификация configmap в пространстве имен kube-system которое ссылается на старый IP [3]
• редактирование этих конфигурационных карт вручную
• перезапуск kubelet и docker (для принудительного воссоздания всех контейнеров)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

У меня сработало спасибо

Единственное, что вам нужно использовать

 kubeadm init phase ..

Для последних версий kubectl

@bboreham
Я выполнил шаги, упомянутые @patricklucas
как вы упомянули в шаге 4, необходимо выполнить некоторую конфигурацию в / etc / hosts, потому что IP-адрес уже изменился и не может подключиться к api-серверу.

Создать сертификат с помощью
kubeadm init --kubernetes-version = v1.16.3 фазовые сертификаты apiserver

я поменял в / etc / hosts

и попробовал kubectl --server = https: //: 6443 все еще не работает :(

какую-то конкретную конфигурацию нужно делать в / etc / hosts ??