Kubernetes(二十三)Service(二)会话保持和获取客户端的ip_sessionaffinity: clientip

接上

一   了解基本的术语

备注： 关于'各个术语',后续会'补充自己写的相关博客',构成一个'系列'

Type=LoadBalancer 类型 Service 的源 IP

全景剖析阿里云容器网络数据链路 Flannel 场景四

二   Service的会话粘滞

Service支持通过设置'sessionAffinity:ClientIP'实现基于客户端IP的'会话保持'机制
 
即：
 
 1、'首次'将'某个客户端来源IP [四层]'发起的请求转发到'后端的某个Pod上'
 
 2、之后从'相同的客户端 IP'发起的请求都将被转发到'相同的后端Pod上'

Service会话粘滞 

通过 ingress 做会话保持 

需求： 实现基于'客户端 IP' 的'会话亲和性'  --> '四层 TCP层'
 
效果： 
 
  1、来自'同一客户端(Client IP)'的请求与后端'某个pod'绑定('或者说映射')
 
  2、如果'没有特殊'的配置,是'获取不了客户端的ip',获取的是'所访问的pod所在节点的ip'
 
具体： 
 
  1、如果'replicas=2'为两个副本,设置'sessionAffinity: ClientIP'
 
  2、那么请求只会到达'其中一个pod'上,另一个'pod'没有访问记录  --> '日志判断'
 
辨析： 同一客户端'client_ip'的请求与pod进行'会话粘滞'和获取客户端的真实ip是'两码事情'

配置参数 

'sessionAffinityConfig' --> 设置sessionAffinity的'有效期',默认是's'

实验模板

创建

测试

测试'思路'： 
 
1）同一客户端通过'curl'命令行'多次'进行访问 
 
备注： 为了防止'缓存'对实验结果造成影响,'不用浏览器'
 
2）观察两个pod的日志，看请求是否在'session的有效期内'定向调度到'某个具体'的pod上
 
3）开启'多个终端'观察

关于client ip,由于我们使用'flannel'的网络形式,并且是在master上'访问'

+++++++++++++++  '命令行修改'  +++++++++++++++
 
1、'会话'保持
 
kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"ClusterIP"}}'  
 
2、'取消'会话保持 
 
kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"None"}}'  

三  四层Service获取源IP

（1）官网的说明

kubectl expose deployment source-ip-app \
 
  --name=clusterip --port=80 --target-port=8080
 
说明： 通过'expose'命令的方式创建Service
 
备注： 如果'没有指定类型'默认就是'Cluster IP'

kubectl expose deployment source-ip-app \
 
  --name=nodeport --port=80 --target-port=8080 --type=NodePort

Load Blance后续专题讲解 

说明： 由于不同的云厂商,'Load Blance'实现的差异性,后续讲解'几个大厂'的特性

（2）Node Port获取Client IP的方式

kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'

说明： 下面的'备注'有问题,'Cluster'会造成'二跳'的
 
ExternalTrafficPolicy的'默认值'是'Cluster'
 
Local： 保留客户端'源 IP '并避免 LoadBalancer 和 Nodeport 类型服务的第二跳
 
--> 但存在潜在的'不平衡'流量传播风险 --> 一个Node上'多个实例'

访问Kubernetes Service时的客户端源IP问题 

流量图

实验思路

通过'前后对比'修改该参数的数值,查看nginx日志中'客户端的ip'

ExternalTrafficPolicy说明 Cluster和Local的解读

从Service的externalTrafficPolicy到podAntiAffinity

测试如下

验证输出

继续验证

场景： 两个node,但是只有'一个副本'
 
--> 分别通过'node1:nodePort'和'node2:nodePort'访问'实验现象' -->'本次以浏览器的形式'
 
说明： 为了保持'实验环境的干净',把'工作负载删除',然后'重建'

说明： 很显然pod落在'node2上',我们尝试通过chrome浏览器访问--> 'node1:nodePort'

访问： 通过'node2:nodePort'的形式访问,并观察'nginx的日志'

后续探讨： 不设置保留源ip和设置保留源ip,'iptales规则是如何实现'
 
补充： 关于'ipvs的实现'先了解即可
 
备注： 记得lvs的'Full Nat'方式,通过options的形式也可以获取'客户端的ip'

四   关于上述问题在华为CCE官网

阿里云参考细节

创建一个K8s集群,为什么会多出来两个SLB? Ingress组件需要安装吗?

Service的负载均衡配置注意事项

容器服务Kubernetes集群中SLB实例的具体用途

ACK: 如果创建Kubernetes集群时'勾选'了 安装 Ingress 组件,那么会创建'两个'SLB实例

通过使用已有SLB的服务公开应用 

在node上通过 "--ipvs-scheduler"参数,指定 ipvs模式下kube-proxy的启动算法为sh

Service 异常问题排查

ACK Flannel网络插件