Пользовательская проверка работоспособности с помощью GCP

Привет, я пытаюсь использовать пользовательскую проверку работоспособности с помощью GCP LoadBalancer.

Я добавил readinessProbe и livenessProbe вот так:

    readinessProbe:
      httpGet:
        path: /health
        port: dash
      initialDelaySeconds: 5
      periodSeconds: 1
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 10
    livenessProbe:
      httpGet:
        path: /health
        port: dash
      initialDelaySeconds: 5
      periodSeconds: 1
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 10

Но когда я создаю вход, у меня нет специальной проверки работоспособности.

Путь LB


person M.Hol    schedule 08.04.2019    source источник
comment
В те времена это было возможно. Не уверен, что он все еще поддерживается. Если это так, вам нужно настроить живость зонда. Если проверка жизнеспособности пройдет успешно, то GCP Load Balancer примет эту конечную точку для проверки работоспособности узлов. Проходит ли ваша проверка живости? Вы получаете 200?   -  person suren    schedule 08.04.2019
comment
У меня была аналогичная проблема, и я заметил, что readinessProbe необходимо определить перед созданием ресурса Ingress — он не будет принимать более поздние изменения. Возможно ли, что это и ваш случай?   -  person Robert Lacok    schedule 08.04.2019
comment
Я пытался подождать 10 минут, прежде чем создать вход, но безрезультатно..   -  person M.Hol    schedule 08.04.2019
comment
github.com/kubernetes/ingress-gce/ blob/ проверка работоспособности Kubernetes L7, созданная с настройками проверки готовности....   -  person M.Hol    schedule 08.04.2019


Ответы (2)


Я ЗАВЕРШИЛ ответ. То, что я пытался сделать, было невозможно. Мой GCE Ingress использовал серверную часть на порту 80. Но в моем ReadinessProbe я сказал ему проверить порт 8080 и путь /health. Это невозможно!

Порт службы, объявленный в бэкенде Ingress, должен совпадать с портом, объявленным в файле readinessProbe. Другим может быть только путь. Если мы не соблюдаем этот шаблон, то / будет связано с путем проверки работоспособности GCP.

С сетевой точки зрения это логично, Health Check GCP «вне» кластера Kube, если мы скажем ему маршрутизировать через порт 80, но наш ReadinessProbe находится на другом порту, как он может гарантировать, что даже если порт связан с ReadinessProbe встречает порт 80 (это тот, на который он должен маршрутизировать трафик) также отвечает.

Итак, порт серверной части, объявленный в Ingress, должен иметь readinessProbe на том же порту. Единственное, что мы можем настроить, — это путь.

person M.Hol    schedule 09.04.2019

Я думаю, вы запутались между ресурсами в GCP.

Размещенный вами код никоим образом не связан с ресурсом балансировщика нагрузки, так как это проверка работоспособности kubernetes для состояний подов. Если вы хотите знать, работают ли зонды, проверьте состояние вашего модуля, если он не работает, опишите свой модуль и просмотрите журналы, это должно указывать на проблему с зондами.

Я собираюсь предположить, что у вас есть входной ресурс где-то в вашей конфигурации kubernetes, который создает lb и все ресурсы вокруг него, такие как проверка работоспособности (все еще предполагая, что изображение, которое вы разместили, связано с этим).

Если вы используете GKE, вам следует оставить конфигурацию автоматизированных ресурсов Google из конфигурации k8s, которую вы развернули, как есть, потому что вы можете нарушить некоторые вещи, которые Google уже поддерживает для вас.

person night-gold    schedule 08.04.2019
comment
Когда я создаю Ingress в GKE с классом GCE, LB создает серверную часть и проверку работоспособности. Проверка работоспособности является обязательной для /path. Но давайте возьмем пример, у нас есть приложение, которое по пути / делает перенаправление ( 302 ) на /dashboard. Поскольку возвращаемый HTTP-код не 200, наша служба возвращает UNHEALTHY. Я знаю, что можно изменить конечную точку проверки работоспособности вручную, но я хотел бы сделать это автоматически, тем более что проверка здоровья соответствует моей готовности. - person M.Hol; 08.04.2019
comment
Возможно, я сказал что-то не так: вы можете найти тот же вопрос, что и ваш, здесь: stackoverflow.com/questions/50018193/, но проверенного ответа нет... - person night-gold; 08.04.2019
comment
Без проблем. Я просто нахожу возможный ответ: github.com/pusher/oauth2_proxy/issues/86 & github.com/jetstack/kube-lego/issues/27 . Но я думаю, что GCP Ingress ограничивает... - person M.Hol; 08.04.2019