Основная концепция Session Affinity - перенаправлять трафик с одного клиента всегда на определенный узел. Помните, что привязка к сеансу - это метод best-стара * , и существуют сценарии, когда он завершится неудачей из-за перезапуска модуля или сетевых ошибок.
Существует два основных типа Session Affinity:
1) На основе IP-адреса клиента
Эта опция хорошо работает для сценария, где на один IP-адрес есть только один клиент. В этом методе вам не нужен Ingress / Proxy между сервисами K8s и клиентом.
IP-адрес клиента должен быть статическим, поскольку каждый раз, когда клиент меняет IP-адрес, он будет перенаправляться на другой модуль.
Чтобы включить сходство сеансов в kubernetes, мы можем добавить следующее в определение сервиса.
service.spec.sessionAffinity: ClientIP
Поскольку сообщество предоставило надлежащий манифест для использования этого метода, я не буду дублировать.
2) На основе файлов cookie
Работает, когда есть несколько клиентов с одного IP, потому что он хранится на уровне веб-браузера. Этот метод требует объекта Ingress. Шаги для применения этого метода с более подробной информацией можно найти здесь в разделе Сходство сеанса на основе раздела Cookie .
- Создание развертывания контроллера NGINX
- Создание службы NGINX
- Создать вход
- Перенаправить ваше общедоступное DNS-имя на общедоступный / внешний IP-адрес службы NGINX.
Об отображении ClientIP и POD, согласно Документация
Kube-прокси отвечает за SessionAffinity. Одно из заданий Kube-Proxy
пишет в IPtables, более подробную информацию здесь так вот как это
нанесены на карту.
Статьи, которые могут помочь в понимании близости сессии:
https://sookocheff.com/post/kubernetes/building-stateful-services/
https://medium.com/@diegomrtnzg/redirect-your-users-to-the-same-pod-by-using-session-affinity-on-kubernetes-baebf6a1733b