Служба GKE с автономным NEG продолжает показывать сбой проверки работоспособности - PullRequest
Новая
       45

Служба GKE с автономным NEG продолжает показывать сбой проверки работоспособности

0 голосов
/ 01 мая 2020

У меня есть простое развертывание «Hello world» со службой: 

apiVersion: v1
kind: Service
metadata:
  name: hello-kube
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
spec:
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: hello-kube

Развертывание работает нормально, и создается NEG, но когда я проверяю в веб-консоли фактическую конечную точку (которая использует виртуальный IP-адрес Pod правильно) отображается как нездоровый. Когда я проверяю с помощью интерактивного модуля "Ubuntu", я могу без проблем свернуться. Также, если я попробую виртуальную машину в сети (тот же VP C, что и кластер), я получу «Hello world!».

Я добавил правило брандмауэра, чтобы разрешить проверки работоспособности, но это Правило, естественно, либо упоминает теги узлов кластера, либо что-то вроде «все в этой сети». Однако есть ли IP-адреса с псевдонимами в сети? Может ли быть так, что проверка работоспособности не удалась, потому что я не могу добавить правило, разрешающее сетевой трафик c для виртуальных IP-адресов?

В данный момент я не могу заставить NEG работать на меня ... У кого-то есть идея ?

Берт Лаверман

1 Ответ

1 голос
/ 06 мая 2020

Таким образом, ответ казался простым и запутанным: NEG создается как следствие правильно аннотированной Службы, но затем Служба не используется. NEG будет определен с использованием IP-адреса модуля (это работает только для кластеров с включенным псевдонимом IP). Для меня любая попытка настроить Load Balancer и Backend Service на основе спецификаций Service потерпела неудачу. Это будет работать, если вы рассматриваете Сервис как средство для публикации, но не пытаетесь переназначить порты.

Поэтому вам следует:

  • Настроить Pod / Deployment с помощью порт, как вы хотите
  • Определите Сервис с помощью аннотации, но просто оставьте порты равными: 
apiVersion: v1
kind: Service
metadata:
  name: hello-kube
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
spec:
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: hello-kube

Это даст вам NEG, который вы можете добавить в Бэкэнд-сервис , но вы все равно можете запутаться, если не создадите правильную проверку здоровья. На самом деле самый простой способ: 

gcloud compute health-checks create http http-basic-check --use-serving-port

Это даст вам общую проверку работоспособности HTTP c, которая зависит от группы NEG / Instance Group для указания порта. Затем создайте Backend Service следующим образом: 

gcloud compute backend-services create magic-backend --protocol HTTP --health-checks http-basic-check --global

Этот Backend Service вы можете сразу добавить в свой LoadBalancer, и он не изменится. NEG должны быть добавлены / удалены в зависимости от развертывания вашей службы. NEG автоматически получит обновления Pod (масштабирование, миграция и т. Д. c). Вы можете использовать «контроллер AutoNEG» (см. https://github.com/GoogleCloudPlatform/gke-autoneg-controller), чтобы автоматизировать добавление / удаление NEG в Backend Service. В приведенном выше примере это означает, что вам нужно добавить аннотацию (после установки контроллера): 

apiVersion: v1
kind: Service
metadata:
  name: hello-kube
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    anthos.cft.dev/autoneg: '{"name":"magic-backend", "max_rate_per_endpoint":1000}'
spec:
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: hello-kube
...