kubernetes系列(九)

1. Service概念
2. Service的类型
3. Service代理模式
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资源清单

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开始使用iptables
ipvs：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