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

Устранение неполадок подключения к приложению, размещенного в кластере AKS

  • Статья

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

Примечание.

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

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

Факторы, которые следует учитывать

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

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

  • Что такое источник и назначение для запроса?

  • Что такое прыжки между источником и назначением?

  • Что такое поток ответа на запрос?

  • Какие прыжки имеют дополнительные уровни безопасности сверху, такие как следующие элементы:

    • Брандмауэр
    • Группа безопасности сети (NSG)
    • Политика сети

При проверке каждого компонента получите и проанализируйте коды ответов HTTP. Эти коды полезны для выявления характера проблемы и особенно полезны в сценариях, в которых приложение отвечает на HTTP-запросы.

Если другие действия по устранению неполадок не предоставляют никаких убедительных результатов, выполните захват пакетов с клиента и сервера. Записи пакетов также полезны, если трафик, отличный от HTTP, участвует между клиентом и сервером. Дополнительные сведения о сборе записей пакетов для среды AKS см. в следующих статьях в руководстве по сбору данных:

Знание того, как получить коды http-ответов и принимать записи пакетов, упрощает устранение неполадок с сетевым подключением.

Базовый сетевой поток для приложений в AKS

Как правило, если приложения предоставляются с помощью типа службы Azure Load Balancer, поток запросов для доступа к ним выглядит следующим образом:

Dns-имя >> КЛИЕНТА >> AKS подсистемы >> балансировки нагрузки IP-адрес >> узлов AKS pod

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

  • Управляемый входящий трафик NGINX с функцией надстройки маршрутизации приложений включен.
  • Шлюз приложений используется с помощью Шлюз приложений контроллера входящего трафика (AGIC) вместо Azure Load Balancer.
  • Azure Front Door и Управление API могут использоваться поверх подсистемы балансировки нагрузки.
  • В процессе используется внутренняя подсистема балансировки нагрузки.
  • Подключение может не заканчиваться в модуле pod и запрошенным URL-адресом. Это может зависеть от того, может ли модуль pod подключаться к другой сущности, например базе данных или любой другой службе в том же кластере.

Важно понимать поток запросов для приложения.

Базовый поток запросов к приложениям в кластере AKS будет похож на поток, показанный на следующей схеме.

Схема базового потока запросов к приложениям в кластере Служба Azure Kubernetes (A K S).

Устранение неполадок внутри сети

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

Шаг 1. Проверка правильности выполнения модуля pod и приложения или контейнера внутри модуля pod

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

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

Что делать, если модуль pod не запущен? В этом случае проверьте события pod с помощью команды kubectl описать :

kubectl describe pod <pod-name> -n <namespace-name>

Если модуль pod не в состоянии Ready или Running не перезагружается много раз, проверьте выходные kubectl describe данные. В событиях будут выявлены все проблемы, которые препятствуют запуску модуля pod. Или, если модуль pod запущен, приложение внутри модуля pod может завершиться ошибкой, что приведет к перезапуску модуля pod. Устраните неполадки pod соответствующим образом, чтобы убедиться, что он находится в подходящем состоянии.

Если модуль pod запущен, его также можно использовать для проверки журналов контейнеров, находящихся в модуле pod. Выполните следующую серию команд kubectl logs :

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous

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

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

Для приложений, прослушивающих другие протоколы, можно установить соответствующие средства в тестовом модуле, например в средстве netcat, а затем проверить подключение к pod приложения, выполнив следующую команду:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Дополнительные команды для устранения неполадок с модулями pod см. в разделе Отладка запущенных модулей pod.

Шаг 2. Проверка доступности приложения из службы

В сценариях, в которых выполняется приложение в модуле pod, можно сосредоточиться главным образом на устранении неполадок, предоставляемых модулем pod.

