Удаление пода вызывает ошибки при использовании NEG

В этом примере я запускаю "echoheaders" Nginx в развертывании с двумя репликами. Когда я удаляю 1 пакет, я иногда получаю медленные ответы и ошибки в течение ~ 40 секунд.

Мы запускаем наш API-шлюз в Kubernetes, и нам нужно разрешить планировщику Kubernetes обрабатывать поды так, как он считает нужным.

Недавно мы хотели ввести привязку сеанса, и для этого мы хотели перейти на новые блестящие группы конечных точек сети NEG: https://cloud.google.com/load-balancing/docs/negs/

При использовании NEG возникают проблемы во время переключения при отказе. Без NEG все в порядке.

развертывание.yaml


apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: echoheaders
  labels:
    app: echoheaders
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echoheaders
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - image: brndnmtthws/nginx-echo-headers
        imagePullPolicy: Always
        name: echoheaders
        readinessProbe:
          httpGet:
            path: /
            port: 8080
        lifecycle:
          preStop:
            exec:
              # Hack: wait for kube-proxy to remove endpoint before exiting, and
              # gracefully shut down 
              command: ["bash", "-c", "sleep 10; nginx -s quit; sleep 40"]
      restartPolicy: Always
      terminationGracePeriodSeconds: 60

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: echoheaders
  labels:
    app: echoheaders
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: echoheaders

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.global-static-ip-name: echoheaders-staging
  name: echoheaders-staging
spec:
  backend:
    serviceName: echoheaders
    servicePort: 80

При удалении модуля я получаю ошибки, как показано на этом изображении

$ httping -G -K 35.190.69.21

(https://i.imgur.com/u14MvHN.png)

Это новое поведение при использовании NEG. Отключение NEG дает старое поведение с рабочим аварийным переключением.

Есть ли способ использовать Google LB, ingress, NEG и Kubernetes без ошибок во время удаления модуля?


kubernetes google-kubernetes-engine google-cloud-networking
person Nicholas Klem    schedule 10.04.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

В балансировщиках нагрузки GCP запрос GET будет обслуживаться только после 502 после того, как два последующих серверных модуля не соберут время ожидания ответа или возникнет серьезная ошибка, которая кажется более правдоподобной.

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

Изящная остановка службы [1] на машине приведет к тому, что после получения SIGTERM ваша служба продолжит обслуживать запросы в полете, но откажется от новых подключений. Это может решить вашу проблему, но имейте в виду, что нет гарантии нулевого времени простоя.

[1] https://landing.google.com/sre/sre-book/chapters/load-balancing-datacenter/#robust_approach_lame_duck

person Lozano    schedule 12.04.2019