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

Настройка проверки состояния контейнера

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

Сценарий

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

Kubernetes предоставляет три типа проб проверки состояния для мониторинга приложений в контейнерах с целью обеспечения стабильности системы и высокой доступности.
  • 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 и how to configure them.

Настройка 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, probe считается успешной. Если код статуса ответа находится вне этого диапазона, probe завершается неудачей, и kubelet останавливает и перезапускает контейнер.

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

      Например, если этот параметр установлен в 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: команда, выполняемая внутри контейнера для проверки его состояния. Введите несколько команд, разместив их на отдельных строках.

    ПРИМЕЧАНИЕ:
    • Прежде чем использовать этот метод, необходимо упаковать требуемые программы и инструменты в образ контейнера. Кластер выполняет команды непосредственно в контейнере. Файловые системы хоста и файловые системы других контейнеров недоступны. Если зависимые программы или инструменты (например 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

    The following uses an HTTP request as an example. For details about other health check methods, see Configuring Liveness, Readiness and Startup Probes. File content:

     
    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. Создайте рабочую нагрузку.

    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

Настройка 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 останавливает и перезапускает контейнер.

    ПРЕДУПРЕЖДЕНИЕ:

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

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

    ПРИМЕЧАНИЕ:
    • Перед использованием этого метода необходимо включить требуемые программы и инструменты в образ контейнера. Кластер выполняет команды непосредственно в контейнере. Файловые системы хоста и других контейнеров недоступны. Если зависимые программы или инструменты (например 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. Включите startup probe.
    Table 3 Probe parameters

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

    Описание

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

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

    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‑пробы во всех 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

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

     
    deployment.apps/nginx created

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

    kubectl get pod

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

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

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