Gitlab Runner не может получить доступ к собственному экземпляру Gitlab

Question

У нас есть собственная установка Gitlab Enterprise на экземпляр Google Compute Engine. Этот экземпляр защищен брандмауэром, поэтому только наши сотрудники могут получить доступ к серверу.

Когда мы развертываем кластер Kubernetes (используя Gitlab CI), бегуны не могут получить доступ к GitLab и, следовательно, не будут запускать задания CI.

Я могу вручную добавить внешний IP-адрес экземпляра Google Kubernetes в наш брандмауэр GitLab (брандмауэр GCP, разрешающий все протоколы и порты для выбранных диапазонов IP-адресов), и тогда он будет работать. Но поскольку у нас меняется количество экземпляров Kubernetes (а также экземпляров с большим количеством символов), мы должны делать это каждый день вручную.

Это не оптимальная ситуация. Я уже пытался добавить внутренние диапазоны IP (10.132.0.0/20, 10.0.0.0/8, 10.56.0.0/14), но это не было решением. Бегуны все еще не могут добраться до сервера gitlab, не указав точный IP-адрес экземпляра.

Чего мне не хватает?

Answer 1

Узлы GKE отображаются в виде экземпляров виртуальных машин на платформе GCE. Они управляются главным узлом и могут быть удалены (контроллером куба), если они считаются нездоровыми. После удаления они воссоздаются. По этой причине IP-адреса эфемерны. Будет довольно сложно использовать внешний IP-адрес каждого экземпляра виртуальной машины, так как IP-адреса все время меняются. Это нереальное решение.

Один из способов - использовать NAT Gateway . Весь исходящий трафик от узлов GKE будет перенаправлен на конкретный экземпляр виртуальной машины, который будет действовать как шлюз NAT. Тогда у вас будет только 1 статический IP-адрес, который является внешним IP-адресом NAT Gateway .

Тогда у вас будет один статический IP-адрес, который вы можете добавить к правилу брандмауэра.