Открытая связь между сервисом и репликами в Кубернетесе - PullRequest
Новая
       52

Открытая связь между сервисом и репликами в Кубернетесе

1 голос
/ 15 мая 2019

У меня есть вопрос о том, как kubernetes определяет обслуживающий модуль, когда существует несколько реплик модуля.

Для примера предположим, что у меня есть веб-приложение, работающее в кластере k8s в виде нескольких копий модуля, и онивыставлены сервисом.

Когда клиент отправляет запрос, он переходит к сервису и kube-proxy.Но где и когда kubernetes принимает решение о том, какой стручок должен обслуживать запрос?

Я хочу знать внутренности kubernetes по этому вопросу.Можем ли мы это контролировать?Можем ли мы решить, какой модуль должен обслуживать, основываясь на клиентских запросах и пользовательских условиях?

Ответы [ 2 ]

2 голосов
/ 15 мая 2019

можем ли мы решить, какой модуль должен обслуживать, основываясь на клиентских запросах и пользовательских условиях?

Как kube-proxy работает на L4 средствах балансировки нагрузки, таким образом, вы можете контролироватьсеанс на основе IP-адрес клиента .он не читает заголовок запроса клиента.

вы можете управлять сеансом с помощью следующего поля service.spec.sessionAffinityConfig в service obejct

следующая команда предоставит объяснение kubectl explain service.spec.sessionAffinityConfig

Следующий абзац и ссылка содержат подробный ответ.

Сходство сеанса на основе Client-IP можно выбрать, установив для service.spec.sessionAffinity значение «ClientIP» (по умолчанию «None»)и вы можете установить максимальное время ожидания сеанса, установив поле service.spec.sessionAffinityConfig.clientIP.timeoutSeconds, если вы уже установили service.spec.sessionAffinity в значение «ClientIP» (по умолчанию «10800») * -service-proxies

Сервисный объект будет выглядеть следующим образом 

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10000
1 голос
/ 15 мая 2019

Сервис Kubernetes создает балансировщик нагрузки (и конечную точку для него) и по умолчанию использует циклический перебор для распределения запросов между модулями.

Вы можете изменить это поведение. Как сказал Суреш, вы также можете использовать sessionAffinity, чтобы запросы к определенному значению сеанса всегда направлялись в один и тот же модуль.

...