Поделиться через


Ограничение сетевого трафика с помощью межсетевого экрана Azure в Службе Azure Kubernetes (AKS)

В этой статье показано, как использовать правила для исходящей сети и полностью квалифицированного доменного имени (FQDN) в кластерах AKS для управления исходящим трафиком с помощью брандмауэра Azure. Чтобы упростить эту конфигурацию, брандмауэр Azure предоставляет тег FQDN службы Azure Kubernetes (AzureKubernetesService), который ограничивает исходящий трафик из кластера AKS.

Требования к интерфейсным IP-адресам брандмауэра

  • Производственный минимум: Используйте по крайней мере 20 внешних IP-адресов в Azure Firewall, чтобы избежать исчерпания портов преобразования сетевых адресов (SNAT).
  • Кластеры с высоким трафиком. Если кластер создает много исходящих подключений к одному и тому же назначению, может потребоваться больше интерфейсных IP-адресов, чтобы избежать максимального количества портов на IP-адрес.
  • Защита сервера API: добавьте общедоступный внешний IP-адрес брандмауэра в авторизованные диапазоны IP-адресов сервера API для повышения безопасности.
  • Доступ разработчика: при использовании авторизованных диапазонов IP-адресов используйте шлюз в виртуальной сети брандмауэра или добавьте IP-адреса конечной точки разработчика в авторизованный диапазон

Это руководство применяется в процессе настройки, описанном в этой статье.

Примечание.

Тег FQDN содержит все полные доменные имена (FQDN), перечисленные в правилах исходящей сети и правилах FQDN для кластеров AKS, и автоматически обновляется.

Обзор архитектуры

На следующей схеме показана архитектура кластера AKS с ограниченным исходящим трафиком с помощью брандмауэра Azure.

Заблокированная топология

К ключевым компонентам этой архитектуры относятся:

  • Общедоступный входящий трафик принудительно проходит через фильтры брандмауэра:
    • Узлы агента AKS изолированы в выделенной подсети.
    • Брандмауэр Azure развертывается в собственной подсети.
    • Правило DNAT преобразует общедоступный IP-адрес брандмауэра в интерфейсный IP-адрес подсистемы балансировки нагрузки.
  • Исходящие запросы начинаются с узлов агента к внутреннему IP-адресу брандмауэра Azure с помощью определяемого пользователем маршрута (UDR):
    • Запросы от узлов агента AKS проходят через UDR, который размещен в подсети, в которую был развернут кластер AKS.
    • Трафик брандмауэра Azure выходит из виртуальной сети через внешний интерфейс с общедоступным IP-адресом.
    • Доступ к общедоступному Интернету или другим службам Azure осуществляется к и из внешнего IP-адреса брандмауэра.
    • Вы можете защитить доступ к плоскости управления AKS с помощью авторизованных диапазонов IP-адресов сервера API, включая общедоступный IP-адрес брандмауэра.
  • Внутренний трафик:

Настройка переменных среды

В следующей таблице перечислены переменные среды, используемые в этой статье. Задайте эти переменные в оболочке перед продолжением или измените команды, чтобы использовать собственные значения.

Variable Description Пример значения
PREFIX Префикс для имен ресурсов aks-egress
RESOURCE_GROUP Имя группы ресурсов aks-egress-rg
LOCATION Регион Azure для ресурсов eastus
PLUGIN Сетевой подключаемый модуль для AKS azure
CLUSTER_NAME Имя кластера AKS aks-egress
VNET_NAME Имя виртуальной сети aks-egress-vnet
AKS_SUBNET_NAME Имя подсети для AKS aks-subnet
FW_SUBNET_NAME Имя подсети для брандмауэра Azure AzureFirewallSubnet
FW_NAME Имя брандмауэра Azure aks-egress-fw
FW_PUBLICIP_NAME Имя общедоступного IP-адреса для брандмауэра Azure aks-egress-fwpublicip
FW_IPCONFIG_NAME Имя IP-конфигурации для брандмауэра Azure aks-egress-fwconfig
FW_ROUTE_TABLE_NAME Имя таблицы маршрутов для брандмауэра Azure aks-egress-fwrt
FW_ROUTE_NAME_1 Имя маршрута для брандмауэра Azure aks-egress-fwrn
FW_ROUTE_NAME_2 Имя интернет-маршрута для брандмауэра Azure aks-egress-fwrn-internet

