Обновление: я полагаю, что это не будет работать с производительностью по той же причине, что и обновление @ dinvlad выше, то есть ограничение скорости в IAP. Я оставлю здесь свой исходный пост, потому что он решает проблему сетевого подключения и иллюстрирует основной сетевой механизм.
Более того, даже если мы не используем его для Cloud Build, мой метод предоставляет способ туннелирования с моего ноутбука на частный главный узел K8s. Поэтому я могу редактировать yaml-файлы K8s на своем ноутбуке (например, с помощью VS Code) и немедленно выполнять kubectl со своего ноутбука, вместо того, чтобы отправлять код на хост-бастион и выполнять kubectl внутри хоста-бастиона. Я считаю, что это большой стимул для продуктивности времени разработки.
Исходный ответ
================
Я думаю, что могу улучшить отличное решение, предоставленное @dinvlad выше.
Я думаю, что решение можно упростить без установки прокси-сервера HTTP. Еще нужен бастионный хозяин.
Я предлагаю следующее Подтверждение концепции (без HTTP-прокси-сервера). Этот PoC иллюстрирует основной сетевой механизм, не отвлекая внимание от Google Cloud Build (GCB). (Когда у меня будет время в будущем, я опробую полную реализацию в Google Cloud Build.)
Предполагать:
- У меня есть кластер GKE, главный узел которого является частным, например, с IP-адресом 10.x.x.x.
- У меня есть вычислительный инстанс-бастион с именем
my-bastion. У него только частный IP, но не внешний IP. Частный IP-адрес находится в master authorized networks CIDR кластера GKE. Следовательно, изнутри my-bastion, kubectl работает против частного главного узла GKE. Поскольку у my-bastion нет внешнего IP-адреса, мой домашний ноутбук подключается к нему через IAP.
- Мой домашний портативный компьютер с моим домашним общедоступным IP-адресом в Интернете не всегда может подключиться к указанному выше частному главному узлу GKE.
Моя цель - выполнить kubectl на моем ноутбуке в этом частном кластере GKE. С точки зрения сетевой архитектуры мой домашний ноутбук похож на сервер Google Cloud Build.
Теория. Зная, что gcloud compute ssh (и связанный с ним IAP) является оболочкой для SSH, SSH Динамическое перенаправление портов должно достичь этой цели.
Практика:
## On laptop:
LAPTOP~$ kubectl get ns
^C <<<=== Without setting anything up, this hangs (no connectivity to GKE).
## Set up SSH Dynamic Port Forwarding (SOCKS proxy) from laptop's port 8443 to my-bastion.
LAPTOP~$ gcloud compute ssh my-bastion --ssh-flag="-ND 8443" --tunnel-through-iap
В другом терминале моего ноутбука:
## Without using the SOCKS proxy, this returns my laptop's home public IP:
LAPTOP~$ curl https://checkip.amazonaws.com
199.xxx.xxx.xxx
## Using the proxy, the same curl command above now returns a different IP address,
## i.e., the IP of my-bastion.
## Note: Although my-bastion doesn't have an external IP, I have a GCP Cloud NAT
## for its subnet (for purpose unrelated to GKE or tunneling).
## Anyway, this NAT is handy as a demonstration for our curl command here.
LAPTOP~$ HTTPS_PROXY=socks5://127.0.0.1:8443 curl -v --insecure https://checkip.amazonaws.com
* Uses proxy env variable HTTPS_PROXY == 'socks5://127.0.0.1:8443' <<<=== Confirming it's using the proxy
...
* SOCKS5 communication to checkip.amazonaws.com:443
...
* TLSv1.2 (IN), TLS handshake, Finished (20): <<<==== successful SSL handshake
...
> GET / HTTP/1.1
> Host: checkip.amazonaws.com
> User-Agent: curl/7.68.0
> Accept: */*
...
< Connection: keep-alive
<
34.xxx.xxx.xxx <<<=== Returns the GCP Cloud NAT'ed IP address for my-bastion
Наконец, момент истины для kubectl:
## On laptop:
LAPTOP~$ HTTPS_PROXY=socks5://127.0.0.1:8443 kubectl --insecure-skip-tls-verify=true get ns
NAME STATUS AGE
default Active 3d10h
kube-system Active 3d10h
person
Vincent Yin
schedule
22.02.2021
