SVC 四层路由的负载
ingress 七层路由的负载
创建service,其实是由kube-proxy生成一套访问规则
?kube-proxy每个节点都有,监听SVC的创建,会将最新的Service信息转换成对应的访问规则
?rr? 轮询
kube-proxy三种工作模式
发向clusterIp的请求,被iptables规则重定向到kube-proxy端口上,kube-proxy(LB算法)选一个pod处理请求?
iptables规则
kube-proxy只负责生成规则
可能会拿到有问题的pod
ipvs 当前最为流行的模式
ip virtual server: 支持更多的轮询算法
创建svc ,kube-proxy会生成一套ipvs策略,当请求进来的时候,会基于策略进行转发到对应的pod
?
?不安装会降级,降到第二种工作模式,
?经查看,当前没有ipvs规则
?
edit cm 采用ipvs规则
?
?再次查看,是否生成对应的规则
?
??SVC 本身是一批转发规则
Service类型-四种
标签选择器,本质上会变成请求转发规则
?sessionAffinity:session亲和性,同一个源请求,每次转发到相同的pod
三个端口 service pod 主机node
type:service 类型,支持4种
clusterip:集群内部访问
nodePort:支持集群外部访问
loadBanlancer: 外接负载均衡器进行分发
?第一步创建pod
?查看创建的pod?
?查看pod ip
?kubectl exec -it 进入到容器中?,修改Linux首页
?
其它三个同理
?
创建clusterIp类型的SVC
?svc创建成功
?describe svc ,查看详细信息
endpoint是一个访问地址
endpoints对象记录一个svc对应的所有pod的访问地址
?根据svc 的selector的值,产生endpoint对象
get? endpoints
ipvsadm -Ln 查看规则
?
?循环访问测试,命令行可以直接输入shell 脚本,
每次都是请求同一个svc,但是被转发到不同的pod上
?负载分发策略
session亲和性,客户端ip
?
?
?可以看到,路由规则变了
?
效果就是,同一个ip,只会转发到同一个pod
?clusterIP 是集群内部ip,外部不可以访问
?headLiness类型
不使用svc提供的负载均衡,而是自己来控制负载均衡策略
?get svc,describe svc?
?没有ip,如何访问的呢? 通过域名进行访问
?clusterip:要么产生ip地址(集群内部访问),要么不产生ip地址(成为无头服务,通过域名访问)
NodePort类型的SVC
将svc的端口映射到node的端口上,然后可以通过nodeip:nodePort进行访问了
?
?
?LoadBalancer类型的svc
vip?
externalName类型的svc?
?
?
?
?