Создайте группу ресурсов

  • Создайте группу ресурсов с помощью az group create команды.

    az group create --name $RESOURCE_GROUP --location $LOCATION
    

Создание виртуальной сети с несколькими подсетями

Подготовьте виртуальную сеть с двумя отдельными подсетями: один для кластера и один для брандмауэра. При необходимости можно создать ее для внутреннего входящего трафика службы. На следующей схеме показана пустая топология сети перед развертыванием любых ресурсов:

Пустая топология сети

  1. Создайте виртуальную сеть с помощью az network vnet create команды.

    az network vnet create \
        --resource-group $RESOURCE_GROUP \
        --name $VNET_NAME \
        --location $LOCATION \
        --address-prefixes 10.42.0.0/16 \
        --subnet-name $AKS_SUBNET_NAME \
        --subnet-prefix 10.42.1.0/24
    
  2. Создайте подсеть для брандмауэра Azure с помощью az network vnet subnet create команды.

    # Dedicated subnet for Azure Firewall (subnet must be named "AzureFirewallSubnet")
    az network vnet subnet create \
        --resource-group $RESOURCE_GROUP \
        --vnet-name $VNET_NAME \
        --name $FW_SUBNET_NAME \
        --address-prefix 10.42.2.0/24
    

Создание общедоступного IP-адреса для брандмауэра Azure

  • Создайте стандартный ресурс общедоступного IP-адреса SKU с помощью az network public-ip create команды. Этот ресурс используется в качестве внешнего IP-адреса брандмауэра Azure.

    az network public-ip create --resource-group $RESOURCE_GROUP --name $FW_PUBLICIP_NAME --location $LOCATION --sku "Standard"
    

Установка расширения Azure Firewall CLI

Создание брандмауэра Azure и включение DNS-прокси

Примечание.

Сведения о сценариях с высоким трафиком см. в разделе требований к IP-адресам внешнего интерфейса брандмауэра .

Дополнительные сведения о создании Брандмауэр Azure с несколькими IP-адресами см. в статье "Создание Брандмауэр Azure с несколькими общедоступными IP-адресами с помощью Bicep".

Брандмауэр и UDR

  • Создайте брандмауэр Azure и включите DNS-прокси с помощью команды с параметром --enable-dns-proxy установленным в true.

    az network firewall create --resource-group $RESOURCE_GROUP --name $FW_NAME --location $LOCATION --enable-dns-proxy true
    

    Настройка общедоступного IP-адреса в брандмауэре Azure может занять несколько минут. Когда он будет готов, вы можете назначить IP-адрес интерфейсу брандмауэра.

    Примечание.

    Чтобы использовать FQDN в правилах сети, необходимо включить DNS-прокси. Если dns-прокси включен, брандмауэр прослушивает порт 53 и пересылает DNS-запросы на указанный DNS-сервер. Этот параметр позволяет брандмауэру автоматически переводить полное доменное имя.

Создание IP-конфигурации для брандмауэра Azure

  • Создайте IP-конфигурацию для Брандмауэра Azure с помощью команды az network firewall ip-config create.

    az network firewall ip-config create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --name $FW_IPCONFIG_NAME --public-ip-address $FW_PUBLICIP_NAME --vnet-name $VNET_NAME
    

