Как получить собственный путь проверки работоспособности в балансире GCE L7, обслуживающем вход Kubernetes?

Я пытаюсь развернуть экземпляр grafana внутри Kubernetes (сервер 1.6.4) в GCE. Я использую следующие манифесты:

Развертывание ( полная версия):

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: grafana
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: grafana
    spec:
      initContainers:
        …                                
      containers:
        - name: grafana
          image: grafana/grafana
          readinessProbe:
            httpGet:
              path: /login
              port: 3000
          …

Сервис:

apiVersion: v1
kind: Service
metadata:
  name: grafana
spec:
  selector:
    name: grafana
  ports:
    - protocol: TCP
      port: 3000
  type: NodePort

Вход:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: grafana
spec:
  tls:
    - secretName: grafana.example.com
  backend:
    serviceName: grafana
    servicePort: 3000

Оказывается, графана служит 302 на / но по умолчанию проверка здоровья входа GCE ожидает 200 на / ( источник). Как вы можете видеть, в Deployment есть пользовательский индикатор готовности (строка 22).

Как только я размещаю эти ресурсы на kube-apiserver, все создается без ошибок. Конкретно, Ingress получает публичный IP4-адрес, но healtcheck настроен по умолчанию / путь вместо пользовательского, настроенного в readinessProbe, Из-за этого я получаю 502, если я curl публичный IP4-адрес Ingress.

Проблема устраняется путем ручного изменения пути зонда на /login в консоли GCE.

Источник

4 ответа

Решение

Цитирую отсюда:

GLBC требует, чтобы вы определили порт (в вашем случае 3000) в спецификации Pod.

Решение состоит в том, чтобы объявить порт, используемый для проверки работоспособности, в ports помимо добавления кастома readinessProbe:

containers:
  - name: grafana
    readinessProbe:
      httpGet:
        path: /login
        port: 3000
    ports:
      - name: grafana
        containerPort: 3000
    …
Источник

Настройка проверки здоровья

С аддоном GLBC

Это не совсем понятно из вашего вопроса, но если вы используете GCE Load-Balancer Controller (GLBC) Cluster Addon, вы можете настроить путь проверки работоспособности.

В настоящее время все служебные серверы должны удовлетворять одному из следующих требований для прохождения проверок работоспособности HTTP(S), отправленных ему из loadbalancer GCE:

  • Ответить с 200 на '/', Содержание не имеет значения.
  • Выставьте произвольный URL-адрес в качестве проверки готовности на бобах, поддерживающих Сервис.

Контроллер Ingress сначала ищет совместимый тест готовности, если он его находит, он принимает его в качестве проверки работоспособности HTTP(S) нагрузочного балансировщика GCE. Если тест готовности отсутствует или для теста готовности требуются специальные заголовки HTTP, контроллер Ingress указывает проверку работоспособности HTTP балансировщика нагрузки GCE на "/". Это пример Ingress, который использует проверку готовности от конечных точек в качестве проверки работоспособности.

Страница аддона GLBC упоминает об этом в разделе " Ограничения":

Все услуги Kubernetes должны обслуживать 200 страница на '/' или любое другое пользовательское значение, указанное вами в GLBC --health-check-path аргумент.

Без аддона GLBC

Если вы не используете аддон, в настоящее время Kubernetes требует от вас служить 200 за GET запросы на / путь для успешных проверок работоспособности, в противном случае серверная часть не будет получать трафик.

В этой ошибке есть немного предыстории.

Google Container Engine (GKE)

Если вы работаете с Google Container Engine (GKE), там применяются те же требования Kubernetes по умолчанию для проверки работоспособности.

Услуги, предоставляемые через Ingress, должны служить ответом HTTP 200 статус на GET запросы на / дорожка. Это используется для проверки здоровья. Если ваше приложение не обслуживается HTTP 200 на /, серверная часть будет помечена как нездоровая и не будет получать трафик.

Ответьте на свой реальный вопрос

Сказав все это, как вы (@mmoya) указали в своем ответе, добавление того же порта, который используется для проверки готовности, в качестве одного из портов в модуле, устраняет проблему для вашего случая, поскольку сам порт не отображается снаружи стручок в противном случае. Это заставило Kubernetes полагаться на проверку здоровья от / вместо.

Источник

условия предполагаемых проверок работоспособности при создании Ingress:

Ingress backend.servicePort ссылается на порт службы, соответствующий Pods spec.containers[].readinessProbe.httpGet.port, а targetPort службы ссылается на контейнеры обслуживающего Pod[].spec.ports.containerPort.

В середине 2020 года GKE представил аннотацию и настраиваемое определение ресурса. BackendConfigчтобы явно настроить проверки работоспособности, см. концепты / ingress#health_checks.

Предупреждение: если вы снова измените readinessProbe, при предполагаемых проверках работоспособности GKE не синхронизирует зонд готовности и проверку работоспособности . Он будет снова выведен только при (повторном) создании Ingress.

Чтобы напрямую редактировать проверки работоспособности внешних балансировщиков нагрузки (для настраиваемого пути http), используйте

      gcloud compute backend-services list
gcloud compute backend-services get-health BACKEND_SERVICE_NAME --global
gcloud compute health-checks describe
gcloud compute health-checks update http BACKEND_SERVICE_NAME --request-path=/api/health
Источник

Это работает на 1.9. Установка httpHeaders также устраняет необходимость добавления дополнительного имени хоста в ALLOWED_HOSTS параметр.

      readinessProbe:
  httpGet:
    path: /login
    port: 3000 # Must be same as containerPort
    httpHeaders:
    - name: Host
      value: yourdomain.com
Источник
Другие вопросы по тегам