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