kubernetes系列(九) - 深入掌握Service

• 1. Service概念
• 2. Service的类型
  • 2.1 ClusterIP（默认）
    • 2.1.1 原理
    • 2.1.2 ClusterIP资源清单
  • 2.2 NodePort
    • 2.2.1 NodePort资源清单
  • 2.3 LoadBalancer
  • 2.4 ExternalName
• 3. Service代理模式
  • 3.1 userspace
  • 3.2 iptables
    • 3.2.1 原理
    • 3.2.2 查看iptables代理规则
  • 3.3 ipvs
    • 3.3.1 原理
    • 3.3.2 查看ipvs代理规则
• 4. Headless Service
  • 4.1 存在的意义
  • 4.2 Headless 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资源清单#

Copy
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资源清单#

Copy
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

Copy
iptables -t nat -nvL KUBE-NODEPORTS

2.3 LoadBalancer#

在NodePort的基础上，在当前云中创建一个外部负载平衡器（如果支持），并为该服务分配一个固定的外部IP。NodePort的超集

即使用云服务商均衡负载服务，需要付费

2.4 ExternalName#

通过返回具有该名称的CNAME记录，使用任意名称（在规范中指定）公开服务。不使用代理。此类型需要v1.7或更高版本kube-dns

Copy
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版本，代理模式的实现方式也不尽相同，前后共有三种模式：

1. userspace：kubernetes v1.0版本使用的是这种代理模式，已过期
2. iptables：从kubernetes v1.2开始使用iptables
3. ipvs：kubernetes v1.14开始默认使用ipvs代理

3.1 userspace#

从下可以看出客户端想要访问到具体的server pod，需要

1. 经过防火墙iptables
2. 经过kube-proxy负责转发
3. 到达server pod

• 缺点：对kube-proxy的压力很大

3.2 iptables#

3.2.1 原理#

从下可以看出客户端想要访问到具体的server pod，需要

1. 经过iptables直接转发
2. 到达server pod

• 这过程中kube-proxy只负责维护iptables的对应规则

3.2.2 查看iptables代理规则#

Copy
iptables -t nat -nvl
iptables -t nat -nvL KUBE-NODEPORTS

3.3 ipvs#

3.3.1 原理#

从下可以看出客户端想要访问到具体的server pod，需要

1. 经过ipvs直接转发
2. 到达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代理规则#

Copy
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资源清单#

Copy
apiVersion: v1 
kind: Service 
metadata:
  name: myapp-headless 
  namespace: default 
spec:
  selector:
    app: myapp 
  clusterIP: "None"
  ports:
  - port: 80 
    targetPort: 80