0
点赞
收藏
分享

微信扫一扫

Kubernetes详解(三十二)——Service会话粘性

今天继续给大家介绍Linux运维相关知识,本文主要内容是Service会话粘性。

一、Service会话粘性简介

在上文Kubernetes详解(三十一)——Service资源清单定义与创建中,我们使用Service资源对象来代理对Pod资源对象的访问。在默认情况下,Service资源对象对Pod的代理采取了轮询机制,即把流量平均的转发到后方的Pod资源对象上,如下所示:
在这里插入图片描述
但是,如果我们的业务环境中需要使用客户端的私有信息,并使用该信息来追踪客户端活动等需求时,就需要Service客户端将同一个客户端的请求调度至同一个Pod资源对象上。要实现这一目的,就需要使用Service资源对象的会话“粘性”。
Service会话粘性,即Service Affinity,可以将来自同一个客户端的请求在一定时间内始终转发给同一个Pod资源对象。Service Affinity机制在实现这种特殊转发模式的同时,也会影响调度算法的流量分发功能,进而降低负载均衡的效果。

二、Service会话粘性实战

接下来,我们就来配置实现Service的会话粘性。我们将上文Kubernetes详解(三十一)——Service资源清单定义与创建中的Service资源配置清单修改如下所示:

apiVersion: v1
kind: Service
metadata:
  name: service-test
spec:
  selector:
      app: test-service
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  sessionAffinity: ClusterIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 20

配置完成后Service资源配置清单如下所示:
在这里插入图片描述
之后,我们继续执行命令:

kubectl apply -f Service-Pod.yaml

创建Service和Pod资源,执行完成后,我们再次修改各个Pod的index.html文件,使这三个Pod的返回不同,如下所示:
在这里插入图片描述
之后,我们查看SVC的IP地址,如下所示:
在这里插入图片描述
最后,我们使用curl访问该客户端,结果如下所示:
在这里插入图片描述
可以看出,我们在访问时,Service总是会把我们的请求发送到同一个Pod上,但是当我们持续静默超出Service的超时时间后,Service才会重新把我们的请求发送到其他的Pod上。
原创不易,转载请说明出处:https://blog.csdn.net/weixin_40228200

举报

相关推荐

0 条评论