k8s 详解 SVC(service) clusterIp,headliness,nodePort,loadBanlance,externalName_svc nodeport

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