Облачная платформаAdvanced

Настройка Container Health Check

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Сценарий

Health check регулярно проверяет состояние контейнеров, когда контейнеры работают. Если health check не настроен, pod не может обнаружить исключения приложения или автоматически перезапустить приложение для его восстановления. В результате pod может находиться в состоянии Running, но приложение недоступно или работает аномально.

Kubernetes предоставляет три типа проб health check для мониторинга приложений в контейнерах с целью обеспечения стабильности системы и высокой доступности.
  • Liveness probe: проверяет, живой ли контейнер. Это аналог команды ps, которая проверяет наличие процесса. Если liveness probe не проходит, кластер перезапускает контейнер. Если liveness probe проходит успешно, дальнейших действий не требуется.
  • Readiness probe: проверяет, готово ли приложение в контейнере принимать трафик. В некоторых сценариях приложение запущено, но не готово предоставлять услуги, потому что необходимо загрузить большой объём данных с диска или инициализировать внешние сервисы. В этом случае можно использовать readiness probe, чтобы предотвратить маршрутизацию трафика к приложению. Если readiness probe не проходит, кластер CCE временно удаляет контейнер из списка эндпоинтов Service, блокируя внешние запросы. Если readiness probe проходит успешно, контейнер считается готовым и может принимать трафик.
  • Startup probe: проверяет, запущено ли приложение в контейнере. Кластер запускает проверки liveness и readiness только после успешного прохождения startup probe, чтобы убедиться, что проверки не влияют на запуск приложения. Такой тип проб хорошо подходит для контейнеров, которым требуется длительное время для старта. Они эффективно предотвращают ошибочное признание контейнеров аномальными и их завершение до завершения инициализации.

Для получения дополнительной информации см. Liveness, Readiness, and Startup Probes и Configuring Liveness, Readiness and Startup Probes.

Настройка Liveness Probes

Liveness probe обнаруживает проблемы, когда контейнер работает, но не отвечает, например, взаимные блокировки.

