k8s学习--sessionAffinity会话保持(又称会话粘滞)详细解释与应用

sessionAffinity简介

什么是sessionAffinity

简单理解
确保把来自同一客户的一个完整会话的请求转发至后台同一台服务器进行处理。

详细解释
在Kubernetes中，sessionAffinity是指Service的一种设置，用于控制外部流量如何在后端Pod之间分发。具体来说，sessionAffinity可以配置为"None"、“ClientIP"或者"ClientIP”。这些设置决定了负载均衡器如何将来自相同客户端的请求路由到后端的Pods上。

模式介绍

None
这是sessionAffinity的默认设置。当设置为"None"时，负载均衡器会根据负载均衡算法（如轮询、最少连接数等）将每个新的请求独立地分发到后端的Pods上，与之前的请求无关。

ClientIP
当设置为"ClientIP"时，负载均衡器会根据客户端的IP地址来将来自同一个客户端的请求路由到同一个后端的Pod上。这样可以确保来自同一个客户端的多次请求都被发送到同一个后端Pod上，用于保持会话一致性。

ClientIP模式的会话粘滞
这种方式通常用于需要保持会话状态的应用程序，如基于HTTP的应用程序，以确保用户在整个会话期间都能被路由到同一个后端Pod上。

应用场景

简单理解
举个大家每天都会遇到的例子，大家在淘宝或者京东上购物时，从完成用户身份认证到浏览店铺，选择心仪商品加入购物车，一直到最后下单完成支付，需要经过很多次和服务器的交互过程才能完成整个交易。由于这几次交互过程从顺序上和逻辑上是密切相关的，服务器在进行这些交互过程的某一个交互步骤时需要一个上下文(Context)，即上一次交互过程的输出，因此要求这些相关的交互过程都由一台服务器完成。
在这种情况下，假设负载均衡器仍然把这些相关交互session分散到不同的服务器实例上，就会带来很糟糕的用户体验，比如客户在浏览器上每点击一次，都会弹出登录页面。或者即使用户输入了正确的验证码，却仍然提示验证码错误。由于服务器处理实例不一样，也有可能造成客户放入购物车的物品丢失。

详细解释

有状态应用程序
对于一些有状态的应用程序，比如基于HTTP协议的Web应用或者需要保持会话状态的应用，使用ClientIP模式的sessionAffinity可以确保来自同一个客户端的请求都被路由到同一个后端Pod上，从而保持会话的一致性。这对于需要在多次请求之间共享状态或者会话信息的应用程序是非常重要的。

避免会话中断
在一些情况下，如果同一个用户的请求被路由到了不同的后端Pod上，可能会导致会话中断或者状态丢失。通过使用sessionAffinity来保持会话粘滞，可以避免这种情况的发生，确保用户的体验和应用的正确性。

缓存一致性
在一些需要使用缓存的应用场景下，比如使用了本地缓存的应用或者分布式缓存系统，通过将来自同一个客户端的请求路由到同一个后端Pod上，可以提高缓存命中率，并确保缓存数据的一致性。

有序处理
对于一些需要按照顺序处理请求的应用场景，比如消息队列、任务调度等，使用sessionAffinity可以确保来自同一个客户端的请求按照顺序被发送到同一个后端Pod上进行处理，从而保证处理的顺序性。

工作原理

创建 Service
当创建一个类型为 LoadBalancer 的 Service 时，Kubernetes 控制平面会请求云服务提供商创建一个外部负载均衡器。

负载均衡器配置
外部负载均衡器被配置为监听指定的端口（或由 Service 定义的端口）。
负载均衡器将流量转发到 Kubernetes 集群内部的所有健康 Pods，这些 Pods 通过 Endpoints 对象与 Service 关联。

流量分发
当外部用户或系统访问负载均衡器的公共 IP 地址和端口时，负载均衡器根据预定义的策略（如轮询或最少连接）将流量分发到后端的 Pods。
这种分发机制确保了负载的平衡分配，并有助于处理高流量。

健康检查
大多数负载均衡器会进行健康检查，以确保流量只被转发到健康的 Pods。
如果一个 Pod 因故障停止服务，负载均衡器将自动停止向该 Pod 发送流量，直到它再次被标记为健康。

动态更新
当新的 Pods 被创建或现有的 Pods 被销毁时，Service 的 Endpoints 列表会动态更新，而负载均衡器也将相应地更新其转发规则。

优势

易于使用
用户只需声明 Service 类型为 LoadBalancer，并不需要进行复杂的配置。

自动化
负载均衡器的创建、配置和更新都是自动进行的，这减少了维护负担。

高可用性
负载均衡器提供了故障转移能力，增强了服务的可靠性。

应用

环境

已部署k8s-1.27

步骤

1.创建测试用的deployment,service
这里使用yaml文件创建

vim sessionAffinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-server1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
       - name: c1
         image: nginx:1.20
         imagePullPolicy: IfNotPresent
         ports:
         - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    app: nginx

创建deployment和service并查看

kubectl apply -f sessionAffinity.yaml
kubectl get pods

进入pod，创建网页web1(根据name进入)

kubectl exec -it nginx-server1-855bbbf689-lmw92 -- bash

root@nginx-server1-855bbbf689-lmw92:/# echo web1 > /usr/share/nginx/html/index.html
root@nginx-server1-855bbbf689-lmw92:/# exit

进入pod，创建网页web2

kubectl exec -it nginx-server1-855bbbf689-xczvl -- bash

root@nginx-server1-855bbbf689-xczvl:/# echo web2 > /usr/share/nginx/html/index.html
root@nginx-server1-855bbbf689-xczvl:/# exit

查看服务

kubectl get svc

测试默认的负载均衡

curl 10.108.198.133

正常

2. 给服务打补丁，增加会话粘滞

设置为ClientIP模式

kubectl patch svc nginx-svc -p '{"spec":{"sessionAffinity":"ClientIP"}}'

测试

curl 10.108.198.133

效果实现
一系列相关联的访问请求会分配到一台服务器上｡

设置回sessionAffinity为None

kubectl patch svc nginx-svc -p '{"spec":{"sessionAffinity":"None"}}'

测试

curl 10.108.198.133

成功恢复轮询效果

实验完成