Вопрос или проблема
Я пытаюсь настроить GKE с автономным NEG (избегая Ingress и вместо этого используя Terraform для настройки балансировщика нагрузки). Все работает нормально, но пока я использую правила брандмауэра из другого Ingress.
Но для создания правильного правила брандмауэра мне нужны GKE_NODE_NETWORK_TAGS. Но я не могу их установить при создании кластера Autopilot. Я также не могу перечислить узлы, как указано в документации, потому что узлы Autopilot невидимы для gcloud compute instances describe.
Как правильно создать правило брандмауэра для кластера Autopilot?
PS: Документация по автономным NEG: https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg#attaching_a_load_balancer_to_your_standalone_negs
При активации Autopilot, GKE автоматически создает правила брандмауэра, и вы можете просмотреть их, набрав команду gcloud:
gcloud compute firewall-rules list --filter="name=gke-autopilot"
Для более детального просмотра:
gcloud compute firewall-rules list --filter="name=gke-autopilot" --format=json
Хотя возможно обновить правила брандмауэра и добавить желаемые целевые теги с помощью команды:
gcloud compute firewall-rules update firewall-rule-name \
--target-tags=tag-name
Как вы правильно указали, невозможно установить теги в узлы autopilot, так как они управляются Google, вам нужно будет настроить свой кластер как стандартный.
Теги сети в настоящее время не поддерживаются Autopilot, но функция находится в разработке и будет выпущена очень скоро в RAPID release channel.
Привет, ребята, не знаю, будет ли это вам полезно или нет, но я вижу, что это доставляет вам хлопоты уже какое-то время, такой недосмотр со стороны Google. Поэтому я автоматизировал процесс и поделился скриптом. Это контейнер Docker, который получает текущий список IP-адресов на вашем кластере и затем обновляет правило брандмауэра, удаляя любые IP-адреса, которых нет в кластере, и убеждаясь, что IP-адреса соответствуют текущим узлам кластера. Он не обновляет правила брандмауэра, если нет расхождений.
Это, вероятно, можно улучшить, мне просто нужно было что-то, что работало, чтобы наш производственный кластер не пострадал каждый раз, когда autopilot обновлял наши узлы.
https://serverfault.com/questions/1091574/how-to-get-k8s-node-networking-tags-for-autopilot-cluster
GKE Autopilot теперь предоставляет возможность использовать сетевые теги или политики брандмауэра для применения тегов к автопроектируемым виртуальным машинам.
.
Ответ или решение
Настройка кластеров GKE Autopilot и управление параметрами сети может быть вызовом, особенно когда речь идет о сетевых тегах и правилах файрвола. В контексте вашего вопроса о получении сетевых тегов для узлов в кластере Autopilot, давайте разберем подробно возможные шаги и подходы.
Теория
Google Kubernetes Engine (GKE) в режиме Autopilot предлагает полностью управляемую платформу для развертывания контейнеризированных приложений. Одним из ключевых аспектов такой платформы является автоматичное управлением облачной инфраструктурой, включая узлы и сетевые ресурсы, что упрощает использование, но может ограничить прямой доступ к определенным настройкам, таким как сетевые теги.
Сетевые теги в GKE, как правило, используются для определения целевых объектов в правилах файрвола. Это необходимо для того, чтобы контролировать доступ к ресурсам из внешних и внутренних источников. В обычных кластерах этого можно достичь, напрямую используя теги узлов, но в Autopilot кластерах этот механизм скрыт от пользователя, так как узлы являются управляемыми ресурсами.
Пример
Если вы создаёте балансировщик нагрузки с помощью Terraform и хотите избежать использования Ingress, то вам будет необходимо вручную управлять правилами файрвола. В случае стандартных кластеров GKE это можно выполнить, используя сетевые теги, связанные с узлами, однако в кластерах Autopilot узлы автоматизированы и, следовательно, директ access к ресурсам отсутствует.
Работа с правилами файрволов в Autopilot
Автопилот автоматически создает и управляет необходимыми правилами файрволов для работы вашего кластера. Вы можете просмотреть текущие настройки, выполнив команды:
gcloud compute firewall-rules list --filter="name=gke-autopilot"Эта команда отобразит список правил файрвола, применяемых к вашему автопилот-кластеру. Для более подробного отображения воспользуйтесь форматированием в JSON:
gcloud compute firewall-rules list --filter="name=gke-autopilot" --format=jsonВ случае необходимости корректировки, возможно, будет полезна команда:
gcloud compute firewall-rules update firewall-rule-name --target-tags=tag-nameНо стоит помнить, что существуют ограничения на использование собственных сетевых тегов в кластере Autopilot, поскольку он управляется Google. В данной конфигурации теги не назначаются вручную.
Применение
Если вы нуждаетесь в больше кастомизации, например при создании собственных правил файрвола для конкретных целей, таких как оптимизация Standalone NEG (Negated Exclusion Group), следует учитывать текущие ограничения и развивать другие подходы.
В частности, могут быть рассмотрены следующие шаги:
-
Использование скриптов автоматизации: как предложено в одном из обсуждений, автоматизация процесса обновления правил файрвола на основе информации об IP-адресах может быть решением. Это может помочь автоматически следить за актуальным состоянием инфраструктуры и соответственно обновлять файрволы. Например, репозиторий на GitHub (нейронический-скрипты) предлагает инструмент, который автоматически проверяет и обновляет правила файрвола на основе состояния узлов в кластере.
-
Переход на стандартный кластер: если ваши потребности сильно зависят от ручного управления сетевыми правилами и тегами узлов, возможно, стоит рассмотреть возможность развертывания кластера в стандартном режиме GKE, где такие настройки более доступны.
-
Обновление информации о поддержке тегов: по состоянию на момент публикации, Google разрабатывает поддержку сетевых тегов для кластеров Autopilot, и это может быть внедрено в RAPID-канале обновлений. Это стоит постоянно мониторить, чтобы воспользоваться этими улучшениями сразу после их выпуска.
В заключение, настройка кластера в режиме Autopilot подразумевает определенные ограничения на кастомизацию инфраструктуры, но возможно использование различных альтернатив, позволяющих обойти эти ограничения. Планирование, мониторинг и автоматизация процессов помогут создать управляемую, безопасную и оптимизированную инфраструктуру приложения на Kubernetes.