Через консоль

  1. Войдите в CCE console.
  2. При создании рабочей нагрузки выберите Health Check в разделе Container Information.
  3. Включите liveness probe.
    Table 1 Probe parameters

    Check Method

    Description

    Specific Parameter

    Common Parameter

    HTTP (httpGet)

    Этот метод применяется к контейнерам, которые предоставляют сервисы HTTP или HTTPS. Кластер периодически отправляет HTTP/HTTPS GET‑запрос к конечной точке целевого контейнера. Если код статуса ответа находится в диапазоне 200–399, зонд считается успешным. Если код статуса ответа находится вне этого диапазона, зонд завершается с ошибкой, и kubelet останавливает и перезапускает контейнер.

    • Path: HTTP или HTTPS путь для проверки, определённый образом образа контейнера. Он должен быть абсолютным путём, начинающимся со слеша (/).
    • Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.
    • Host Address: IP‑адрес целевого хоста для запроса. Если не указано, по умолчанию используется IP‑адрес pod.
    • Protocol: протокол, используемый для запроса. Он должен соответствовать протоколу, предоставляемому сервисом контейнера.
    • Request Header: HTTP или HTTPS заголовок, включаемый в запрос, задаётся как пара ключ‑значение.
    • Period (periodSeconds): интервал между проверками зонда, в секундах.

      Например, если этот параметр установлен в 30, проверка состояния выполняется каждые 30 секунд.
    • Delay (initialDelaySeconds): период ожидания запуска контейнера перед началом проверок состояния, в секундах.

      Например, если этот параметр установлен в 30, проверка состояния начинается через 30 секунд после запуска контейнера.
    • Timeout (timeoutSeconds): максимальное время ожидания ответа пробой, в секундах. Если установлено 0 или оставлено пустым, будет использовано значение по умолчанию (1).

      Например, если этот параметр установлен в 10, таймаут проверки состояния составляет 10 секунд. Проба завершается неудачей, если ответ занимает более 10 секунд.
    • Success Threshold (successThreshold): минимальное количество последовательных успешных проб, необходимое для пометки контейнера как здорового после сбоя. Значение по умолчанию — 1, которое также является минимальным. Этот параметр должен быть установлен в 1 для проб живости и запуска.

      Например, если этот параметр установлен в 1, контейнер восстанавливается после одной успешной пробы после сбоя.
    • Failure Threshold (failureThreshold): количество последовательных неудачных проб до пометки контейнера как нездорового. Значение по умолчанию — 3, минимальное значение — 1.

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

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

    TCP (tcpSocket)

    Этот метод применяется к контейнерам, которые предоставляют TCP‑службы (например, базы данных, кэши и пользовательские TCP‑приложения). Кластер периодически пытается установить TCP‑соединение с целевым контейнером. Если соединение успешно, проба считается здоровой. В противном случае проба завершается неудачей, и kubelet останавливает и перезапускает контейнер.

    Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: 1‑65535.

    Command (exec)

    Необходимо указать исполняемую команду, которую кластер будет периодически запускать внутри контейнера. Если команда завершается с кодом 0, проба считается успешной. В противном случае проба завершается неудачей, и kubelet останавливает и перезапускает контейнер.

    CAUTION:

    Избегайте проб, основанных на командах, в средах с высокой нагрузкой, так как они потребляют системные ресурсы. Когда ресурсы ограничены, например при высокой загрузке CPU или конкуренции за блокировки файловой системы, пробы могут истекать по времени и завершаться неудачей. Если их необходимо использовать, следуйте этим рекомендациям:
    • Увеличьте порог неудач и таймаут, чтобы предотвратить срабатывание проб из‑за кратковременных всплесков нагрузки. Однако это снижает чувствительность обнаружения реальных нездоровых состояний, поэтому настраивайте консервативно.
    • Установите правильные ограничения CPU для сервисных контейнеров и системных дополнений. В противном случае голодание по квантам времени может удерживать блокировки ядра и блокировать exec probes на всех pod‑ах узла.

    Command: команда, выполняемая внутри контейнера для проверки его состояния. Вводите несколько команд в отдельных строках.

    ПРИМЕЧАНИЕ:
    • Перед использованием этого метода необходимо упаковать требуемые программы и инструменты в образ контейнера. Кластер выполняет команды непосредственно в контейнере. Файловые системы Host и файловые системы других контейнеров недоступны. Если зависимые программы или инструменты (например, curl, nc или пользовательские скрипты) не включены в образ, будет отображено сообщение об ошибке "Command not found".
    • Если выполняется shell‑скрипт, необходимо указать интерпретатор скрипта. Кластер не предоставляет интерактивный терминал, поэтому скрипты нельзя запускать напрямую. Нужно использовать интерпретатор для вызова скрипта. Например, если скрипт находится в /data/scripts/health_check.sh, следует выполнить sh /data/scripts/health_check.sh.

    gRPC Check (grpc)

    Этот метод применяется к gRPC‑приложениям. HTTP‑портов или внешних скриптов не требуется. Проверки состояния используют стандартные gRPC API.

    Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.

  4. Настройте остальные параметры и нажмите Create Workload в правом нижнем углу. Если workload находится в состоянии Running, проверка состояния считается успешной.

Через YAML

  1. Используйте kubectl для доступа к кластеру. Подробности см. в Accessing a Cluster Using kubectl.
  2. Создайте YAML‑файл для настройки workload. В этом примере имя файла — health_check.yaml. При необходимости его можно изменить.

    vim health_check.yaml

    Ниже приведён пример с HTTP‑запросом. Подробности о других методах проверок состояния см. в Configuring Liveness, Readiness and Startup Probes. Содержимое файла:

     
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
          version: v1
      template:
        metadata:
          labels:
            app: nginx
            version: v1
        spec:
          containers:
            - name: container-1
              image: nginx:latest
               livenessProbe :                 # The liveness probe
                httpGet:                     # HTTP requests are used to check container health.
                  path: /                    # The HTTP health check path
                  port: 80                   # The health check port is  80 .
                  host: ''                   # The host address, which defaults to the pod IP address
                  scheme: HTTP               # The health check protocol
                  httpHeaders:               # (Optional) The request header name is  Custom-Header , and the value is  Awesome .
                  - name: Custom-Header
                    value: Awesome
                initialDelaySeconds: 3       # The grace period for container startup before health checks begin, in seconds
                timeoutSeconds: 1            # The probe timeout, in seconds
                periodSeconds: 3             # The probe check period, in seconds
                successThreshold: 1          # The minimum consecutive successful probes required to mark a container healthy after a failure
                failureThreshold: 3          # The minimum consecutive probe failures before marking a container unhealthy
          imagePullSecrets:
            - name: default-secret

  3. Создайте workload.

    kubectl create -f health_check.yaml

    Если отображается информация, аналогичная следующей, workload создаётся:

     
    deployment.apps/nginx created

  4. Проверьте pod рабочей нагрузки.

    kubectl get pod

    Если статус pod Running, рабочая нагрузка создана.

     
    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-58cdd4f48d-jcsqn   1/1     Running   0          4m19s

