Проверка работоспособности узлов и pod

Эта статья является частью серии. Начните с обзора.

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

Шаг 1: Проверьте работоспособность рабочих узлов

Различные факторы могут способствовать неработоспособной работе узлов в кластере AKS. Одной из распространенных причин является разрыв связи между плоскостью управления и узлами. Это недопонимание часто вызвано неправильными настройками в правилах маршрутизации и брандмауэра.

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

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

В частном кластере AKS проблемы с разрешением системы доменных имен (DNS) могут вызвать проблемы со связью между плоскостью управления и узлами. Необходимо убедиться, что DNS-имя сервера API Kubernetes разрешается в частный IP-адрес сервера API. Неправильная настройка пользовательского DNS-сервера является распространенной причиной сбоев разрешения DNS. Если вы используете пользовательские DNS-серверы, убедитесь, что вы правильно указали их в качестве DNS-серверов в виртуальной сети, где подготавливаются узлы. Также убедитесь, что частный сервер API AKS может быть разрешен с помощью пользовательского DNS-сервера.

После устранения этих потенциальных проблем, связанных с обменом данными уровня управления и разрешением DNS, вы сможете эффективно решать проблемы с работоспособностью узлов в кластере AKS.

Работоспособность узлов можно оценить с помощью одного из следующих методов.

Представление работоспособности контейнеров Azure Monitor

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

1. На портале Azure перейдите к Azure Monitor.
2. В разделе Аналитика области навигации выберите Контейнеры.
3. Выберите Отслеживаемые кластеры , чтобы получить список кластеров AKS, которые отслеживаются.
4. Выберите кластер AKS из списка, чтобы просмотреть работоспособность узлов, пользовательских модулей pod и системных модулей pod.

Представление узлов AKS

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

1. На портале Azure перейдите в кластер AKS.
2. В разделе Параметры области навигации выберите Пулы узлов.
3. Выберите Узлы.
4. Убедитесь, что все узлы находятся в состоянии готовности.

Мониторинг в кластере с помощью Prometheus и Grafana

Если вы развернули Prometheus и Grafana в кластере AKS, вы можете использовать панель мониторинга сведений о кластере K8 для получения аналитических сведений. На этой панели мониторинга отображаются метрики кластера Prometheus и важная информация, такая как загрузка ЦП, использование памяти, сетевая активность и использование файловой системы. В нем также показана подробная статистика для отдельных подов, контейнеров и служб systemd.

На панели мониторинга выберите Условия узла , чтобы просмотреть метрики о работоспособности и производительности кластера. Вы можете отслеживать узлы, у которых могут быть проблемы, такие как проблемы с расписанием, сетью, нагрузкой на диск, нехваткой памяти, нагрузкой на пропорциональную интегральную производную (PID) или дисковым пространством. Отслеживайте эти метрики, чтобы можно было заблаговременно выявлять и устранять любые потенциальные проблемы, влияющие на доступность и производительность кластера AKS.

Управляемый сервис мониторинга для Prometheus и управляемой Azure Grafana

Предварительно созданные панели мониторинга можно использовать для визуализации и анализа метрик Prometheus. Для этого необходимо настроить кластер AKS для сбора метрик в управляемой службе Monitor для Prometheus и подключить рабочую область Monitor к рабочей области Azure Managed Grafana. Эти панели мониторинга предоставляют полное представление о производительности и работоспособности кластера Kubernetes.

Панели управления размещаются в указанном экземпляре Azure Managed Grafana в папке Managed Prometheus. К некоторым панелям мониторинга относятся:

• Kubernetes / Вычислительные ресурсы или кластер
• Kubernetes / Вычислительные ресурсы / Неймспейс (Pods)
• Kubernetes / Вычислительные ресурсы / Узел (Pods)
• Kubernetes / Вычислительные ресурсы / Pod
• Kubernetes / Вычислительные ресурсы / пространство имен (рабочие нагрузки)
• Kubernetes / Вычислительные ресурсы / Рабочая нагрузка
• Kubernetes / Kubelet
• Метод "Экспортер узлов" / "Метод USE" / Node
• Экспортер узлов / Узлы
• Kubernetes / Вычислительные ресурсы / кластер (Windows)
• Kubernetes / Вычислительные ресурсы / неймспейс (Windows)
• Kubernetes / Вычислительные ресурсы / Pod (Windows)
• Kubernetes / USE Method / Cluster (Windows)
• Kubernetes / USE Method / Node (Windows)