Получение IP-адресов брандмауэра Azure

  • Сохраните общедоступные и частные IP-адреса брандмауэра для настройки позже с помощью следующих команд:

    export FW_PUBLIC_IP=$(az network public-ip show --resource-group $RESOURCE_GROUP --name $FW_PUBLICIP_NAME --query "ipAddress" -o tsv)
    export FW_PRIVATE_IP=$(az network firewall show --resource-group $RESOURCE_GROUP --name $FW_NAME --query "ipConfigurations[0].privateIPAddress" -o tsv)
    

    Примечание.

    Сведения о безопасности сервера API см. в разделе "Требования к интерфейсным IP-адресам брандмауэра ".

Настройка UDR для исходящего трафика AKS через брандмауэр Azure

Azure автоматически направляет трафик между подсетями Azure, виртуальными сетями и локальными сетями. Чтобы изменить маршрутизацию по умолчанию, создайте таблицу маршрутов со следующими требованиями:

Обязательные параметры маршрута:

  • Назначение маршрута: 0.0.0.0/0 (весь трафик)
  • Тип следующего перехода: сетевое виртуальное устройство (NVA)
  • IP-адрес следующего прыжка: частный IP-адрес брандмауэра Azure
  • Связь: одна таблица маршрутов для каждой подсети (ноль или одна разрешенная)

Ограничения UDR:

  • По умолчанию интернет-маршрут () уже существует,0.0.0.0/0 но требуется общедоступный IP-адрес для SNAT.
  • Маршрут должен указывать на шлюз или NVA, а не напрямую на Интернет.
  • AKS проверяет конфигурацию маршрута и предотвращает прямые интернет-маршруты.
  • Каждая подсеть поддерживает только одну связанную таблицу маршрутов.

Влияние исходящего типа:

  • UDR (userDefinedRouting): Общедоступный IP-адрес системы балансировки нагрузки не создан для исходящих запросов.
  • Общедоступный IP-адрес Load Balancer: создан только для входящих запросов с типом LoadBalancer службы.
  • Конфигурация SNAT. Требуется правильная конфигурация общедоступного IP-адреса для исходящего подключения.

Дополнительные сведения см. в разделе "Правила исходящего трафика" для Azure Load Balancer.

Создание маршрута с переходом через Azure Firewall

  1. Создайте пустую таблицу маршрутов с помощью az network route-table create команды. Таблица маршрутов определяет брандмауэр Azure в качестве следующего прыжка. Каждая подсеть может иметь ноль или одну таблицу маршрутов, связанную с ней.

    az network route-table create --resource-group $RESOURCE_GROUP --location $LOCATION --name $FW_ROUTE_TABLE_NAME
    
  2. Создайте маршруты в таблице маршрутов для подсетей с помощью az network route-table route create команды.

    az network route-table route create --resource-group $RESOURCE_GROUP --name $FW_ROUTE_NAME_1 --route-table-name $FW_ROUTE_TABLE_NAME --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FW_PRIVATE_IP
    
    az network route-table route create --resource-group $RESOURCE_GROUP --name $FW_ROUTE_NAME_2 --route-table-name $FW_ROUTE_TABLE_NAME --address-prefix $FW_PUBLIC_IP/32 --next-hop-type Internet
    

Сведения о переопределении системных маршрутов Azure по умолчанию или добавлении дополнительных маршрутов в таблицу маршрутов подсети см. в документации по таблице маршрутов виртуальной сети.

Правила исходящего трафика брандмауэра Azure для AKS

Примечание.

Для приложений за пределами пространств имен kube-system или gatekeeper-system, которые должны взаимодействовать с сервером API, необходимо дополнительное сетевое правило, позволяющее TCP-связь через порт 443 для IP-адреса сервера API, а также добавление правила приложения для fqdn-tag пространства имен AzureKubernetesService.

