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

Пользовательская группа безопасности сети блокирует трафик

  • Статья

При доступе к приложению, размещенном в кластере Служба Azure Kubernetes (AKS), вы получите сообщение об ошибке "Время ожидания". Эта ошибка может возникать, даже если приложение запущено, и остальная часть конфигурации, как представляется, исправлена.

Предварительные требования

Симптомы

При выполнении следующих команд kubectl get и cURL возникают ошибки "Время ожидания", похожие на следующие выходные данные консоли:

$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
my-deployment-66648877fc-v78jm   1/1     Running   0          5m53s

$ kubectl get service
NAME                      TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
my-loadbalancer-service   LoadBalancer   10.0.107.79   10.81.x.x   80:31048/TCP   4m14s

$ curl -Iv http://10.81.124.39  # Use an IP address that fits the "EXTERNAL-IP" pattern.
*   Trying 10.81.x.x:80...
* connect to 10.81.x.x port 80 failed: Timed out
* Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out

Причина

Если возникает одна и та же ошибка "Время ожидания" каждый раз, то обычно предполагается, что сетевой компонент блокирует трафик.

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

Чтобы проверить pod, выполните следующие kubectl get команды и команды kubectl :

$ kubectl get pods -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP            NODE                               
my-deployment-66648877fc-v78jm   1/1     Running   0          53s   172.25.0.93   aks-agentpool-42617579-vmss000000

$ kubectl describe pod my-deployment-66648877fc-v78jm  # Specify the pod name from the previous command.
...
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  117s  default-scheduler  Successfully assigned default/my-deployment-66648877fc-v78jm to aks-agentpool-42617579-vmss000000
  Normal  Pulling    116s  kubelet            Pulling image "httpd"
  Normal  Pulled     116s  kubelet            Successfully pulled image "httpd" in 183.532816ms
  Normal  Created    116s  kubelet            Created container webserver
  Normal  Started    116s  kubelet            Started container webserver

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

Откройте тестовый модуль pod, чтобы проверить доступ к pod приложения. Выполните следующие kubectl getкоманды kubectl иapt-get cURL:

$ kubectl get pods -o wide  # Get the pod IP address.
NAME                             READY   STATUS    RESTARTS   AGE     IP            NODE                                
my-deployment-66648877fc-v78jm   1/1     Running   0          7m45s   172.25.0.93   aks-agentpool-42617579-vmss000000  

$ kubectl run -it --rm aks-ssh --image=debian:stable  # Launch the test pod.
If you don't see a command prompt, try pressing enter.
$ root@aks-ssh:

$ # Install packages inside the test pod.
$ root@aks-ssh: apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
...
...
Running hooks in /etc/ca-certificates/update.d...
done.

$ # Try to check access to the pod using the pod IP address from the "kubectl get" output.
$ curl -Iv http://172.25.0.93
*   Trying 172.25.0.93:80...
* Connected to 172.25.0.93 (172.25.0.93) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 172.25.0.93 left intact

Модуль pod доступен напрямую. Поэтому приложение выполняется.

Определяемая служба является типом LoadBalancer . Это означает, что поток запроса от конечного клиента к pod будет следующим образом:

Модуль pod приложения для балансировки >> нагрузки >> клиента >> AKS

В этом потоке запросов можно заблокировать трафик через следующие компоненты:

  • Политики сети в кластере
  • Группа безопасности сети (NSG) для подсети AKS и узла AKS

Чтобы проверить политику сети, выполните следующую kubectl get команду:

$ kubectl get networkpolicy --all-namespaces
NAMESPACE     NAME                 POD-SELECTOR             AGE
kube-system   konnectivity-agent   app=konnectivity-agent   3h8m

Существует только политика AKS по умолчанию. Таким образом, политика сети не блокирует трафик.

Чтобы проверить группы безопасности сети и связанные с ними правила с помощью AKS, выполните следующие действия.

  1. В портал Azure найдите и выберите масштабируемые наборы виртуальных машин.

  2. В списке экземпляров масштабируемого набора выберите тот, который вы используете.

  3. В области меню экземпляра масштабируемого набора выберите Networking.

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

  • Первый набор состоит из правил NSG на уровне подсети. Эти правила отображаются в следующем заголовке заметок:

    Группа безопасности сети my-aks-nsg> (подключенная к подсети:< my-aks-subnet>)<

    Это обычно происходит, если используется настраиваемая виртуальная сеть и пользовательская подсеть для кластера AKS. Набор правил на уровне подсети может выглядеть следующим образом.

    Приоритет Имя Порт Протокол Источник Назначение Действие
    65000 AllowVNetInBound Любой Любой Виртуальная сеть Виртуальная сеть Allow
    65001 AllowAzureLoadBalancerInBound Любой Любой AzureLoadBalancer Любое Allow
    65500 DenyAllInBound Любой Любой Любой Любой Запрет

  • Второй набор состоит из правил NSG на уровне сетевого адаптера. Эти правила отображаются в следующем заголовке заметок:

    Группа безопасности сети aks-agentpool-agentpool-number-nsg>< (подключена к сетевому интерфейсу: aks-agentpool-vm-scale-set-number-vmss><)

    Эта группа безопасности сети применяется кластером AKS и управляется AKS. Соответствующий набор правил может быть похож на следующую таблицу.

    Приоритет Имя Порт Протокол Источник Назначение Действие
    500 <guid-TCP-80-Internet> 80 TCP Интернет 10.81.x.x Разрешить
    65000 AllowVNetInBound Любой Любой Виртуальная сеть Виртуальная сеть Allow
    65001 AllowAzureLoadBalancerInBound Любой Любой AzureLoadBalancer Любое Allow
    65500 DenyAllInBound Любой Любой Любой Любой Запрет

На уровне сетевого адаптера существует правило входящего трафика NSG для TCP-адреса 10.81.x.x на порту 80 (выделено в таблице). Однако эквивалентное правило отсутствует в правилах группы безопасности сети на уровне подсети.

Почему AKS не применял правило к пользовательской группе безопасности сети? Так как AKS не применяет группы безопасности сети к своей подсети, и она не будет изменять группы безопасности сети, связанные с этой подсетью. AKS изменит группы безопасности сети только на уровне сетевого адаптера. Дополнительные сведения см. в статье "Можно ли настроить группы безопасности сети с помощью AKS?".

Решение

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

$ curl -Iv http://10.81.x.x
*   Trying 10.81.x.x:80...
* Connected to 10.81.x.x (10.81.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 10.81.x.x left intact

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.