Базовый вход GKE периодически возвращает 502, когда возвращается бэкэнд 404/422 - PullRequest
Новая
       40

Базовый вход GKE периодически возвращает 502, когда возвращается бэкэнд 404/422

1 голос
/ 07 ноября 2019

У меня есть вход, обеспечивающий маршрутизацию для двух микросервисов, работающих на GKE, и периодически, когда микросервис возвращает 404/422, вход возвращает 502.

Вот мое определение входа: 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: basic-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: develop-static-ip
    ingress.gcp.kubernetes.io/pre-shared-cert: dev-ssl-cert
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: srv
          servicePort: 80
      - path: /c/*
        backend:
          serviceName: collection
          servicePort: 80
      - path: /w/*
        backend:
          serviceName: collection
          servicePort: 80

Я запускаю тесты, которые попадают в серверную часть srv, где я ожидаю ответ 404 или 422. Когда я напрямую нажал на сервер srv (в обход входа), я подтвердил, что служба правильно отвечает 404 / 422.

Когда я выполняю те же запросы через вход, вход будет прерывистымответьте 502 вместо 404/422, исходящим от серверной части.

Как я могу получить вход, просто вернув ответ 404/422 от серверной части?

Вот некоторыеПример кода для демонстрации поведения, которое я вижу (ожидаемое состояние - 404): 

>>> for i in range(10):
        resp = requests.get('https://<server>/a/v0.11/accounts/junk', cookies=<token>)
        print(resp.status_code)

502
502
404
502
502
404
404
502
404
404

И вот те же запросы, выданные из приглашения Python в модуле, то есть в обход входа: 

>>> for i in range(10):
...     resp = requests.get('http://0.0.0.0/a/v0.11/accounts/junk', cookies=<token>)
...     print(resp.status_code)
...
404
404
404
404
404
404
404
404
404
404

Вот выходные данные команд kubectl, чтобы продемонстрировать, что балансировщик нагрузки настроен правильно (я никогда не получаю 502 для ответа 2xx / 3xx от микросервиса): 

$ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP          NODE                                     NOMINATED NODE   READINESS GATES
srv-799976fbcb-4dxs7          2/2     Running   0          19m   10.24.3.8   gke-develop-default-pool-ea507abc-43h7   <none>           <none>
srv-799976fbcb-5lh9m          2/2     Running   0          19m   10.24.1.7   gke-develop-default-pool-ea507abc-q0j3   <none>           <none>
srv-799976fbcb-5zvmv          2/2     Running   0          19m   10.24.2.9   gke-develop-default-pool-ea507abc-jjzg   <none>           <none>
collection-5d9f8586d8-4zngz   2/2     Running   0          19m   10.24.1.6   gke-develop-default-pool-ea507abc-q0j3   <none>           <none>
collection-5d9f8586d8-cxvgb   2/2     Running   0          19m   10.24.2.7   gke-develop-default-pool-ea507abc-jjzg   <none>           <none>
collection-5d9f8586d8-tzwjc   2/2     Running   0          19m   10.24.2.8   gke-develop-default-pool-ea507abc-jjzg   <none>           <none>
parser-7df86f57bb-9qzpn       1/1     Running   0          19m   10.24.0.8   gke-develop-parser-pool-5931b06f-6mcq    <none>           <none>
parser-7df86f57bb-g6d4q       1/1     Running   0          19m   10.24.5.5   gke-develop-parser-pool-5931b06f-9xd5    <none>           <none>
parser-7df86f57bb-jchjv       1/1     Running   0          19m   10.24.0.9   gke-develop-parser-pool-5931b06f-6mcq    <none>           <none>

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
srv          NodePort    10.0.2.110   <none>        80:30141/TCP   129d
collection   NodePort    10.0.4.237   <none>        80:30270/TCP   129d
kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP        130d

$ kubectl get endpoints
NAME         ENDPOINTS                                AGE
srv          10.24.1.7:80,10.24.2.9:80,10.24.3.8:80   129d
collection   10.24.1.6:80,10.24.2.7:80,10.24.2.8:80   129d
kubernetes   35.237.239.186:443                       130d

Ответы [ 2 ]

1 голос
/ 13 ноября 2019

502 ошибки ожидаются, когда ваш бэкэнд-сервис возвращает ошибки 4xx . Если сервер возвращает 4xx, проверки работоспособности не пройдены. Если все серверы не работают, балансировщик нагрузки не будет иметь доступного серверного сервера для отправки трафика и вернет 502.

Для любой ошибки 502, возвращенной балансировщиком нагрузки, я настоятельно рекомендую проверить журналы стекового драйвера на наличие ошибок. HTTP Load Balancer. Любая ошибка 502 будет включать вывод сообщения вместе с ответом 502. В сообщении должно быть разъяснено, почему 502 было перезапущено (есть ряд причин).

В вашем текущем случае в журнале ошибок 502 должно быть указано"failed_to_pick_backend" или "failed_to_connect_to_backend", что-то дляэта мелодия. Если вы используете вход nginx, можно увидеть похожее поведение, но сообщение об ошибке 502 может сказать что-то другое.

0 голосов
/ 10 ноября 2019

502 - сложный код состояния, он может означать контекст, отмененный клиентом, или просто плохой шлюз с сервера, к которому вы пытаетесь обратиться. В kubernetes 502 обычно означает, что вы не можете обратиться к услуге. Таким образом, я бы пошел на отладку ваших сервисов и развертываний doc .

Используйте kubectl get pods -o wide, чтобы получить srv pod;проверь свой кластер IP IP. Затем убедитесь, что служба выполняет балансировку нагрузки для развертывания srv. Для этого запустите kubectl get svc и найдите сервис srv. Наконец, запустите kubectl get endpoints, получите IP-адрес, назначенный конечной точке srv, и сопоставьте его с IP-адресом, полученным из модуля. Если все в порядке, значит, вы корректно распределяете нагрузку на свой бэкэнд.

...