Служба контроллера HAProxy Ingress изменила IP-адрес на GCP

Я использую HAProxy в качестве входящего контроллера в своих кластерах GKE. И выставляем сервис HAProxy как сервис LoadBalancer (внутренний).

Недавно у меня возникла проблема, когда служба HA-Proxy изменила свой ВНЕШНИЙ IP-адрес, и трафик перестал маршрутизироваться на HAProxy. Эта проблема возникала несколько раз в разные дни (теперь она исчезла). Мне пришлось вручную добавить этот новый внешний IP-адрес к интерфейсу этого Loadbalancer, чтобы разрешить трафик на HAProxy.
Для HAProxy было запущено два модуля, и оба работали несколько дней, и в их журналах ничего не было. Я предполагаю, что это было связано с Service или GCP LB, а не с самим HAProxy.
Боюсь, что у меня нет журналов, связанных с этим.

Я до сих пор не знаю, что привело к изменению IP-адреса службы. Поскольку последних изменений не было, и кластер и все службы работали в течение многих дней правильно, это произошло внезапно.

Кто-нибудь раньше сталкивался с подобной проблемой? Или что я могу сделать, чтобы избежать такой проблемы в будущем?
Что могло привести к изменению IP-адреса?

Так настроен мой сервис:

---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: haproxy-ingress
  name: haproxy-ingress
  namespace: haproxy-controller
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-allow-global-access: "true"
    cloud.google.com/network-tier: "Premium"
spec:
  selector:
    run: haproxy-ingress
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  - name: stat
    port: 1024
    protocol: TCP
    targetPort: 1024

Нашел несколько логов:

Warning SyncLoadBalancerFailed 30m (x3570 over 13d) service-controller Error syncing load balancer: failed to ensure load balancer: googleapi: Error 409: IP_IN_USE_BY_ANOTHER_RESOURCE - IP '10.17.129.17' is already being used by another resource.
Normal EnsuringLoadBalancer 3m33s (x3576 over 13d) service-controller Ensuring load balancer

kubernetes kubernetes-ingress google-kubernetes-engine kubernetes-service haproxy-ingress
person kadamb    schedule 15.05.2021    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Краткий ответ: External IP для службы являются эфемерными.
Поскольку модули контроллеров HA-Proxy воссоздаются, служба HA-Proxy создается с эфемерным IP-адресом.

Чтобы избежать этой проблемы, я бы рекомендовал использовать статический IP-адрес, на который вы можете ссылаться в поле loadBalancerIP.

Это можно сделать, выполнив следующие действия:

  • Зарезервируйте статический IP. (ссылка)
  • Используйте этот IP-адрес для создания службы (ссылка)

Пример YAML:

apiVersion: v1
kind: Service
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    app: hello
    tier: web
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer
  loadBalancerIP: "YOUR.IP.ADDRESS.HERE"
person kadamb    schedule 18.05.2021

arrow_upward
0
arrow_downward

К сожалению, без логов сложно что-либо сказать наверняка. Вам следует проверить журналы аудита, которые GKE отправляет в Cloud Logging, поскольку они могут дать вам некоторое представление о том, что произошло. Один из вариантов - GCP не удалось, GLB и GKE воссоздали его, тем самым присвоив ему новый IP. Я никогда не слышал, чтобы такое происходило с LB (это довольно часто случается с узлами, но не с LB). Более распространенный случай: вы выполнили некоторую команду kubectl, которая непреднамеренно удалила объект Service, а затем он был воссоздан некоторым уровнем управления, который вы настроили (Argo, Flux, Helm Operator, что угодно), но удаление + воссоздание снова означает, что это новый LB с новым IP. Последний случай должен быть виден в журналах аудита, поэтому обязательно проверьте их.

person coderanger    schedule 16.05.2021
comment
LB не был воссоздан, он присутствовал с другими серверными и внешними интерфейсами без изменений. И когда проверено, сервис тоже давно присутствует, а у меня нет никакого уровня управления. Нашел две строчки логов с того дня, поставил под сомнение. - person kadamb; 16.05.2021