Kubernetes - Affinity Cookie - запросы не возвращаются к одной и той же реплике pod - PullRequest
0 голосов
/ 27 октября 2019

Я искал способ использования сходства файлов cookie в GKE. и я успешно его реализовал (благодаря этому вопросу: Проблемы с настройкой Ingress с привязкой к cookie ), и теперь я вижу, что получил GCLB Cookie, но по какой-то причине запросы не возвращаются в тот же модульreplica

Я создал YAML со следующими данными:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-bsc-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 3
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: gcr.io/google-samples/hello-app:1.0
---
apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-bsc-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50
---
apiVersion: v1
kind: Service
metadata:
  name: my-bsc-service
  labels:
    purpose: bsc-config-demo
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"80":"my-bsc-backendconfig"}}'
spec:
  type: NodePort
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-bsc-ingress
spec:
  backend:
    serviceName: my-bsc-service
    servicePort: 80
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-bsc-service
          servicePort: 80
---

Что может быть причиной такой проблемы?

Ответы [ 3 ]

1 голос
/ 28 октября 2019

Причина в том, что из GCP HTTP (S) Load Balancers документация :

Необходимо создать правило брандмауэра, разрешающее трафик с 130.211.0.0/22 ​​и 35.191. .0.0 / 16, чтобы достичь ваших экземпляров. Это диапазоны IP-адресов, которые балансировщик нагрузки использует для подключения к экземплярам бэкэнда.

Ваши пользователи подключаются не к бэкэндам напрямую, а через эти «прокси-серверы», так что сродство сеанса происходит, но некак ты хочешь. На самом деле, если вы используете GCLB, вам следует избегать сходства сессий.

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

Сродство работает, но не так, как вы ожидаете. В настоящее время сходство происходит между GCP LB и его бэкэндом (узлом, а не модулем). Как только трафик достигает вашего узла, сервис пересылает запрос в модуль. Поскольку служба не имеет сходства, она выбирает пакет по существу наугад. Это можно сделать двумя способами.

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

  2. Оставьте входной файл как есть, настройте службу NodePort с помощью spec.sessionAffinity. В GKE поддерживает только clientIP в качестве значения для этого поля. Следующий шаг - убедиться, что IP-адрес клиента действительно используется правильно, добавьте поле spec.externalTrafficPolicy: Local.

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

0 голосов
/ 28 октября 2019

Мне приходится сталкиваться с той же проблемой, и последний уровень балансировки трафика - kubeproxy, этот прокси-сервер вообще не поддерживает сессионную привязку.

Чтобы решить эту проблему, вы должны использовать другойвходной контроллер для замены kubeproxy на прокси-сервис, который поддерживает сессионную привязку, в моем случае я использую Nginx. У вас есть несколько хороших примеров того, как реализовать это в репозитории GitHub здесь , базовое использование здесь , а также вы можете использовать аннотации для настройки Nginx в зависимости от потребностей каждого входа, полный списоканнотаций здесь .

...