Kubernetes:Проблемы с проверкой работоспособности / готовности в реестре Docker, размещенном в хранилище S3

Текущая настройка

Здравствуйте. Я использую диаграмму управления реестра Docker, развернутую с хранилищем S3. Теперь я хотел бы обновить (изменить) способ работы зондов в реальном времени / готовности. Причина в том, что после одного дня использования я исчерпал ежемесячную квоту уровня бесплатного пользования для запросов LIST на AWS. Эта квота составляет 2000 запросов в месяц. Прямо сейчас зонды в модуле реестра выглядят следующим образом:

Liveness:       http-get http://:5000/ delay=0s timeout=1s period=10s #success=1 #failure=3
Readiness:      http-get http://:5000/ delay=0s timeout=1s period=10s #success=1 #failure=3

Это, очевидно, GET . Однако согласно этот ответ, эти запросы помечены AWS как LIST .

Это пользовательские значения ( chart_values.yaml ), которые я использовал в диаграмме управления. Установка реестра Docker:

storage: s3

secrets:
  htpasswd: "..."
  s3:
    accessKey: "..."
    secretKey: "..."

s3:
  region: "..."
  secure: true
  bucket: "..."

Отправка / извлечение образов работает, как ожидалось.

Вопрос (см. последнее изменение перефразированного вопроса)

• Что мне делать, чтобы избежать запросов S3 от зондов ?
• Разве проверки работоспособности / готовности не должны быть связаны только с самим модулем, не касаясь S3?

Я знаю, что могу отредактировать конфигурацию развертывания, чтобы изменить periodSeconds зондов, чтобы скажем 600s . Но я не думаю, что это оптимальное решение. Я знаю, что существуют команды liveness , но я не уверен, возможно ли это с помощью образа докера реестра по умолчанию.

Последнее, о чем я подумал, было то, что, возможно, если бы образ докера реестра имел Если включены метрики prometheus, я смогу заменить зонды на путь : 5001 / metrics . Но я не совсем уверен, как это сделать.

РЕДАКТИРОВАТЬ :

Чтобы включить метрики Prometheus, я удалил свою предыдущую установку helm реестра докеров. Затем загрузите стабильную диаграмму управления reigstry докеров через helm pull stable / docker-registry --untar .

Затем я отредактировал файл templates / deployment.yaml :

spec:
  containers:
    ports:
      - containerPort: 5000
      - containerPort: 5001     # Added this line
    livenessProbe:
      initialDelaySeconds: 1    # Added
      path: /metrics            # Edited
      port: 5001                # Edited
    readinessProbe:
      initialDelaySeconds: 10   # Added
      path: /metrics            # Edited
      port: 5001                # Edited
    env:
      # Added these env variables
      - name: REGISTRY_HTTP_DEBUG_ADDR
        value: "localhost:5001"
      - name: REGISTRY_HTTP_DEBUG_PROMETHEUS_ENABLED
        value: "true"
      - name: REGISTRY_HTTP_DEBUG_PROMETHEUS_PATH
        value: /metrics

и файл templates / service.yaml :

  ports:
    - port: {{ .Values.service.port }}
      protocol: TCP
      name: {{ .Values.service.name }}
      targetPort: 5000
    # Added these lines below
    - port: 5001
      protocol: TCP
      name: {{ .Values.service.name }}-prometheus
      targetPort: 5001

Lint и установите:

helm install registry ./docker-registry-chart/ -f chart_values.yaml -n docker-registry

Однако, модуль реестра никогда не готов с этой конфигурацией ( kubectl get показывает 0/1 на модуле). Это связано с ошибкой проверки готовности, поскольку 5001 containerPort не раскрывается. Таким образом, проверка готовности завершается ошибкой, так как не удается достичь сервера метрик.

Я могу подтвердить, что сервер метрик в контейнере Docker запускается правильно. Вот журналы модуля реестра, которые показывают, что сервер отладки (метрик) запущен:

