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）