kubernetes系列(九) - 深入掌握Service
1. Service概念
通过创建service可以为一组相同功能的容器应用提供一个统一的入口，并将请求均衡负载发送到后端的各个容器应用上
- 通常是通过
label selector来实现选中具体哪些容器的 - 均衡负载算法默认是RR (
Round-Robin 轮询调度) - 还可以通过设置
service.spec.sessionAffinity=ClientIp来启用SessionAffinity策略 service只提供4层负载均衡能力(只能基于ip地址和端口进行转发)，而没有7层功能(不能通过主机名及域名的方案去进行负载均衡)，但有时我们可能需要更多的匹配规则来转发请求，这点上4层负载均衡是不支持的
2. Service的类型
2.1 ClusterIP（默认）
在集群的内部ip上公开服务。这种类型使得只能从集群内访问服务
2.1.1 原理
clusterIP主要在每个node节点使用iptables(新版本模式是ipvs)，将发向clusterlP对应端口的数据，转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口
为了实现图上的功能，需要以下几个组件协调工作：
api-server：用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中kube-proxy:kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中iptables: 使用NAT等技术将virtuallP的流量转至endpoint中
2.1.2 ClusterIP资源清单
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: ClusterIP
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
2.2 NodePort
在每个node上的相同端口上公开服务，可以从集群外部访问服务。ClusterIP的超集, 最常用
2.2.1 NodePort资源清单
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
type: NodePort
selector:
app: myapp
release: stabel
ports:
- name: http
port: 80
targetPort: 80
- iptables查询nodeport
iptables -t nat -nvL KUBE-NODEPORTS
2.3 LoadBalancer
在NodePort的基础上，在当前云中创建一个外部负载平衡器（如果支持），并为该服务分配一个固定的外部IP。NodePort的超集
即使用云服务商均衡负载服务，需要付费
2.4 ExternalName
通过返回具有该名称的CNAME记录，使用任意名称（在规范中指定）公开服务。不使用代理。此类型需要v1.7或更高版本kube-dns
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: default
spec:
type: ExternalName
externalName: hub.coreqi.cn
3. Service代理模式
在kubernetes集群中，为每个节点运行了一个kube-proxy，kube-proxy负责为service实现一种virtual ip的形式，而这个过程称之为service代理模式。不同的kubernetes版本，代理模式的实现方式也不尽相同，前后共有三种模式：
userspace：kubernetes v1.0版本使用的是这种代理模式，已过期iptables：从kubernetes v1.2开始使用iptablesipvs：kubernetes v1.14开始默认使用ipvs代理
3.1 userspace
从下可以看出客户端想要访问到具体的server pod，需要
- 经过防火墙iptables
- 经过
kube-proxy负责转发 - 到达
server pod
- 缺点：对
kube-proxy的压力很大
3.2 iptables
3.2.1 原理
从下可以看出客户端想要访问到具体的server pod，需要
- 经过
iptables直接转发 - 到达
server pod
- 这过程中
kube-proxy只负责维护iptables的对应规则
3.2.2 查看iptables代理规则
iptables -t nat -nvl
iptables -t nat -nvL KUBE-NODEPORTS
3.3 ipvs
3.3.1 原理
从下可以看出客户端想要访问到具体的server pod，需要
- 经过
ipvs直接转发 - 到达
server pod
ipvs这种模式，kube-proxy会监视Kubernetes service 对象和Endpoints，调用netlink 接口以相应地创建ipvs 规则并定期与Kubernetes service对象和Endpoints 对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod
与iptables类似，ipvs于netfilter的hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如
- rr：轮询调度
- 1c：最小连接数
- dh：目标哈希
- sh：源哈希
- sed:最短期望延迟
- nq：不排队调度
注意: ipvs需要节点上的ipvs内核模块支持，如果未安装，则kube-proxy将回退到iptables代理模式
3.3.2 查看ipvs代理规则
ipvsadm -Ln
4. Headless Service
Headless Service也是一种Cluster IP,只不过是一种特殊的Cluster IP
4.1 存在的意义
- 有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定
ClusterIP(spec.clusterIP)的值为None来创建Headless Service。这类Service:- 并不会分配
Cluster IP** kube-proxy不会处理它们- 平台也不会为它们进行负载均衡和路由
- 并不会分配
- 主要的特点是通过无头服务的方式去解决hostname和portname的变化问题，也就是通过它去进行绑定
4.2 Headless Service资源清单
apiVersion: v1
kind: Service
metadata:
name: myapp-headless
namespace: default
spec:
selector:
app: myapp
clusterIP: "None"
ports:
- port: 80
targetPort: 80