Настройка Readiness Probes

Readiness probe определяет, готовы ли контейнеры pod к получению трафика. Pod присоединяется к конечным точкам Service для получения трафика только после того, как все его контейнеры готовы.

Через Console

  1. Войдите в CCE console.
  2. При создании рабочей нагрузки выберите Health Check в Container Information.
  3. Включите readiness probe.
    Table 2 Probe parameters

    Check Method

    Description

    Specific Parameter

    Common Parameter

    HTTP (httpGet)

    Этот метод применяется к контейнерам, которые предоставляют HTTP или HTTPS сервисы. Кластер периодически отправляет HTTP/HTTPS GET‑запрос к конечной точке целевого контейнера. Если код статуса ответа находится в диапазоне 200–399, probe считается успешным. Если код статуса ответа находится вне этого диапазона, probe завершается с ошибкой, и kubelet останавливает и перезапускает контейнер.

    • Path: HTTP или HTTPS путь, который проверяется, как определено в образе контейнера. Должен быть абсолютным путём, начинающимся со слеша (/) .
    • Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.
    • Host Address: IP‑адрес целевого хоста для запроса. Если не указано, по умолчанию используется IP‑адрес pod.
    • Protocol: протокол, используемый для запроса. Он должен соответствовать протоколу, открытом сервисом контейнера.
    • Request Header: HTTP или HTTPS заголовок, включаемый в запрос, задаётся как пара ключ‑значение.
    • Period (periodSeconds): интервал между проверками проб, в секундах.

      Например, если этот параметр установлен в 30, проверка состояния выполняется каждые 30 секунд.
    • Delay (initialDelaySeconds): период ожидания запуска контейнера до начала проверок состояния, в секундах.

      Например, если этот параметр установлен в 30, проверка состояния начинается через 30 секунд после запуска контейнера.
    • Timeout (timeoutSeconds): максимальное время ожидания ответа проб, в секундах. Если установлено значение 0 или оставлено пустым, будет использовано значение по умолчанию (1).

      Например, если этот параметр установлен в 10, тайм‑аут проверки состояния составляет 10 секунд. Проба считается неуспешной, если ответ занимает более 10 секунд.
    • Success Threshold (successThreshold): минимальное количество последовательных успешных проб, необходимое для пометки контейнера как здорового после сбоя. Значение по умолчанию — 1, которое также является минимальным. Для проб liveness и startup этот параметр должен быть установлен в 1.

      Например, если этот параметр установлен в 1, контейнер восстанавливается после одной успешной пробы после сбоя.
    • Failure Threshold (failureThreshold): количество последовательных неудачных проб, после которых контейнер считается нездоровым. Значение по умолчанию — 3, минимальное значение — 1.

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

      Для проверок готовности, если количество последовательных сбоев достигает этого порога, pod помечается как неготовый и удаляется из Service endpoints. В этом случае контейнер не получает новый трафик, но не перезапускается.

    TCP (tcpSocket)

    Этот метод применяется к контейнерам, которые предоставляют TCP‑сервисы (например, базы данных, кэши и пользовательские TCP‑приложения). Кластер периодически пытается установить TCP‑соединение с целевым контейнером. Если соединение успешно, проверка считается здоровой. В противном случае проверка не проходит, и kubelet останавливает и перезапускает контейнер.

    Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: 1 до 65535.

    Command (exec)

    Необходимо указать исполняемую команду, которую кластер будет периодически запускать внутри контейнера. Если команда завершается с кодом 0, проверка считается успешной. В противном случае проверка не проходит, и kubelet останавливает и перезапускает контейнер.

    CAUTION:

    Избегайте проверок, основанных на командах, в средах с высокой нагрузкой, так как они потребляют системные ресурсы. Когда ресурсы ограничены, например при высокой загрузке CPU или конкуренции за блокировки файловой системы, проверки могут истекать по времени и завершаться с ошибкой. Если их необходимо использовать, следуйте этим рекомендациям:
    • Увеличьте порог сбоев и тайм‑аут, чтобы предотвратить срабатывание проверок из‑за кратковременных всплесков нагрузки. Однако это снижает чувствительность обнаружения реальных нездоровых состояний, поэтому настраивайте консервативно.
    • Установите корректные ограничения CPU для сервисных контейнеров и системных аддонов. В противном случае голодание по времени может удерживать блокировки ядра и блокировать exec‑проверки во всех pod‑ах на узле.

    Command: команда, выполняемая внутри контейнера для проверки его состояния. Вводите несколько команд в отдельных строках.

    NOTE:
    • Перед использованием этого метода необходимо включить требуемые программы и инструменты в образ контейнера. Кластер выполняет команды непосредственно в контейнере. Файловые системы хоста и других контейнеров недоступны. Если зависимые программы или инструменты (например curl, nc или пользовательские скрипты) не включены в образ, будет отображено сообщение об ошибке «Command not found».
    • Если выполняется shell‑скрипт, необходимо указать интерпретатор скрипта. Кластер не предоставляет интерактивный терминал, поэтому скрипты нельзя выполнять напрямую. Нужно использовать интерпретатор для вызова скрипта. Например, если скрипт находится в /data/scripts/health_check.sh, необходимо выполнить sh /data/scripts/health_check.sh.

    gRPC Check (grpc)

    Этот метод применяется к gRPC‑приложениям. HTTP‑портов или внешних скриптов не требуется. Проверки состояния используют стандартные gRPC API.

    Port: контейнерный порт, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.

  4. Настройте другие параметры и нажмите Create Workload в правом нижнем углу. Если рабочая нагрузка находится в состоянии Running, проверка состояния считается успешной.