Предоставляется ли модуль pod как услуга? В этом случае проверьте события службы. Кроме того, проверьте, доступен ли IP-адрес pod и порт приложения в качестве конечной точки в описании службы:

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Проверьте, присутствует ли IP-адрес pod в качестве конечной точки в службе, как показано в следующем примере:

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Если конечные точки не указывают на правильный IP-адрес pod, проверьте Labels и Selectors для pod и службы.

Правильны ли конечные точки в службе? В этом случае получите доступ к службе и проверьте, доступно ли приложение.

Доступ к службе ClusterIP

ClusterIP Для службы можно запустить тестовый модуль pod в кластере и получить доступ к IP-адресу службы:

Схема использования тестового модуля pod в кластере Служба Azure Kubernetes (K S) для доступа к ip-адресу кластера. 

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Для приложений, прослушивающих другие протоколы, можно установить соответствующие средства в тестовом модуле, например в средстве netcat, а затем проверить подключение к pod приложения, выполнив следующую команду:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

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

Доступ к службе LoadBalancer

LoadBalancer Для службы можно получить доступ к IP-адресу подсистемы балансировки нагрузки извне кластера.

Схема тестового пользователя, обращаюющегося к ip-адресу подсистемы балансировки нагрузки за пределами кластера Служба Azure Kubernetes (A K S). 

curl -Iv http://<service-ip-address>:<port>

Для приложений, прослушивающих другие протоколы, можно установить соответствующие средства в тестовом модуле, например в средстве netcat, а затем проверить подключение к pod приложения, выполнив следующую команду:

nc -z -v <pod-ip-address> <port>

LoadBalancer Возвращает ли IP-адрес службы правильный ответ? Если это не так, выполните следующие действия.

  1. Проверьте события службы.

  2. Убедитесь, что группы безопасности сети (NSG), связанные с узлами AKS и подсетью AKS, разрешают входящий трафик через порт службы.

Дополнительные команды для устранения неполадок служб см. в разделе "Отладка служб".

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

В сценариях, в которых приложение предоставляется с помощью Ingress ресурса, поток трафика выглядит следующим образом:

Подсистема балансировки нагрузки dns >> клиента >> или ip-адреса >> шлюза приложений контроллера Ingress в службе кластера >> или модулях pod

Схема потока сетевого трафика, когда приложение в кластере Служба Azure Kubernetes (A K S) предоставляется с помощью ресурса входящего трафика.

Здесь также можно применить внутренний подход к устранению неполадок. Дополнительные сведения см. также в ресурсе kubernetes ingress и контроллере входящего трафика:

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

В этом примере содержится Ingress ресурс, который:

  • Прослушивает myapp.com узел.
  • Имеет две Path строки, настроенные.
  • Маршруты к двум Services в задней части.

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

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP

Проверьте журналы для модулей pod контроллера входящего трафика, если возникла ошибка:

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

Что делать, если клиент выполняет запросы на имя узла входящего трафика или IP-адрес, но в журналах модуля pod контроллера входящего трафика не отображаются записи? В этом случае запросы могут не достигать кластера, и пользователь может получить сообщение об ошибке Connection Timed Out .

Еще одна возможность заключается в том, что компоненты на вершине модулей pod ingress, например Load Balancer или Шлюз приложений, не перенаправляют запросы в кластер правильно. Если это верно, можно проверить конфигурацию серверной части этих ресурсов.

Если появится сообщение об ошибке Connection Timed Out , проверьте группу безопасности сети, связанную с узлами AKS. Кроме того, проверьте подсеть AKS. Это может быть блокировка трафика от подсистемы балансировки нагрузки или шлюза приложений к узлам AKS.

Дополнительные сведения об устранении неполадок входящего трафика (например, Nginx Ingress) см. в статье об устранении неполадок ingress-nginx.

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

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

Заявление об отказе от ответственности за контактные данные сторонней организации

Корпорация Майкрософт предоставляет контактные данные сторонних производителей в целях получения дополнительных сведений по данной теме. Эти данные могут быть изменены без предварительного уведомления. Корпорация Майкрософт не гарантирует точность контактных данных сторонних производителей.