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

У меня вопрос о том, как Kubernetes определяет сервировочную капсулу, когда есть несколько копий этой капсулы.

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

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

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


kubernetes minikube kubernetes-pod kubernetes-ingress kubectl
person Pert8S    schedule 15.05.2019    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

Сервисный объект будет таким

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
person Suresh Vishnoi    schedule 15.05.2019
comment
Спасибо, Суреш! Кроме того, когда служба не запущена, я создаю два независимых модуля, запускающих одно и то же приложение. Есть ли там что-нибудь похожее на AffinityConfig? - person Pert8S; 15.05.2019
comment
Сервисный объект обеспечивает стабильность для модулей, поскольку podIP может быть изменен в его жизненном цикле как неизменный объект. два независимых модуля не являются копиями друг друга. - person Suresh Vishnoi; 15.05.2019
comment
Кроме того, вам необходимо иметь служебный объект, чтобы открывать его внутренне или внешне. - person Suresh Vishnoi; 15.05.2019
comment
Да, конечно, сервисы более гибкие и удобные. Но можем ли мы сделать указанные выше настройки на уровне модуля? - person Pert8S; 15.05.2019
comment
Я не нашел ничего, связанного с привязкой к сеансу, в podspec, вы также можете проверить с помощью следующей команды kubectl explain pod.spec --recursive | grep -i affinity - person Suresh Vishnoi; 15.05.2019

arrow_upward
1
arrow_downward

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

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

person Ankit Deshpande    schedule 15.05.2019