Через YAML

  1. Используйте kubectl для доступа к кластеру. Подробности см. Accessing a Cluster Using kubectl.
  2. Создайте файл YAML для настройки рабочей нагрузки. В этом примере имя файла health_check.yaml. При необходимости вы можете изменить его.

    vim health_check.yaml

    Ниже приведён пример с использованием HTTP‑запроса. Подробности о других методах проверок состояния см. Configuring Liveness, Readiness and Startup Probes. Содержимое файла:

     
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
          version: v1
      template:
        metadata:
          labels:
            app: nginx
            version: v1
        spec:
          containers:
            - name: container-1
              image: nginx:latest
               readinessProbe :                # The readiness probe
                httpGet:                     # HTTP requests are used to check container health.
                  path: /                    # The HTTP health check path
                  port: 80                   # The health check port is  80 .
                  host: ''                   # The host address, which defaults to the pod IP address
                  scheme: HTTP               # The health check protocol
                  httpHeaders:               # (Optional) The request header name is  Custom-Header , and the value is  Awesome .
                  - name: Custom-Header
                    value: Awesome
                initialDelaySeconds: 3       # The grace period for container startup before health checks begin, in seconds
                timeoutSeconds: 1            # The probe timeout, in seconds
                periodSeconds: 3             # The probe check period, in seconds
                successThreshold: 1          # The minimum consecutive successful probes required to mark a container healthy after a failure
                failureThreshold: 3          # The minimum consecutive probe failures before marking a container unhealthy
          imagePullSecrets:
            - name: default-secret

  3. Создайте рабочую нагрузку.

    kubectl create -f health_check.yaml

    Если отображается информация, аналогичная следующей, рабочая нагрузка создаётся:

     
    deployment.apps/nginx created

  4. Проверьте pod рабочей нагрузки.

    kubectl get pod

    Если статус pod Running, рабочая нагрузка создана.

     
    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-58cdd4f48d-jcsqn   1/1     Running   0          4m19s

