Блог

Я обновляю тестовый кластер в GKE, и изначально у меня возникли проблемы с созданием пула узлов, при этом в одном из пулов появился красный восклицательный знак. Обновления как этого пула, так и, казалось бы, исправного другого пула с 1.15 продолжали завершаться неудачей, поэтому я удалил оба пула и создал новые.

К сожалению, созданные узлы никогда не добавляются в пул. После просмотра в вычислительном ядре компьютеров это выглядит как проблема с конфигурацией сети. Мост cbr0 никогда не создается, как и устройства veth, что приводит к отсутствию подключения к Интернету, что, по-видимому, является причиной того, что настройка узла Kubernetes не завершена.

Я также обнаружил, что вывод :

 kubectl get pods --all-namespaces
  

не показывает модуль kube-proxy, как это происходит в рабочем кластере.

Кто-нибудь сталкивался с этим раньше и как это можно исправить? У меня практически идентичный кластер работает нормально, все создается из графического интерфейса с настройками по умолчанию, и в обоих добавлена сеть VPC (VPN включен, проблем не наблюдается).

Я наткнулся на: https://github.com/kubernetes/kubernetes/issues/21401 и проверил :

  /var/lib/docker/network/files/local-kv.db
  

Он не содержал cbr0, и его удаление и перезапуск демона Docker ничего не изменили.

У меня есть еще один кластер в том же проекте, который работает без проблем. Похоже, что причиной проблемы может быть мастер, управляемый Google, но я понятия не имею, как приступить к дальнейшему устранению неполадок. Любая помощь приветствуется, спасибо.

[обновление] Другие тесты:

• создайте новый кластер в том же проекте с сетью по умолчанию — без проблем
• создайте новый кластер в том же проекте с сетью VPC — та же проблема

вывод ip a на узле, который «застрял»: ip a

 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
    link/ether 42:01:0a:30:0f:eb brd ff:ff:ff:ff:ff:ff
    inet 10.48.15.235/32 scope global dynamic eth0
       valid_lft 2323sec preferred_lft 2323sec
    inet6 fe80::4001:aff:fe30:feb/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:2d:e7:41:51 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
  

команда /usr/bin/toolbox не работает (ответ об ошибке от daemon: Get https://gcr.io/v2 /: net/http: запрос отменен во время ожидания подключения (Клиент.Превышен тайм-аут при ожидании заголовков)), поэтому дальнейшее устранение неполадок затруднено (используется ОС CoreOS).

Похоже, это вызвано пользовательской сетью. Я ожидаю, что, учитывая, что это общедоступный кластер, сеть должна быть настроена для подключения к Интернету. Интересно, это ошибка или неправильная настройка. Кто-нибудь знает, должна ли установка создавать cbr0 и другие интерфейсы независимо? Я все еще продолжаю расследование…

Итак, создание нового кластера в конце показывает:

Сведения о состоянии Все ресурсы кластера были подняты, но: зарегистрировано только 0 узлов из 3; вероятно, это связано с тем, что узлы не запускаются правильно; попробуйте заново создать кластер или обратитесь в службу поддержки, если это не сработает. У меня нет коммерческой поддержки, поэтому, если из этого ничего не выйдет, я могу использовать общедоступный баг-трекер.

Проблема решена. Сначала я обнаружил, что это, похоже, проблема с DNS, поэтому при добавлении, например, 8.8.8.8 в /etc/resolv.conf, интернет-маршрутизация сработала. По какой-то причине вскоре после того, как пул узлов внезапно начал работать и отображаться в графическом интерфейсе. После проверки компьютеров узла сетевые интерфейсы были там, и это также работает при масштабировании компьютеров в пуле узлов.

Неясно, вызвано ли это моим единственным действием или возникла проблема в среде Google Kubernetes, я действительно подозреваю последнее. Спасибо всем за помощь, на данный момент эта проблема решена.