GitLab CI в частном кластере GKE не может подключиться к мастеру
До сих пор мы использовали публичный кластер GKE для всех наших рабочих нагрузок. Мы создали второй частный кластер (все еще GKE) с улучшенной безопасностью и доступностью (старый - это одна зона, новый - региональный кластер). Мы используем Gitlab.com для нашего кода, но в кластерах используем Gitlab CI, размещенный самостоятельно.
На общедоступном кластере бегун работает нормально, все рабочие нагрузки завершены успешно. Однако в частном кластере все команды kubectl thr CI терпят неудачу с Unable to connect to the server: dial tcp <IP>:443: i/o timeout error, Конфигурация CI не изменилась - тот же базовый образ, все еще использующий gcloud SDK с учетной записью службы CI для аутентификации в кластере.
В обоих кластерах разрешены главные авторизованные сети и настроены только наши офисные IP-адреса. Мастер доступен с публичного IP. Аутентификация прошла успешно, сертификат клиента и базовая аутентификация отключены на обоих. Облачный NAT настроен, узлы имеют доступ к Интернету (может получать изображения контейнеров, Gitlab CI может подключаться и т. Д.).
Я что-то пропустил? На что еще я должен смотреть?
3 ответа
Я нашел решение своей проблемы, но я не совсем уверен в причине.
я использовал gcloud container clusters get-credentials [CLUSTER_NAME], который дал публичную конечную точку мастера. Однако это недоступно изнутри кластера по какой-то причине - поэтому я предполагаю, что для этого потребуется добавить общедоступный IP-адрес NAT (который не предоставляется статически) в авторизованные сети.
Я добавил флаг --internal-ip, который дал внутренний IP-адрес кластера. CI теперь может подключиться к мастеру.
Источник: https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl
тл; др - gcloud container clusters get-credentials --internal-ip [CLUSTER_NAME]
Если это gitlab.com, вы можете занести его диапазон IP в белый список в авторизованных сетях Master на GKE,
Вы можете установить GitLab runner внутри вашего частного кластера GKE, и каждый раз, когда конвейер должен запускать модуль, он будет запускаться из GitLab runner, который вы настроили и удалили после выполнения задания.