Мы строим новый кластер Kubernetes в GCP, используя Shared VPC. Кластер был создан с включенным VPC-native (то есть псевдонимом IP). В общем, в общем VPC вроде все в порядке. IP-адреса узла, модуля и службы соответствуют ожидаемым от общего VPC. У меня даже есть одна служба на внутреннем балансировщике нагрузки в подсети Shared VPC, которая отлично работает.
Но когда я запускаю простейшие тесты для внешней службы
kubectl create deployment hello-web --image=nginxdemos/hello
kubectl expose deployment hello-web --type=LoadBalancer --port 80 --target-port 80
kubectl get service hello-web
общедоступный IP-адрес, указанный последней командой, получает от Chrome "Этот сайт недоступен, x.x.x.x слишком долго отвечал".
Я провел вышеупомянутый тест в наших существующих кластерах, которые не являются ни VPC-native, ни Shared VPC, и он работает. Так что же я могу упустить?
Когда кластер GKE использует сеть из того же проекта, автоматически предоставляются разрешения, позволяющие учетной записи службы кластера Kubernetes создавать правила брандмауэра в этом проекте. Так что это просто работает.
При использовании общего VPC сервисному проекту (GKE) необходимо предоставить разрешение на создание правил брандмауэра в основном проекте. Или вы должны создать правила брандмауэра вручную. Если кластеру GKE не удается создать правила брандмауэра, он будет долго регистрироваться в событии Kubernetes вместе с командами, необходимыми для создания правил.
Мое решение заключалось в предоставлении роли compute.securityAdmin в проекте хоста Shared VPC учетной записи службы в проекте службы GKE: service- [номер-проекта] @ container-engine-robot.iam.gserviceaccount.com.
Вышеуказанная роль может быть чрезмерной. По крайней мере, учетной записи службы требуются правила compute.firewalls. * Внутри этой роли.