Kubernetes: проблемы с тестированием живучести / готовности на хранилище S3 Docker Реестр - PullRequest
Новая
       36

Kubernetes: проблемы с тестированием живучести / готовности на хранилище S3 Docker Реестр

1 голос
/ 08 апреля 2020

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

Здравствуйте. Я использую таблицу управления реестром 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. Однако, согласно этому ответу, эти запросы помечены как LIST AWS.

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

storage: s3

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

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

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

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

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

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

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

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

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

Затем я отредактировал файл templates / deploy.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

Я могу даже запустить c в контейнер docker и свернуть localhost:5001/metrics, что приводит к 200 с соответствующие данные Прометея.

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

EDIT 2 : 

kubectl port-forward <registry_pod> 5001

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

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

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

Наконец, чтобы перевести это на то, как должен выглядеть ваш templates / deploy.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 et c.).

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

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

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

1 Ответ

0 голосов
/ 08 апреля 2020

Вы можете изменить URL-адреса активности и готовности в файле манифеста на metri c URL.

...