Анализ стратегии перезапуска Kubernetes Pod и проверка работоспособности

использоватьKubernetesОдним из основных преимуществ Kubernetes является его способность управлять и поддерживать контейнеры в кластере, обеспечивая практически нулевое время простоя службы. созданиеPodПосле источника ресурсов,KubernetesДля него будет выбран рабочий узел, а затем запланирован запуск на узле.Podконтейнер в.KubernetesМощные функции обеспечивают непрерывную работу контейнеров вашего приложения, и вы можете автоматически масштабировать свою систему по мере роста спроса. Помимо того, что вPodили когда контейнер выходит из строяKubernetesЭто также может позволить системе достичь «самовосстановления». В этой статье мы расскажем, как использоватьKubernetesВстроенныйlivenessProbeа такжеreadinessProbeдля управления и контроля работоспособности приложения.

Стратегия перезапуска модуля

KubernetesЧасть его собственной способности восстановления системы должна полагаться наPod, стратегия перезапуска также называетсяrestartPolicy. этоPodизSpecЧасть стандартного поля (pod.spec.restartPolicy), значение по умолчанию — «Всегда», то есть каждый раз, когда в контейнере возникает исключение, его необходимо создавать заново.

Вы можете изменить политику восстановления Pod, установив restartPolicy. В дополнение к Always у него также есть OnFailure и Never.

• Всегда: в любом случае, пока контейнер не запущен, он автоматически перезапускается;
• OnFailure: автоматически перезапускать контейнер, только если он неисправен;
• Никогда: никогда не перезапускать контейнер.

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

Для Pod, содержащего несколько контейнеров, Pod перейдет в состояние Failed только после того, как все контейнеры в нем перейдут в ненормальное состояние. До этого Pods находились в состоянии Running. На этом этапе в поле READY пода будет отображаться количество обычных контейнеров, например:

$ kubectl get pod test-liveness-exec
NAME           READY     STATUS    RESTARTS   AGE
liveness-exec   0/1       Running   1          1m

Если в поде есть только один контейнер, то контейнер выходит из строя ненормально. Затем, только когда restartPolicy=Never, Pod перейдет в состояние Failed. В других случаях, поскольку Kubernetes может перезапустить контейнер, состояние пода сохраняется.RunningБез изменений, информация о RESTARTS учтенаPodколичество перезапусков. Следует отметить, что хотя это и перезапуск, за ним на самом деле стоитKubernetesЗаменил старый контейнер воссозданным контейнером.

Как Pod достигает самоисцеления?

будетPodПосле планирования на узле Kubelet на узле запустит в нем контейнер, иPodдержать их в рабочем состоянии в течение их жизни. Если происходит сбой основного процесса контейнера,kubeletКонтейнер будет перезапущен. Однако, если приложение внутри контейнера выдает ошибку, из-за которой оно продолжает перезапускаться, тогдаKubernetesиспользуя правильные диагностические процедуры и следуяPodперезапустите стратегию, чтобы исправить это.

KubernetesСуществует два типа проверок работоспособности, на которые можно ответить:

• Живучесть: проверка живучести,kubeletИспользуйте статус возврата живости зонда (livenessProbe) в качестве основы для перезапуска контейнера. Зонд Liveness используется для обнаружения проблем с контейнером во время работы приложения. После перехода контейнера в это состояниеPodузлаkubeletв состоянии пройтиPodстратегия перезапуска контейнера.

• Готовность: проверка готовности, этот тип проверки (readinessProbe) используется для определения того, готов ли контейнер принимать трафик. Вы можете использовать этот зонд для управления тем, какиеPodБудет использоваться в качестве бэкенда сервиса. еслиPodЕще не готово, удалите его из списка бэкендов сервиса.

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

обработчик зонда

Для проверки здоровьяPodпровести диагностику состояния здоровьяkubeletВызываются обработчики, реализованные для зонда в контейнере, и эти обработчики делятся на три категории:

• Exec: выполнить команду внутри контейнера.
• TCPSocket: выполняет TCP-проверку IP-адреса контейнера на указанном порту.
• HTTPGet: выполните HTTP-запрос GET для IP-адреса контейнера.

Статус возврата обработчика также делится на три типа:

• Успех: Контейнер прошел диагностику.
• Сбой: контейнер не прошел диагностику.
• Неизвестно: диагностика не удалась, статус не определен, никаких действий предприниматься не будет.

После разговора о типах и возвращаемых значениях программ-зондов давайте взглянем на варианты использования этих двух зондов.

Случаи применения

И живость, и готовность зондов находятся вPodизYAMLконфигурация в файле. Каждый тип имеет разные варианты использования.

livenessProbe

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

Например, включите в контейнер датчик живучести Exec, чтобы определить, когда приложение переходит вBrokenгосударство.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

этоYAMLопределить один контейнерPod. это говоритkubeletПервая проверка работоспособности (initialDelaySeconds: 5) выполняется через 5 секунд после запуска контейнера и затем каждые 5 секунд (periodSeconds: 5).kubeletВыполните команду «cat /tmp/healthy» в контейнере, в случае успеха он вернет 0, что означает, что он исправен. Если он возвращает ненулевое значение, тоkubeletубьет контейнер и перезапустит его.

Этот пример приведен в официальном туториале.Помимо выполнения команд в контейнере, в туториале также приводится livenessProbe, который инициирует HTTP или TCP запросы:

...
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

    ...
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Больше примеров можно найти в официальном туториале, ссылка:Что особенного.IO/docs/tasks/…

readinessProbe

Зонды готовности выполняют те же проверки, что и зонды живучести (запросы GET, TCP-соединения и выполнение команд). Однако корректирующие действия бывают разными. Он не будет перезапускать контейнеры, не прошедшие проверку.Pod, но изServiceверхнее удалениеPod, чтобы временно изолировать его от трафика.

Например, есть один изPodМожет выполняться много вычислений или тяжелых операций, что увеличивает задержку ответа службы. Давайте определим пробу готовности, которая будет отвечать на запросы GET более чем за две секунды, с помощью параметра проверки timeoutSeconds.Podне здоров

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: k8s.gcr.io/liveness
     name: liveness
     ports:
       - containerPort: 8080
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 8080
       timeoutSeconds: 2

Когда время отклика зонда превышает две секунды, kubelet не перезапускает под, а направляет трафик на другие исправныеPodначальство. Подожди покаPodПосле того, как перегрузки больше нетkubeletбудетPodдобавить обратно к оригиналуServiceсередина.

Суммировать

по умолчанию,KubernetesОбеспечивает две проверки работоспособности: readinessProbe и livenessProbe. Все они используют один и тот же тип обработчика тестов (HTTP GET-запрос, TCP-соединение и выполнение команды). они не проходят проверкуPodПредпринимаемые корректирующие действия различны. livenessProbe перезапустит контейнер, и после ожидаемого перезапуска ошибка больше не возникает. readinessProbe будет изолировать поды от трафика до тех пор, пока не исчезнет причина сбоя.

через тот жеPodЭти две проверки работоспособности используются для того, чтобы гарантировать, что трафик не достигнет неготовогоPod, и убедитесьPodВозможность перезапуска в случае сбоя.

Хороший дизайн приложения должен одновременно регистрировать достаточно информации, особенно при возникновении исключений. Он также должен предоставлять необходимые конечные точки API, которые будут передавать важные показатели работоспособности и состояния для использования системами мониторинга, такими как Prometheus.

Ссылка на ссылку:

kubernetes-best-practices-health-probes

liveness-and-readiness-probes-in-kubernetes