Для управления исходящим трафиком AKS через брандмауэр Azure требуются следующие правила сети:

  • Первое сетевое правило разрешает доступ к порту 9000 через TCP.
  • Второе правило сети разрешает доступ к порту 1194 через UDP. Если вы развертываете в Microsoft Azure, управляемой 21Vianet, ознакомьтесь с необходимыми сетевыми правилами, управляемыми 21Vianet. В этой статье команды используют AzureCloud.$LOCATION тег службы в качестве адреса назначения. Теги служб представляют группы префиксов IP-адресов для служб Azure в определенных регионах. Это автоматически включает соответствующие диапазоны CIDR для служб Azure, не требуя ручной спецификации диапазона IP-адресов.
  • Третье сетевое правило открывает порт 123 на ntp.ubuntu.com FQDN по UDP. Добавление полного доменного имени в качестве сетевого правила является одной из уникальных функций брандмауэра Azure, поэтому необходимо адаптировать это правило при использовании собственных параметров.
  • Четвертые и пятые правила сети позволяют получать контейнеры из реестра контейнеров GitHub (ghcr.io) и Docker Hub (docker.io).

Создание сетевых правил в брандмауэре Azure

  • Создайте сетевые правила с помощью следующих az network firewall network-rule create команд.

    az network firewall network-rule create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --collection-name 'aksfwnr' --name 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOCATION" --destination-ports 9000
    
    az network firewall network-rule create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --collection-name 'aksfwnr' --name 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOCATION" --destination-ports 1194 --action allow --priority 100
    
    az network firewall network-rule create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --collection-name 'aksfwnr' --name 'time' --protocols 'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123
    
    az network firewall network-rule create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --collection-name 'aksfwnr' --name 'ghcr' --protocols 'TCP' --source-addresses '*' --destination-fqdns ghcr.io pkg-containers.githubusercontent.com --destination-ports '443'
    
    az network firewall network-rule create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --collection-name 'aksfwnr' --name 'docker' --protocols 'TCP' --source-addresses '*' --destination-fqdns docker.io registry-1.docker.io production.cloudflare.docker.com --destination-ports '443'
    

Создание правил приложения в брандмауэре Azure

  • Создайте правило приложения с помощью az network firewall application-rule create команды.

    az network firewall application-rule create --resource-group $RESOURCE_GROUP --firewall-name $FW_NAME --collection-name 'aksfwar' --name 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
    

Дополнительные сведения о Брандмауэр Azure см. в документации по Брандмауэр Azure.

Привязка таблицы маршрутизации к AKS

Чтобы связать кластер с брандмауэром, выделенная подсеть для подсети кластера должна ссылаться на таблицу маршрутов.

  • Свяжите таблицу маршрутов с AKS с помощью az network vnet subnet update команды.

    az network vnet subnet update --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --name $AKS_SUBNET_NAME --route-table $FW_ROUTE_TABLE_NAME
    

Развертывание кластера AKS, который соответствует правилам исходящего трафика

Теперь кластер AKS можно развернуть в существующей виртуальной сети. Вы используете тип конфигурации на исходящий трафикuserDefinedRouting, который гарантирует, что весь исходящий трафик проходит через брандмауэр, и не допускается иных путей для выхода. Вы также можете использовать исходящийloadBalancer тип.

aks-deploy

  • Задайте переменную среды для идентификатора подсети целевой подсети с помощью следующей команды:

    SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --name $AKS_SUBNET_NAME --query id -o tsv)
    

Вы определяете исходящий тип, чтобы использовать UDR, который уже существует в подсети. Эта конфигурация позволяет AKS пропускать настройку и подготовку IP-адресов для подсистемы балансировки нагрузки.

Совет

Дополнительные функции можно добавить в развертывание кластера, например частные кластеры.

Сведения о настройке разрешенных диапазонов IP-адресов сервера API и рекомендациях по доступу к разработчикам см. в разделе требований к интерфейсным IP-адресам брандмауэра .


Создание кластера AKS с удостоверениями, назначенными системой

Примечание.

AKS создает системное удостоверение kubelet в группе ресурсов узла, если вы не указали собственное управляемое удостоверение kubelet.

