Руководство по устранению неполадок в Kubernetes

Введение

Отладка приложений Kubernetes сродни лабиринту. Учитывая распределенный характер и множество компонентов, для выявления и устранения проблем в Kubernetes требуются надежные инструменты и методы отладки.

А ценные рекомендации по эффективной отладке пригодятся и опытным, и «зеленым» пользователем Kubernetes.

Хотя мы постарались собрать передовые практики и обобщить опыт, авторитетным источником истины остается официальная документация Kubernetes.

Анализ событий жизненного цикла пода

Для отладки и сопровождения приложений, запущенных в Kubernetes, важно понимание жизненного цикла пода. Каждый под проходит несколько этапов  —  от создания до завершения, с помощью анализа этих событий выявляются и устраняются проблемы.

Этапы жизненного цикла пода

Под в Kubernetes проходит такие этапы:

Использование kubectl get и kubectl describe

События жизненного цикла пода анализируются с помощью kubectl get и kubectl describe.

Командой kubectl get предоставляется высокоуровневый обзор состояния подов:

kubectl get pods

Вывод:

NAME              READY   STATUS    RESTARTS   AGE
web-server-pod    1/1     Running   0          5m
db-server-pod     1/1     Pending   0          2m
cache-server-pod  1/1     Completed 1          10m

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

Командой kubectl describe предоставляется подробная информация о поде, включая события жизненного цикла:

kubectl describe pod <pod-name>

Фрагмент вывода:

Name:           web-server-pod
Namespace:      default
Node:           node-1/192.168.1.1
Start Time:     Mon, 01 Jan 2024 10:00:00 GMT
Labels:         app=web-server
Status:         Running
IP:             10.244.0.2
Containers:
  web-container:
    Container ID:   docker://abcdef123456
    Image:          nginx:latest
    State:          Running
      Started:      Mon, 01 Jan 2024 10:01:00 GMT
    Ready:          True
    Restart Count:  0
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  10m   default-scheduler  Successfully assigned default/web-server-pod to node-1
  Normal  Pulled     9m    kubelet, node-1    Container image "nginx:latest" already present on machine
  Normal  Created    9m    kubelet, node-1    Created container web-container
  Normal  Started    9m    kubelet, node-1    Started container web-container

Анализ событий пода

В части Events вывода kubectl describe приводится журнал значимых для пода событий, представленных в хронологическом порядке. По этим событиям разбираются переходы между этапами жизненного цикла и выявляются такие проблемы, как:

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

Журналы событий и аудита Kubernetes

Чтобы быстро просматривать происходящее в кластере, в Kubernetes генерируются внутрикластерные ресурсы событий kind: Event.

Журналами аудита kind: Policy в кластере обеспечиваются совместимость и безопасность, показываются попытки входа, эскалация привилегий подов и многое другое.

События Kubernetes

События Kubernetes представляются временно́й шкалой значимых явлений внутри кластера: планирование подов, перезапуски контейнеров, ошибки. Они важны для понимания переходов между состояниями, выявления первопричин проблем.

Просмотр событий

События в кластере просматриваются командой kubectl get events:

kubectl get events

Пример вывода:

LAST SEEN   TYPE      REASON             OBJECT                                   MESSAGE
12s         Normal    Scheduled          pod/web-server-pod                       Successfully assigned default/web-server-pod to node-1
10s         Normal    Pulling            pod/web-server-pod                       Pulling image "nginx:latest"
8s          Normal    Created            pod/web-server-pod                       Created container web-container
7s          Normal    Started            pod/web-server-pod                       Started container web-container
5s          Warning   BackOff            pod/db-server-pod                        Back-off restarting failed container

Фильтрация событий

События фильтруются по пространствам имен, типам ресурсов или периодам времени. Например, так просматриваются связанные с конкретным подом события:

kubectl get events --field-selector involvedObject.name=web-server-pod

Описание ресурсов

В вывод команды kubectl describe включаются события с подробной информацией о конкретном ресурсе и историей его событий:

kubectl describe pod web-server-pod

