5.Service资源
外部应用访问集群内的服务:
NodePort
LoadBalancer
Ingress –> ingress controller、ingress服务(使用开源的反向代理负载均衡来实现对外暴露服务,比如Nginx,Haproxy,envoy,traefik)
深入了解service:https://mp.weixin.qq.com/s/_V9RdjYzMT_XcnPIKuiI_w
kube-proxy使用详解:https://blog.csdn.net/xixihahalelehehe/article/details/115370095
一、Service资源
为屏蔽后端实例的动态变化和对多实例的负载均衡。
CoreDNS Kube-DNS
CNI(container network interface)
Node network
Pod network
Cluster network (virtual ip)
Kube-proxy是一个简单的网络代理和负载均衡器,它的作用主要是负责Service的实现,具体来说,就是实现了内部从Pod到Service和外部的从NodePort向Service的访问,每台机器上都运行一个 kube-proxy 服务,它监听 API server 中 service 和 endpoint 的变化情况,并通过 iptables 等来为服务配置负载均衡(仅支持 TCP 和 UDP)。
1、Service的工作模式:
工作在四层协议(TCP/UDP)
userspace 1.1版本之前, kube-porxy接收并调度,工作在用户空间,效率很低,因为需要来回在内核空间到用户空间反复转换。
iptables 1.10版本之前
ipvs 1.11版本之后,需要在配置文件(/etc/sysconfig/kubelet)中添加配置:KUBE_PROXY_MODE=ipvs,并且节点主机应该在开机启动时自动装载ip_vs,ip_vs_rr,ip_vs-wrr,ip_vs_sh,nf_conntrack_ipv4
2、Service的类型:
ClusterIP:集群内部,没法出集群访问。
NodePort::client --> NodeIP:NodePort --> ClusterIP:ServicePort --> PodIP:containerPort
LoadBalancer:部署在公有云上,使用云上的LB服务
ExternalName:FQDN的记录,别名解析记录(CNAME)。
No ClusterIP:Headless Service
ServiceName --> PodIP
ClusterIP包含两类:一类为普通Service,为service分配一个集群内部可以访问的固定虚拟Ip;另一类为Headless Service,不分配ClusterIP,不通过Kube-proxy做反向代理或负载均衡。通过DNS提供稳定的ID来访问,DNS会将Headless Service的记录直接解析为PodIP列表,主要供StatefulSet使用。
每一个service创建好之后,都会在dns中动态添加相应的资源记录。资源记录的格式:SVC_NAME.NS_NAME.DOMAIN.LTD -- redis.default.svc.cluster.local
3、创建清单资源:
svc.spec.sessionAffinity #会话粘性,ClientIP来自于同一个客户端IP的用户请求,始终发往同一个后端Pod;默认值None
svc.spec.clusterIP:“”,None,or a valid ip。当为None时,Headless Service(没有clusterIP的service,资源记录会直接解析到后端Pod的IP)