time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5000_TCP" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5000_TCP_ADDR" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5000_TCP_PORT" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5000_TCP_PROTO" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5001_TCP" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5001_TCP_ADDR" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5001_TCP_PORT" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_PORT_5001_TCP_PROTO" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_SERVICE_HOST" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_SERVICE_PORT" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_SERVICE_PORT_REGISTRY" 
time="2020-04-10T14:36:26Z" level=warning msg="Ignoring unrecognized environment variable REGISTRY_DOCKER_REGISTRY_SERVICE_PORT_REGISTRY_PROMETHEUS" 
time="2020-04-10T14:36:26.172115809Z" level=info msg="debug server listening localhost:5001" 
time="2020-04-10T14:36:26.188154917Z" level=info msg="redis not configured" go.version=go1.11.2 instance.id=fc945824-3600-4343-8a18-75a20b07f695 service=registry version=v2.7.1 
time="2020-04-10T14:36:26.194453749Z" level=info msg="Starting upload purge in 29m0s" go.version=go1.11.2 instance.id=fc945824-3600-4343-8a18-75a20b07f695 service=registry version=v2.7.1 
time="2020-04-10T14:36:26.211140816Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.11.2 instance.id=fc945824-3600-4343-8a18-75a20b07f695 service=registry version=v2.7.1 
time="2020-04-10T14:36:26.211497166Z" level=info msg="providing prometheus metrics on /metrics" 
time="2020-04-10T14:36:26.211894294Z" level=info msg="listening on [::]:5000" go.version=go1.11.2 instance.id=fc945824-3600-4343-8a18-75a20b07f695 service=registry version=v2.7.1 

Я даже могу выполнить команду в контейнере докера и curl localhost: 5001 / metrics , что дает 200 с соответствующим prometheus данные.

Но я все еще не знаю, как открыть порт 5001 в контейнере . Я считаю, что это позволило бы мне использовать метрики с такими зондами, как @mdaniel упоминает в его ответ .

РЕДАКТИРОВАТЬ 2 :

kubectl port-forward <registry_pod> 5001

Перенаправление порта реестра работает и Я могу curl localhost: 5001 / metrics , чтобы получить данные метрик Prometheus. curl выполняется из кластера.

Мне интересно, что-то не так с моим файлом templates / service.yaml ?

РЕДАКТИРОВАТЬ 3 : Я выяснил, в чем проблема. Недоступная служба на порту 5001 была вызвана неправильной настройкой REGISTRY_HTTP_DEBUG_ADDR на localhost: 5001 . Значение должно быть : 5001 .

Наконец, чтобы преобразовать это в то, как должен выглядеть ваш templates / deployment.yaml :

spec:
  containers:
    ports:
      - containerPort: 5000
      - containerPort: 5001     # Added this line
    livenessProbe:
      initialDelaySeconds: 1    # Added
      path: /metrics            # Edited
      port: 5001                # Edited
    readinessProbe:
      initialDelaySeconds: 10   # Added
      path: /metrics            # Edited
      port: 5001                # Edited
    env:
      # Added these env variables
      - name: REGISTRY_HTTP_DEBUG_ADDR
        value: ":5001"          # Make sure the addr field is left empty!
      - name: REGISTRY_HTTP_DEBUG_PROMETHEUS_ENABLED
        value: "true"
      - name: REGISTRY_HTTP_DEBUG_PROMETHEUS_PATH
        value: /metrics

Возможно, вы также можете указать переменные среды через файл chart_values.yaml с разделом configData ( configData.http.debug.addr и т. д.).

В любом случае, я решили опубликовать « ответ » в качестве редактирования, а не обычного ответа SO. Исходный вопрос все еще остается без ответа.

Перефразируя исходный вопрос :

• Разве проверки работоспособности / готовности не должны быть связаны только с самим модулем без доступа к S3? Проверку работоспособности S3 следует настраивать с помощью драйвера хранилища в контейнере реестра. Мне кажется, что реестр - это отдельный объект, почти не связанный с S3. По сути, мы хотим проверить работоспособность этого объекта, а не хранилища данных, для которого предусмотрена отдельная проверка работоспособности ...