Фрагмент вывода:

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  10m   default-scheduler  Successfully assigned default/web-server-pod to node-1
  Normal  Pulled     9m    kubelet, node-1    Container image "nginx:latest" already present on machine
  Normal  Created    9m    kubelet, node-1    Created container web-container
  Normal  Started    9m    kubelet, node-1    Started container web-container

Журналы аудита Kubernetes

В журналах аудита содержится подробная запись обо всех API-запросах, отправленных на сервер API в Kubernetes, включая пользователя, выполненное действие и результат. Эти журналы необходимы для проверки и обеспечения безопасности.

Включение журналирования аудита

Журналирование аудита активируется конфигурированием API-сервера соответствующими флагами и политикой аудита.

Вот пример конфигурации политики аудита:

# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["pods"]
- level: RequestResponse
  users: ["admin"]
  verbs: ["update", "patch"]
  resources:
  - group: ""
    resources: ["configmaps"]

Конфигурирование сервера API

При запуске сервера API указывается расположение файла политики аудита и лог-файла:

kube-apiserver --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kubernetes/audit.log

Просмотр журналов аудита

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

Вот пример записи в журнале аудита:

{
    "kind": "Event",
    "apiVersion": "audit.k8s.io/v1",
    "level": "Metadata",
    "auditID": "12345",
    "stage": "ResponseComplete",
    "requestURI": "/api/v1/namespaces/default/pods",
    "verb": "create",
    "user": {
        "username": "admin",
        "groups": ["system:masters"]
    },
    "sourceIPs": ["192.168.1.1"],
    "objectRef": {
        "resource": "pods",
        "namespace": "default",
        "name": "web-server-pod"
    },
    "responseStatus": {
        "metadata": {},
        "code": 201
    },
    "requestReceivedTimestamp": "2024-01-01T12:00:00Z",
    "stageTimestamp": "2024-01-01T12:00:01Z"
}

Дашборд Kubernetes

Дашборд Kubernetes  —  это веб-интерфейс пользователя для устранения неполадок кластера Kubernetes и легкого управления им: визуализирования ресурсов, развертывания приложений, выполнения административных задач.

Установка

Подробно об установке и доступе к дашборду  —  в документации Kubernetes.

Использование дашборда

Вот функционал дашборда:

1. Обзор кластера и его общего состояния: узлы, пространства имен, потребление ресурсов.
2. Мониторинг и контроль рабочих нагрузок: Deployment, ReplicaSet, StatefulSet, DaemonSet.
3. Управление службами и поступающими ресурсами для контроля сетевого трафика.
4. Управление конфигурациями и хранилищами: ConfigMaps, секреты, запросы на выделение постоянных томов, другие ресурсы хранения.
5. Просмотр журналов и событий в целях аудита и устранения неполадок.

Мониторинг расходования ресурсов

Отлеживая расход ресурсов, проще разобраться с их потреблением в приложении, выявить возможности оптимизации.

Инструменты мониторинга

• kubectl top: предоставляются показатели расходования ресурсов в реальном времени.
• Prometheus: собираются и сохраняются метрики для детального анализа.
• Grafana: визуализируются метрики, предоставляются дашборды для мониторинга.

Применение kubectl top

Командой kubectl top показывается текущий расход ресурсов процессора и памяти в подах и узлах:

kubectl top pods
kubectl top nodes

Пример вывода:

NAME        CPU(cores)   MEMORY(bytes)
my-app-pod  100m         120Mi

kubectl logs

kubectl logs  —  важный инструмент отладчика приложений Kubernetes. Этой командой извлекаются логи из конкретного контейнера пода, эффективно диагностируются и устраняются неполадки.

Базовое применение

Простейший способ извлечь логи из пода  —  указать после команды kubectl logs название пода и пространство имен.

Вот простой пример для пода в пространстве имен default:

kubectl logs <pod-name>

Этой командой извлекаются логи из первого контейнера указанного пода. Если в поде несколько контейнеров, указывается также название контейнера:

kubectl logs <pod-name> -c <container-name>

Логи в реальном времени с флагом -f

Потоковая передача логов в реальном времени, аналогичная tail -f в Linux, выполняется с флагом -f:

kubectl logs -f <pod-name>

Особенно полезно это при мониторинге логов во время выполнения приложения и просмотре вывода текущих процессов.