Настройка Startup Probes

Startup probes запускаются при старте контейнера для проверки инициализации. Они используются для медленно запускающихся приложений.

Через консоль

  1. Войдите в CCE console.
  2. При создании рабочей нагрузки выберите Health Check в Container Information.
  3. Включите пробу запуска.
    Таблица 3 Параметры проб

    Метод проверки

    Описание

    Конкретный параметр

    Общий параметр

    HTTP (httpGet)

    Этот метод применяется к контейнерам, которые предоставляют службы HTTP или HTTPS. Кластер периодически отправляет запрос HTTP/HTTPS GET к конечной точке целевого контейнера. Если код статуса ответа находится в диапазоне 200–399, проба считается успешной. Если код статуса ответа находится вне этого диапазона, проба завершается с ошибкой, и kubelet останавливает и перезапускает контейнер.

    • Path: HTTP или HTTPS путь, который необходимо проверить, как определено в образе контейнера. Должен быть абсолютным путём, начинающимся со слеша (/).
    • Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.
    • Host Address: IP‑адрес целевого хоста для запроса. Если не указано, по умолчанию используется IP‑адрес pod.
    • Protocol: протокол, используемый для запроса. Он должен соответствовать протоколу, предоставляемому службой контейнера.
    • Request Header: HTTP или HTTPS заголовок, включаемый в запрос, задаётся в виде пары ключ‑значение.
    • Period (periodSeconds): интервал между проверками пробы, в секундах.

      Например, если этот параметр установлен в 30, проверка состояния выполняется каждые 30 секунд.
    • Delay (initialDelaySeconds): период ожидания запуска контейнера до начала проверок состояния, в секундах.

      Например, если этот параметр установлен в 30, проверка состояния начинается через 30 секунд после запуска контейнера.
    • Timeout (timeoutSeconds): максимальное время ожидания ответа проверки, в секундах. Если он установлен в 0 или оставлен пустым, будет использовано значение по умолчанию (1).

      Например, если этот параметр установлен в 10, тайм‑аут проверки состояния составляет 10 секунд. Проверка считается неуспешной, если ответ занимает более 10 секунд.
    • Success Threshold (successThreshold): минимальное количество последовательных успешных проверок, необходимое для пометки контейнера как здорового после сбоя. Значение по умолчанию — 1, которое также является минимальным. Этот параметр должен быть установлен в 1 для проверок liveness и startup.

      Например, если этот параметр установлен в 1, контейнер восстанавливается после одной успешной проверки после сбоя.
    • Failure Threshold (failureThreshold): количество последовательных неудачных проверок до пометки контейнера как нездорового. Значение по умолчанию — 3, минимальное значение — 1.

      Для проверок liveness, если количество последовательных неудач достигает этого порога, контейнер помечается как нездоровый, и kubelet перезапускает контейнер.

      Для проверок readiness, если количество последовательных неудач достигает этого порога, pod помечается как неготовый и удаляется из конечных точек Service. В этом случае контейнер не получает новый трафик, но не перезапускается.

    TCP (tcpSocket)

    Этот метод применяется к контейнерам, которые предоставляют TCP‑службы (например, базы данных, кэши и пользовательские TCP‑приложения). Кластер периодически пытается установить TCP‑соединение с целевым контейнером. Если соединение успешно, проверка считается здоровой. В противном случае проверка не проходит, и kubelet останавливает и перезапускает контейнер.

    Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.

    Command (exec)

    Необходимо указать исполняемую команду, которую кластер будет периодически запускать внутри контейнера. Если команда завершается с кодом 0, проверка считается успешной. В противном случае проверка не проходит, и kubelet останавливает и перезапускает контейнер.

    ВНИМАНИЕ:

    Избегайте проб на основе команд в средах с высокой нагрузкой, так как они потребляют системные ресурсы. Когда ресурсы ограничены, например при высокой загрузке CPU или конкуренции за блокировки файловой системы, пробам может истекать время ожидания и они могут завершаться с ошибкой. Если необходимо их использовать, следуйте этим рекомендациям:
    • Увеличьте порог отказов и время ожидания, чтобы предотвратить срабатывание проб из‑за кратковременных всплесков нагрузки. Однако это снижает чувствительность обнаружения реальных нездоровых состояний, поэтому настраивайте консервативно.
    • Установите правильные ограничения CPU для контейнеров сервисов и системных дополнений. В противном случае голодание по времени квантов может удерживать блокировки ядра и блокировать exec probes во всех pod‑ах на узле.

    Command: команда, выполняемая внутри контейнера для проверки его состояния. Вводите несколько команд в отдельных строках.

    ПРИМЕЧАНИЕ:
    • Прежде чем использовать этот метод, необходимо упаковать требуемые программы и инструменты в образ контейнера. Кластер выполняет команды непосредственно в контейнере. Файловые системы хоста и файловые системы других контейнеров недоступны. Если зависимые программы или инструменты (например curl, nc или пользовательские скрипты) не включены в образ, будет отображено сообщение об ошибке "Command not found".
    • Если выполняется shell‑скрипт, необходимо указать интерпретатор скрипта. Кластер не предоставляет интерактивный терминал, поэтому вы не можете выполнять скрипты напрямую. Нужно использовать интерпретатор для вызова скрипта. Например, если скрипт находится в /data/scripts/health_check.sh, необходимо выполнить sh /data/scripts/health_check.sh.

    Проверка gRPC (grpc)

    Этот метод применяется к gRPC‑приложениям. HTTP‑портов или внешних скриптов не требуется. Проверки состояния используют стандартные gRPC API.

    Port: порт контейнера, открытый для проверок состояния. Допустимый диапазон: от 1 до 65535.

  4. Настройте другие параметры и нажмите Create Workload в правом нижнем углу. Если workload находится в состоянии Running, проверка состояния считается успешной.