Для пользовательской маршрутизации удостоверение, назначенное системой, поддерживает только сетевой плагин CNI.

  • Создайте кластер AKS с управляемым удостоверением, назначаемым системой, используя сетевой плагин CNI с помощью команды az aks create.

    az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --location $LOCATION \
        --node-count 3 \
        --network-plugin azure \
        --outbound-type userDefinedRouting \
        --vnet-subnet-id $SUBNET_ID \
        --api-server-authorized-ip-ranges $FW_PUBLIC_IP \
        --generate-ssh-keys
    

Создание удостоверений, назначенных пользователем

Если у вас нет идентификаторов, назначенных пользователем, выполните действия, описанные в этом разделе. Если у вас уже есть удостоверения, назначенные пользователем, перейдите к разделу "Создание кластера AKS с удостоверениями, назначенными пользователем".

  1. Создайте управляемое удостоверение с помощью az identity create команды.

    az identity create --name myIdentity --resource-group $RESOURCE_GROUP
    

    Выходные данные должны выглядеть примерно так:

     {
       ...
       "id": "/subscriptions/<subscriptionid>/resourcegroups/aks-egress-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
       "location": "eastus",
       "name": "myIdentity",
       ...
       "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
     }
    
  2. Создайте управляемое удостоверение kubelet с помощью команды az identity create.

    az identity create --name myKubeletIdentity --resource-group $RESOURCE_GROUP
    

    Выходные данные должны выглядеть примерно так:

    {
      ...
      "id": "/subscriptions/<subscriptionid>/resourcegroups/aks-egress-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity",
      "location": "eastus",
      "name": "myKubeletIdentity",
      ...
      "resourceGroup": "aks-egress-rg",
      ...
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
    }
    

Примечание.

Если вы создаете собственную виртуальную сеть и таблицу маршрутов, где ресурсы находятся за пределами рабочей группы ресурсов узла, интерфейс командной строки автоматически добавляет назначение роли. Если вы используете шаблон ARM или другой метод, вам необходимо использовать идентификатор управляющей учетной записи кластера для выполнения назначения роли.

Создание кластера AKS с идентификаторами, назначенными пользователем

  • Создайте кластер AKS с вашими существующими назначаемыми пользователем управляемыми удостоверениями на подсети с помощью команды az aks create. Укажите идентификатор ресурса управляемого удостоверения для плоскости управления и идентификатор ресурса удостоверения kubelet.

    az aks create \
        --resource-group $RESOURCE_GROUP \
        --name $CLUSTER_NAME \
        --location $LOCATION \
        --node-count 3 \
        --network-plugin kubenet \
        --outbound-type userDefinedRouting \
        --vnet-subnet-id $SUBNET_ID \
        --api-server-authorized-ip-ranges $FW_PUBLIC_IP \
        --assign-identity <identity-resource-id> \
        --assign-kubelet-identity <kubelet-identity-resource-id> \
        --generate-ssh-keys
    

Разрешение доступа разработчика к серверу API

Если вы использовали авторизованные диапазоны IP-адресов для кластера на предыдущем шаге, необходимо добавить IP-адреса инструментов разработчика в список утвержденных диапазонов IP-адресов, чтобы получить доступ к серверу API. Вы также можете настроить шлюз с необходимым инструментарий в отдельной подсети в VNet брандмауэра.

  1. Получите IP-адрес с помощью следующей команды:

    CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
    
  2. Добавьте IP-адрес в утвержденные диапазоны с помощью az aks update команды.

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --api-server-authorized-ip-ranges $CURRENT_IP/32
    

Подключение к кластеру AKS

  • Настройте kubectl, чтобы подключиться к вашему кластеру AKS, с помощью команды az aks get-credentials.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
    

Разверните публичную службу в AKS

Теперь можно приступить к раскрытию служб и развертыванию приложений в этом кластере. В этом примере предоставляется общедоступная служба, но может потребоваться предоставить внутреннюю службу с помощью внутренней подсистемы балансировки нагрузки.

Общедоступная служба DNAT

  1. Просмотрите манифест демонстрации AKS Store Quickstart, чтобы понять развернутые компоненты.

  2. Разверните службу с помощью kubectl apply команды.

    kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/aks-store-quickstart.yaml
    