В проектах вроде Stern возможности отслеживания логов расширяются.

Извлечение предыдущих логов

Логи перезапущенного пода просматриваются из предыдущего экземпляра флагом --previous:

kubectl logs <pod-name> --previous

Изучив логи до момента сбоя, проще понять причины перезапуска пода.

Фильтрация логов с помощью меток

Логи фильтруются по меткам подов с помощью kubectl и jq для расширенной фильтрации:

kubectl get pods -l <label-selector> -o json | jq -r '.items[] | .metadata.name' | xargs -I {} kubectl logs {}

<label-selector> заменяется конкретными метками, например app=myapp.

Сочетание с другими инструментами

Для совершенствования отладки kubectl logs сочетается с другими командами Linux. Например, с grep в логах разыскивается конкретное сообщение об ошибке:

kubectl logs web-server-pod | grep "Error"

А это непрерывный поиск в логах реального времени:

kubectl logs -f web-server-pod | grep --line-buffered "Error"

Практические рекомендации

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

Осуществляйте структурированное логирование, например в формате JSON, упрощая парсинг и анализ логов инструментами вроде jq.

Настройте систему централизованного логирования для агрегации и поиска логов из всех подов Kubernetes, например Elasticsearch, Fluentd и Kibana  —  стек EFK.

kubectl exec

С kubectl exec команды выполняются непосредственно внутри запущенного контейнера. Особенно полезно это при интерактивном устранении неполадок, когда: проверяется среда контейнера, запускаются диагностические команды, в реальном времени вносятся исправления.

Базовое применение

Вот базовый синтаксис kubectl exec:

kubectl exec <pod-name> -- <command>

Команда в конкретном контейнере внутри пода выполняется с флагом -c, сразу после происходит выход из контейнера:

kubectl exec <pod-name> -c <container-name> -- <command>

Запуск интерактивной оболочки

kubectl exec часто применяется для открытия сеанса интерактивной оболочки внутри контейнера и интерактивного выполнения команд:

kubectl exec -it <pod-name> -- /bin/bash

Для контейнеров вместо bash применяется sh:

kubectl exec -it <pod-name> -- /bin/sh

Пример: проверка переменных среды

Переменные среды́ внутри контейнера проверяются командой env:

kubectl exec <pod-name> -- env

Переменные среды́ в конкретном контейнере проверяются так:

kubectl exec <pod-name> -c <container-name> -- env

Пример: проверка конфигурационных файлов

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

kubectl exec <pod-name> -- cat /path/to/config/file

Для конкретного контейнера:

kubectl exec <pod-name> -c <container-name> -- cat /path/to/config/file

Копирование файлов в контейнеры и из контейнеров

Если внутри контейнера нет нужного двоичного файла, его легко скопировать  —  как в контейнеры, так и из них  —  командой kubectl cp.

Например, скопируем в контейнер файл с локального компьютера:

kubectl cp /local/path/to/file <pod-name>:/container/path/to/file

А теперь, наоборот, из контейнера на локальный компьютер:

kubectl cp <pod-name>:/container/path/to/file /local/path/to/file

Практические рекомендации

Используйте -i и -t: с помощью флага -i сеанс делается интерактивным, а флагом -t выделяется псевдо-TTY. Ими вместе -it обеспечивается полностью интерактивный сеанс.

Запускайте от имени конкретного пользователя: при необходимости флагом --user команды выполняются от имени конкретного пользователя внутри контейнера.

kubectl exec --user=<username> -it <pod-name> -- /bin/bash

Учет безопасности: будьте осторожны при запуске kubectl exec с повышенными привилегиями. Чтобы предотвратить несанкционированный доступ, обзаведитесь политиками ролевого управления доступом.

Отладка на уровне узла с kubectl debug

Большинство методов отладки ориентированы на уровень приложения, отладка конкретного узла Kubernetes выполняется командой kubectl debug node.

Отладка на уровне узла важна для диагностики проблем, связанных с самими узлами Kubernetes: исчерпание ресурсов, ошибки в конфигурации или аппаратные сбои.

Итак, отладочным подом получается доступ к корневой файловой системе узла, примонтированного в поде в /host.

