Удаление стручка вызывает ошибки при использовании NEG - PullRequest
1 голос
/ 10 апреля 2019

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

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

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

При использовании NEG у нас возникают проблемы при отработке отказа. Без NEG у нас все хорошо.

deployment.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:
    <b>cloud.google.com/neg: '{"ingress": true}'</b>
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 без ошибок при удалении модуля?

1 Ответ

0 голосов
/ 12 апреля 2019

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

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

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


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

...