Неправильный зонд жизнестойкости для Redis не дает сбоя

#kubernetes #redis #livenessprobe

Вопрос:

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

   livenessProbe:
    initialDelaySeconds: 20
    periodSeconds: 10
    exec:
      command:
        {{- include "liveness_probe" . | nindent 16 }}
 

_liveness.tpl

 {{/* Liveness probe script. */}}
{{- define "liveness_probe" -}}

- "redis-cli"
- "set"
- "liveness_test_key"
- ""SUCCESS""
- "amp;amp;"
- "redis-cli"
- "get"
- "liveness_test_key"
- "|"
- "awk"
- "'$1 != "SUCCESS" {exit 1}'"
{{- end }}
 

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

 {{/* Liveness probe script. */}}
{{- define "liveness_probe" -}}

- "redis-cli"
- "set"
- "liveness_test_key"
- ""SUCCESS""
- "amp;amp;"
- "redis-cli"
- "del"
- "liveness_test_key"
- "amp;amp;"
- "redis-cli"
- "get"
- "liveness_test_key"
- "|"
- "awk"
- "'$1 != "SUCCESS" {exit 1}'"
{{- end }}
 

Я получаю ожидаемые коды выхода, когда выполняю эту команду непосредственно в командной строке.

Но дело в том, что мой модуль все еще в состоянии запуститься.

Команда зонда жизнестойкости, которую я использую, в порядке? Если да, то как я могу это подтвердить?

Ответ №1:

Попробуйте это для вашего зонда жизнестойкости, он работает нормально, и вы можете попробовать то же самое в readinessProbe:

 apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: redis
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: redis
    spec:
      containers:
      - image: redis
        name: redis
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - |            
                #!/usr/bin/env bash -e
                #export REDISCLI_AUTH="$REDIS_PASSWORD"

                set_response=$(
                  redis-cli set liveness_test_key "SUCCESS"
                )

                del_response=$(
                    redis-cli del liveness_test_key
                )

                response=$(
                  redis-cli get liveness_test_key
                )

                if [ "$response" != "SUCCESS" ] ; then
                  echo "Unable to get keys, something is wrong"
                  exit 1
                fi               

          initialDelaySeconds: 5
          periodSeconds: 5
          
status: {}

 

Вам нужно будет отредактировать эти значения в своем шаблоне

Ответ №2:

Я думаю, вы путаете livenessProbe с readinessProbe . livenessProbe сообщает kubernetes о перезапуске модуля, если ваша команда возвращает ненулевой код завершения, он выполняется по истечении периода, указанного в initialDelaySeconds: 20

В то readinessProbe время как это то, что решает, находится ли модуль в Ready состоянии принять трафик или нет.

   readinessProbe:
    initialDelaySeconds: 20
    periodSeconds: 10
    exec:
      command:
        {{- include "liveness_probe" . | nindent 16 }}
 

Они также могут быть использованы вместе, если вам это нужно.

Пожалуйста , проверьте эту страницу из документации kubernetes, где они объясняют livenessProbe , readinessProbe и startupProbe

Комментарии:

1. Но в моей конфигурации не должен ли зонд жизнестойкости выйти из строя и привести к перезапуску модуля?

2. Это должно произойти через 20 секунд, если ваша команда вернет ненулевой код выхода. Я предлагаю вам запустить kubectl exec в модуль и попробовать запустить команду оттуда, чтобы убедиться, что она не возвращает 0.

3. Да, я уже проверил это. Он действительно возвращает 1 внутри модуля.