Создание сеанса отладки

Командой kubectl debug в узле запускается сеанс отладки, и создается под, которым в этом узле запускается отладочный контейнер:

kubectl debug node/<node-name> -it --image=busybox

<node-name> заменяется названием узла, подлежащего отладке. Флагом -it открывается интерактивный терминал, а посредством --image=busybox указывается образ для отладочного контейнера.

Подробнее  —  в официальной документации Kubernetes по отладке на уровне узла.

Отладка на уровне приложения отладочными контейнерами

Для задач посложнее используется отладочный контейнер с предустановленными инструментами. Из множества хороших образов Docker с инструментарием и скриптами отладки выделяется этот. Он создается быстро:

kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot

Пример: использование отладочного контейнера как дополнительного

apiVersion: apps/v1
   kind: Deployment
   metadata:
       name: nginx-netshoot
       labels:
           app: nginx-netshoot
   spec:
   replicas: 1
   selector:
       matchLabels:
           app: nginx-netshoot
   template:
       metadata:
       labels:
           app: nginx-netshoot
       spec:
           containers:
           - name: nginx
           image: nginx:1.14.2
           ports:
               - containerPort: 80
           - name: netshoot
           image: nicolaka/netshoot
           command: ["/bin/bash"]
           args: ["-c", "while true; do ping localhost; sleep 60;done"]

Применяем конфигурацию:

kubectl apply -f debug-pod.yaml

Практические рекомендации

Задайте в спецификациях подов политики перезапуска для различных сценариев сбоя.

С помощью Prometheus и Alertmanager настройте автоматический мониторинг и оповещение о критических ошибках вроде CrashLoopBackOff.

Временные контейнеры для отладки

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

Преимущества временных подов

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

Создание временных подов

Временные поды создаются в Kubernetes разными способами, один из которых  —  команда kubectl run.

Пример: создание временного пода

Использование kubectl run:

kubectl debug mypod -it --image=nicolaka/netshoot

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

Практические рекомендации по применению временных подов

Доступность инструментов: включите в образ отладочного контейнера все необходимые инструменты для устранения неполадок: curl, netcat, nslookup, df, top и другие.

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

Пример: расширенная отладка с пользовательским отладочным контейнером

Чтобы применить такой контейнер для задач расширенной отладки, создадим временный под с пользовательским отладочным контейнером:

kubectl debug -it redis5 --image=nicolaka/netshoot

Defaulting debug container name to debugger-v4hfv.
If you don't see a command prompt, try pressing enter.
                    dP            dP                           dP
                    88            88                           88