Эти встроенные панели мониторинга широко используются в сообществе с открытым кодом для мониторинга кластеров Kubernetes с помощью Prometheus и Grafana. Используйте эти панели мониторинга для просмотра таких метрик, как использование ресурсов, состояния пода и сетевая активность. Вы также можете создавать пользовательские панели мониторинга, адаптированные к вашим потребностям мониторинга. Панели мониторинга помогают эффективно отслеживать и анализировать метрики Prometheus в кластере AKS, что позволяет оптимизировать производительность, устранять проблемы и обеспечивать плавную работу рабочих нагрузок Kubernetes.

Панель мониторинга Kubernetes / Вычислительные ресурсы / Узлы (Pod) позволяет просматривать метрики для узлов агента Linux. Вы можете визуализировать использование ЦП, квоту ЦП, использование памяти и квоту памяти для каждого модуля pod.

Если кластер включает узлы агента Windows, вы можете использовать панель мониторинга Kubernetes / USE Method / Node (Windows) для визуализации метрик Prometheus, собираемых с этих узлов. Эта панель мониторинга предоставляет всестороннее представление о потреблении ресурсов и производительности для узлов Windows в кластере.

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

Шаг 2: Проверьте плоскость управления и подключение рабочего узла

Если рабочие узлы работоспособны, следует проверить подключение между управляемой плоскостью управления AKS и рабочими узлами кластера. AKS обеспечивает обмен данными между сервером API Kubernetes и отдельными узлами kubelets с помощью безопасного метода связи через туннель. Эти компоненты могут взаимодействовать, даже если они находятся в разных виртуальных сетях. Туннель защищен шифрованием Mutual Transport Layer Security (mTLS). Основной туннель, используемый AKS, называется Konnectivity (ранее известный как apiserver-network-proxy). Убедитесь, что все сетевые правила и полные доменные имена соответствуют обязательным сетевым правилам Azure.

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

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

kubectl get deploy konnectivity-agent -n kube-system

Убедитесь, что стручки находятся в готовом состоянии.

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

Выполните следующую команду, чтобы перезапустить konnectivity-agent поды:

kubectl rollout restart deploy konnectivity-agent -n kube-system

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

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

Журналы должны отображать следующие выходные данные:

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

Замечание

Если кластер AKS настроен с интеграцией виртуальной сети с сервером API и сетевым интерфейсом контейнера Azure (CNI) или Azure CNI с динамическим назначением IP-адресов pod, нет необходимости развертывать агенты Konnectivity. Интегрированные серверные модули API могут устанавливать прямую связь с рабочими узлами кластера через частную сеть.

Однако при использовании интеграции виртуальной сети сервера API с наложением Azure CNI или использовании собственного CNI (BYOCNI) Konnectivity развертывается для упрощения обмена данными между серверами API и IP-адресами pod. Связь между серверами API и рабочими узлами остается прямой.

Вы также можете выполнять поиск в журналах контейнера в службе ведения журналов и мониторинга, чтобы получить журналы. Пример поиска ошибок подключения aks-link см. в статье Запросы журналов из аналитики контейнеров.

Выполните следующий запрос, чтобы получить журналы:

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

Выполните следующий запрос для поиска в журналах контейнера любого сбоя модуля pod в определенном пространстве имен:

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

Если вы не можете получить журналы с помощью запросов или средства kubectl, используйте проверку подлинности Secure Shell (SSH). В этом примере модуль pod tunnelfront обнаруживается после подключения к узлу по SSH.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

Шаг 3: Проверка разрешения DNS при ограничении исходящего трафика

Разрешение DNS является важным аспектом кластера AKS. Если разрешение DNS работает неправильно, это может привести к ошибкам уровня управления или сбоям извлечения образов контейнеров. Чтобы убедиться, что разрешение DNS на сервер API Kubernetes работает правильно, выполните следующие действия:

1. Выполните команду kubectl exec, чтобы открыть командную оболочку в контейнере, который выполняется в модуле pod.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. Проверьте, установлены ли в контейнере инструменты nslookup или dig .

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

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. Адрес сервера API можно получить на странице обзора кластера AKS на портале Azure или выполнить следующую команду.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. Выполните следующую команду, чтобы попытаться разрешить сервер API AKS. Дополнительные сведения см. в статье Устранение неполадок при разрешении DNS изнутри модуля pod, но не с рабочего узла.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. Проверьте верхний DNS-сервер из pod, чтобы определить, работает ли разрешение DNS правильно. Например, для Azure DNS выполните nslookup команду.

   nslookup microsoft.com 168.63.129.16
   

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

8. Если разрешение DNS успешно выполнено с узла, но не с пода, проблема может быть связана с DNS Kubernetes. Инструкции по отладке разрешения DNS из модуля pod см. в статье Устранение неполадок при сбоях разрешения DNS.

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

Шаг 4: Проверьте наличие ошибок kubelet

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

Рабочая тетрадь AKS kubelet

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

