今天继续给大家介绍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