88d888b. .d8888b. d8888P .d8888b. 88d888b. .d8888b. .d8888b. d8888P
88'  `88 88ooood8   88   Y8ooooo. 88'  `88 88'  `88 88'  `88   88
88    88 88.  ...   88         88 88    88 88.  .88 88.  .88   88
dP    dP `88888P'   dP   `88888P' dP    dP `88888P' `88888P'   dP

Welcome to Netshoot! (github.com/nicolaka/netshoot)
Version: 0.13





 redis5  ~ 

Запуск диагностических команд:

Внутри отладочного контейнера запускаются команды.

# Проверяем DNS-разрешение
nslookup kubernetes.default.svc.cluster.local

Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   kubernetes.default.svc.cluster.local
Address: 10.96.0.1

# Тестируем сетевое подключение
curl http://my-service:8080/healthВременными подами эффективно выполняется отладка и устраняются неполадки приложений Kubernetes в изолированной и контролируемой среде, минимизируется риск воздействия на рабочие нагрузки в продакшене.

Решение проблем с DNS и сетью

Разберем два сценария устранения неполадок: проблемы DNS и отладка подов с сохранением состояния  —  и посмотрим, чему мы при этом научимся.

Типичные проблемы с сетью

• Сбои DNS-разрешений: проблемы с преобразованием названий служб в IP-адреса.
• Недостижимая служба: службы недоступны внутри кластера.
• Проблемы взаимодействия подов: поды не могут взаимодействовать друг с другом.
• Ошибки конфигурации в сетевых политиках: из-за некорректных сетевых политик блокируется трафик.

Инструменты и команды для устранения неполадок

kubectl exec: для диагностики сетевых проблем команды запускаются в контейнере.

nslookup: проверяется DNS-разрешение.

ping: тестируется подключение между подами и службами.

curl: проверяются HTTP-соединение и ответы.

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

Пример: диагностика проблемы DNS-разрешения

Продиагностируем проблемы DNS-разрешения при попытке пода my-app-pod подключиться к службе my-db-service.

Проверка DNS-разрешения:

kubectl exec -it my-app-pod -- nslookup my-db-service

Альтернативный вариант: отладочный под или временные контейнеры.

В выводе указывается проблема:

Server: 10.96.0.10
Address:10.96.0.10#53
** server can't find my-db-service: NXDOMAIN

Проверка логов CoreDNS:

Чтобы выявить проблемы с DNS-разрешением, просматриваются логи подов CoreDNS:

kubectl logs -l k8s-app=kube-dns -n kube-system

Ищем ошибки или предупреждения, которыми указывается на сбои DNS-разрешений.

Проверка служб и конечных точек:

Они должны существовать и быть корректно сконфигурированными.

kubectl get svc my-db-service
kubectl get endpoints my-db-service

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
my-db-serviceClusterIP   10.96.0.11   <none>        5432/TCP   1h

NAME         ENDPOINTS            AGE
my-db-service10.244.0.5:5432      1h

Перезапуск подов CoreDNS:

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

kubectl rollout restart deployment coredns -n kube-system

Повторная проверка DNS-разрешения:

Устранив проблему, снова проверяем DNS-разрешение:

kubectl exec -it my-app-pod -- nslookup my-db-service

Ожидаемый вывод:

Server: 10.96.0.10
Address:10.96.0.10#53

Name:   my-db-service.default.svc.cluster.local
Address:10.96.0.11

Практические рекомендации

Для полноценного устранения сетевых отказов используйте контейнеры отладки сети, такие как nicolaka/netshoot:

kubectl run netshoot --rm -it --image nicolaka/netshoot -- /bin/bash

Мониторинг сетевых показателей: с помощью Prometheus и Grafana отслеживайте сетевые показатели и настраивайте оповещения о проблемах с сетью.

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

Отладка приложений с сохранением состояния

Приложениям с сохранением состояния в Kubernetes требуется особое внимание при отладке из-за необходимости в постоянном хранилище и согласованном состоянии при перезапусках. Рассмотрим методы обработки и отладки проблем, характерных для приложений с сохранением состояния.

Что такое «приложения с сохранением состояния»?

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

Типичные проблемы приложений с сохранением состояния

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

Пример: отладка StatefulSet MySQL

Выполним отладку StatefulSet-контроллера MySQL my-mysql.

Просмотр StatefulSet:

kubectl describe statefulset my-mysql

Фрагмент вывода:

Name:           my-mysql
Namespace:      default
Selector:       app=my-mysql
Replicas:       3 desired | 3 total
...
Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  1m    statefulset-controller  create Pod my-mysql-0 in StatefulSet my-mysql successful
  Normal  SuccessfulCreate  1m    statefulset-controller  create Pod my-mysql-1 in StatefulSet my-mysql successful
  Normal  SuccessfulCreate  1m    statefulset-controller  create Pod my-mysql-2 in StatefulSet my-mysql successful

Проверка запросов на выделение постоянных томов:

kubectl get pvc
kubectl describe pvc data-my-mysql-0

Фрагмент вывода:

Name:          data-my-mysql-0
Namespace:     default
Status:        Bound
Volume:        pvc-1234abcd-56ef-78gh-90ij-klmnopqrstuv
...

Проверка логов подов:

kubectl logs my-mysql-0

Фрагмент вывода:

2024-01-01T00:00:00.000000Z 0 [Note] mysqld (mysqld 8.0.23) starting as process 1 ...
2024-01-01T00:00:00.000000Z 1 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11

Выполнение команд в подах:

kubectl exec -it my-mysql-0 -- /bin/sh

Внутри пода:

# Проверяем примонтированные тома
df -h
# Проверяем каталог данных MySQL
ls -l /var/lib/mysql
# Проверяем статус MySQL
mysqladmin -u root -p status

Проверка сетевого подключения:

kubectl exec -it my-mysql-0 -- ping my-mysql-1.my-mysql.default.svc.cluster.local

Фрагмент вывода:

PING my-mysql-1.my-mysql.default.svc.cluster.local (10.244.0.6): 56 data bytes
64 bytes from 10.244.0.6: icmp_seq=0 ttl=64 time=0.047 ms

Продвинутые методы отладки

В Kubernetes это специализированные инструменты и стратегии для диагностики и устранения сложных проблем. Рассмотрим инструментирование трассировок и удаленную отладку.

Профилирование с Jaeger

Jaeger  —  комплексный Open Source инструмент распределенной трассировки для отслеживания и устранения неполадок транзакций в сложных распределенных системах. Благодаря профилированию с Jaeger получается представление о производительности микросервисов, выявляются проблемы с задержкой.

Jaeger устанавливается в кластере Kubernetes с помощью оператора Jaeger или Helm:

helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm repo update
helm install jaeger jaegertracing/jaeger

Инструментирование приложения:

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

Пример в приложении на Go:

import (
    "github.com/opentracing/opentracing-go"
    "github.com/uber/jaeger-client-go"
    "github.com/uber/jaeger-client-go/config"
)
func initJaeger(service string) (opentracing.Tracer, io.Closer) {
    cfg := config.Configuration{
        ServiceName: service,
        Sampler: &config.SamplerConfig{
            Type:  "const",
            Param: 1,
        },
        Reporter: &config.ReporterConfig{
            LogSpans:           true,
            LocalAgentHostPort: "jaeger-agent.default.svc.cluster.local:6831",
        },
    }
    tracer, closer, _ := cfg.NewTracer()
    opentracing.SetGlobalTracer(tracer)
    return tracer, closer
}

Трассировки просматриваются и анализируются в пользовательском интерфейсе Jaeger:

kubectl port-forward svc/jaeger-query 16686:16686

Открывается в браузере http://localhost:16686.

Удаленная отладка с mirrord

Mirrord  —  это Open Source инструмент для удаленной отладки служб Kubernetes, при которой в контексте кластера Kubernetes и удаленной инфраструктуры запускаются локальные процессы.

Настройка mirrord:

curl -fsSL https://raw.githubusercontent.com/metalbear-co/mirrord/main/scripts/install.sh | bash

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

Чтобы подключить локальную среду к кластеру Kubernetes, запускается сеанс mirrord:

mirrord connect

Перенос Deployment:

Следующей командой из кластера в локальную службу переносится Deployment:

mirrord exec --target-namespace devops-team --target deployment/foo-app-deployment nodemon server.js

В итоге трафик, переменные среды́ и файловые операции перенаправляются из кластера Kubernetes на локальный компьютер. А отладка выполняется так, как если бы служба запускалась локально.

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

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

Дополнительные инструменты

Кроме основных команд Kubernetes и Open Source инструментов, доступны и другие средства разных категорий для расширения возможностей по устранению неполадок:

| Название                       | Категория                 | Описание                                                                                                                                        |
|--------------------------------|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
| [Komodor](https://komodor.com) | Устранение неполадок      | Предоставляется полная информация в режиме реального времени с отслеживанием изменений и анализом первопричин для Kubernetes.                   |
| [Robusta](https://robusta.dev) | Реагирование на инциденты | Платформа автоматизированного реагирования на инциденты, интегрируемая с Kubernetes для совершенствования наблюдаемости и устранения неполадок. |
| [Sysdig](https://sysdig.com)   | Мониторинг и безопасность | Облачная платформа для обеспечения видимости и безопасности, глубокого понимания производительности, безопасности, соответствия контейнеров.    |

Заключение

Отладка приложений Kubernetes  —  задача непростая, но при наличии правильных инструментов и методов она становится намного более управляемой.

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

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

Читайте также:

• Возможности Docker, о которых вы не знали. Часть 2
• Шаблон Sidecar-контейнера с Kubernetes и Go
• Развертывание безопасных Java-приложений на AWS EKS с GitLab CI/CD, Maven, Trivy и SonarQube

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи Piotr: The Kubernetes Troubleshooting Handbook