1. Перейдите в свой кластер AKS на портале Azure.

2. В разделе Мониторинг области навигации выберите Книги.

3. Выберите книгу Kubelet .

   

4. Выберите Операции и убедитесь, что операции для всех рабочих узлов завершены.

   

Мониторинг в кластере с помощью Prometheus и Grafana

Если вы развернули Prometheus и Grafana в кластере AKS, вы можете использовать панель мониторинга Kubernetes / Kubelet для получения аналитических сведений о работоспособности и производительности отдельных узлов kubelets.

Управляемый сервис мониторинга для Prometheus и управляемой Azure Grafana

Вы можете использовать предварительно настроенный дашборд Kubernetes / Kubelet для визуализации и анализа метрик Prometheus для kubelets рабочего узла. Для этого необходимо настроить кластер AKS для сбора метрик в управляемой службе Monitor для Prometheus и подключить рабочую область Monitor к рабочей области Azure Managed Grafana.

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

Шаг 5: Используйте инструмент обнаружения проблем с узлами (NPD) для проверки работоспособности узла

NPD — это инструмент Kubernetes, который можно использовать для выявления проблем, связанных с узлами, и создания отчетов о них. Он работает как служба systemd на каждом узле в кластере. Он собирает метрики и системную информацию, такую как загрузка ЦП, использование диска и состояние подключения к сети. При обнаружении проблемы инструмент NPD формирует отчет о событиях и состоянии узла. В AKS средство NPD используется для мониторинга и управления узлами в кластере Kubernetes, размещенном в облаке Azure. Дополнительные сведения см. в статье NPD в узлах AKS.

Шаг 6: Проверьте количество операций ввода-вывода в секунду на диске (IOPS) на предмет регулирования

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

Книга дискового ввода-вывода узла AKS

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

1. Перейдите в свой кластер AKS на портале Azure.

2. В разделе Мониторинг области навигации выберите Книги.

3. Выберите книгу ввода-вывода диска узла .

   

4. Просмотрите метрики, связанные с вводом-выводом.

   

Мониторинг в кластере с помощью Prometheus и Grafana

Если вы развернули Prometheus и Grafana в кластере AKS, вы можете использовать панель мониторинга метода USE или узла , чтобы получить аналитические сведения о дисковом вводе-выводе для рабочих узлов кластера.

Управляемый сервис мониторинга для Prometheus и управляемой Azure Grafana

Вы можете использовать предварительно созданную панель мониторинга Node Exporter / Nodes для визуализации и анализа метрик, связанных с дисковым вводом-выводом, от рабочих узлов. Для этого необходимо настроить кластер AKS для сбора метрик в управляемой службе Monitor для Prometheus и подключить рабочую область Monitor к рабочей области Azure Managed Grafana.

IOPS и диски Azure

Физические устройства хранения имеют неотъемлемые ограничения с точки зрения пропускной способности и максимального количества файловых операций, которые они могут обрабатывать. Диски Azure используются для хранения операционной системы, которая работает на узлах AKS. На диски распространяются те же ограничения физического хранилища, что и на операционную систему.

Рассмотрим концепцию пропускной способности. Можно умножить средний размер операций ввода-вывода на количество операций ввода-вывода в секунду, чтобы определить пропускную способность в мегабайтах в секунду (МБ/с). Большие размеры операций ввода-вывода приводят к меньшему количеству операций ввода-вывода в секунду из-за фиксированной пропускной способности диска.

Когда рабочая нагрузка превышает максимальные ограничения службы операций ввода-вывода в секунду, назначенные дискам Azure, кластер может перестать отвечать и перейти в состояние ожидания ввода-вывода. В системах на базе Linux многие компоненты, такие как сетевые сокеты, CNI, Docker и другие службы, зависящие от сетевого ввода-вывода, обрабатываются как файлы. Следовательно, если диск не может быть прочитан, сбой распространяется на все эти файлы.

Регулирование операций ввода-вывода в секунду может быть вызвано несколькими событиями и сценариями, в том числе:

• Значительное количество контейнеров, которые работают на узлах, так как ввод-вывод Docker использует диск операционной системы.

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

• События отработки отказа узла и периодические задания, которые увеличивают рабочую нагрузку или увеличивают количество модулей pod. Такая повышенная нагрузка повышает вероятность возникновения дросселирования, что может привести к переходу всех узлов в неготовое состояние до завершения операций ввода-вывода.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Паоло Сальватори | Главный инженер клиента
• Фрэнсис Сими Назарет | Старший технический специалист

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

• Ограничения на диск виртуальной машины
• Производительность виртуальных машин и дисков

Связанные ресурсы

Мониторинг развертываний рабочих нагрузок