Я могу (например) подключиться к кластеру вычислить такие узлы: gcloud compute ssh gke-test-deploy-default-pool-xxxxx --internal-ip
Но если я попытаюсь настроить свои учетные данные kubectl следующим образом: gcloud container clusters get-credentials test-deploy --internal-ip Он жалуется:
ОШИБКА: (gcloud.container.clusters.get-credentials) тестовое развертывание кластера не является частным кластером.
Я могу выполнять команды, отличные от ssh, например kubectl get pods --all-namespaces, но если я сделаю kubectl exec -it rabbitmq-podnumber -n backbone-testdeploy bash Я получаю такую ошибку:
Ошибка сервера: ошибка при наборе номера: в настоящее время туннели SSH не открыты. Могли ли цели принять ssh-ключ для пользователя "gke-xxxxxxx"
Кстати, вся суть этого заключается в использовании Google Cloud NAT в моем кластере, чтобы у меня был согласованный внешний IP-адрес для всех модулей при подключении к внешней службе (Atlas), которая использует белый список IP-адресов. Я вижу, как NAT работает для вычислительных экземпляров, но я не могу подключиться к модулям, чтобы проверить их.
Главный узел и рабочие узлы находятся в разных сетях, главный находится в сети, управляемой Google, а рабочие узлы находятся в вашем VPC. В стандартном кластере мастер связывается с узлами через внешний IP-адрес. В частном кластере главный узел и рабочие узлы связаны через пиринговую сеть и обмениваются данными через внутренние IP-адреса.
Это вызывает проблемы при подключении к мастеру напрямую через другие одноранговые сети или VPN-подключения, потому что маршруты пиринга сети к мастеру не распространяются через VPN и сетевой пиринг.
Для вашего случая использования отключить внешнюю главную конечную точку. Как только это будет сделано, когда вы запустите команду get-credentials, ваша конфигурация kube будет иметь внутреннюю главную конечную точку вместо внешней. Затем вам нужно будет подключиться к своему мастеру (kubectl) из сети VPC (хост-бастион или прокси).
Вместо этого я рекомендую оставить активную внешнюю конечную точку, использовать get-credentials без использования --internal-ip, чтобы ваша конфигурация kube использовала внешнюю конечную точку и, таким образом, вы могли подключаться из любого места. Чтобы убедиться, что ваш мастер в безопасности, используйте Мастер авторизованных сетей для определения внешних IP-адресов или CIDR, с которых вы будете подключаться
Я почти уверен, что команды kubectl exec и logs не работают из-за того, как вы получаете учетные данные.
И последнее, что стоит проверить: GKE автоматически создает правила и маршруты брандмауэра (они будут называться gke -...), они необходимы для обеспечения правильной работы SSH-туннелей от мастера к узлам.