Получение внутреннего IP-адреса балансировщика нагрузки и IP-адреса службы

  1. Получите внутренний IP-адрес, назначенный балансировщику нагрузки, с помощью команды kubectl get services.

    kubectl get services
    

    IP-адрес должен быть указан в столбце EXTERNAL-IP , как показано в следующем примере выходных данных:

    NAME              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)              AGE
    kubernetes        ClusterIP      10.0.0.1       <none>        443/TCP              9m10s
    order-service     ClusterIP      10.0.104.144   <none>        3000/TCP             11s
    product-service   ClusterIP      10.0.237.60    <none>        3002/TCP             10s
    rabbitmq          ClusterIP      10.0.161.128   <none>        5672/TCP,15672/TCP   11s
    store-front       LoadBalancer   10.0.89.139    20.39.18.6    80:32271/TCP         10s
    
  2. Получите IP-адрес службы с помощью kubectl get svc store-front команды.

    SERVICE_IP=$(kubectl get svc store-front -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
    

Создание правила DNAT в брандмауэре Azure

Внимание

Если вы используете Брандмауэр Azure для ограничения исходящего трафика и создаёте маршрут UDR для принудительной передачи всего исходящего трафика, убедитесь, что вы создаёте корректное правило DNAT в Брандмауэр Azure, чтобы правильно разрешить входящий трафик. Использование Брандмауэра Azure в сочетании с определяемыми пользователем маршрутами нарушает передачу входящего трафика из-за асимметричной маршрутизации. Проблема возникает, если подсеть AKS имеет маршрут по умолчанию, который ведет к частному IP-адресу брандмауэра, но вы используете публичный балансировщик нагрузки или службу Kubernetes типа loadBalancer. В этом случае входящий трафик подсистемы балансировки нагрузки поступает через общедоступный IP-адрес, а обратный путь проходит через частный IP-адрес брандмауэра. Поскольку брандмауэр отслеживает состояние соединений, он отбрасывает возвращаемый пакет, так как не знает о существующем сеансе. Сведения о том, как интегрировать Брандмауэр Azure с балансировщиком нагрузки для входящего трафика или служб, см. в статье Интеграция Брандмауэра Azure с Azure Standard Load Balancer.

Чтобы настроить входящий трафик, необходимо написать правило DNAT в Брандмауэр Azure. Чтобы проверить возможность подключения к вашему кластеру, для общедоступного IP-адреса фронтенда брандмауэра определяется правило, которое маршрутизирует его на внутренний IP-адрес, предоставляемый внутренней службой. Вы можете настроить целевой адрес. Преобразованный адрес должен представлять собой IP-адрес внутреннего балансировщика нагрузки. Перенаправленный порт должен быть открытым портом для вашей службы в Kubernetes. Кроме того, необходимо указать внутренний IP-адрес, назначенный подсистеме балансировки нагрузки, созданной службой Kubernetes.

  • Добавьте правило NAT с помощью az network firewall nat-rule create команды.

    az network firewall nat-rule create --collection-name exampleset --destination-addresses $FW_PUBLIC_IP --destination-ports 80 --firewall-name $FW_NAME --name inboundrule --protocols Any --resource-group $RESOURCE_GROUP --source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP
    

Проверка подключения

  • Перейдите к IP-адресу клиентского компонента брандмауэра Azure в браузере, чтобы проверить подключение. Вам должно быть видно приложение магазина AKS. В этом примере общедоступный IP-адрес брандмауэра:52.253.228.132

    Снимок экрана приложения Azure Store Front, открытого в локальном браузере.

    На этой странице можно просмотреть продукты, добавить их в корзину, а затем разместить заказ.

Очистка ресурсов

Если ресурсы, созданные в этой статье, больше не нужны, их можно удалить, чтобы избежать будущих затрат.

  • Удалите группу ресурсов AKS с помощью az group delete команды.

    az group delete --name $RESOURCE_GROUP