Через YAML

  1. Используйте kubectl для доступа к кластеру. Подробности см. в Accessing a Cluster Using kubectl.
  2. Создайте YAML‑файл для настройки workload. В этом примере имя файла health_check.yaml. При необходимости вы можете изменить его.

    vim health_check.yaml

    Следующее использует HTTP‑запрос в качестве примера. Для получения подробной информации о других методах проверки работоспособности см. Configuring Liveness, Readiness and Startup Probes. Содержимое файла:

     
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
          version: v1
      template:
        metadata:
          labels:
            app: nginx
            version: v1
        spec:
          containers:
            - name: container-1
              image: nginx:latest
               startupProbe :                  # The startup probe
                httpGet:                     # HTTP requests are used to check container health.
                  path: /                    # The HTTP health check path
                  port: 80                   # The health check port is  80 .
                  host: ''                   # The host address, which defaults to the pod IP address
                  scheme: HTTP               # The health check protocol
                  httpHeaders:               # (Optional) The request header name is  Custom-Header , and the value is  Awesome .
                  - name: Custom-Header
                    value: Awesome
                initialDelaySeconds: 3       # The grace period for container startup before health checks begin, in seconds
                timeoutSeconds: 1            # The probe timeout, in seconds
                periodSeconds: 3             # The probe check period, in seconds
                successThreshold: 1          # The minimum consecutive successful probes required to mark a container healthy after a failure
                failureThreshold: 3          # The minimum consecutive probe failures before marking a container unhealthy
          imagePullSecrets:
            - name: default-secret

  3. Создайте рабочую нагрузку.

    kubectl create -f health_check.yaml

    Если отображается информация, аналогичная следующей, workload создаётся:

     
    deployment.apps/nginx created

  4. Проверьте pod workload.

    kubectl get pod

    Если статус pod Running, workload создан.

     
    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-58cdd4f48d-jcsqn   1/1     Running   0          4m19s

Родительская тема: Configuring a Workload
Предыдущая статья
Настройка жизненного цикла контейнера
Следующая статья
Настройка переменных среды
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru