K8S实战（十）| Service

前言

Pod 已经成功运行起来了，但是有两个问题。

一是这些 Pod 无法从集群外部直接访问到，二是 Pod 出现故障自愈后，IP 会发生变化。

如何解决这两个问题，这里有一个非常重要的概念：Service

更新历史

20200625 - 初稿 - 左程立
原文地址 - https://blog.zuolinux.com/2020/06/25/about-service.html

Service 的意义和特点

对一组 Pod 提供负载均衡（工作在 TCP/UDP 4 层）
防止 Pod 更换 IP 失联，即服务发现
通过 label selector 关联 Pod

Service 工作原理

Service 是由 kube-proxy 组件加上 iptables/LVS 共同实现。
说白了就是通过 kube-proxy 生成了一堆 iptables 规则，通过 iptables 规则来转发数据。

iptables 转发：

K8S 默认的转发设置。
选择后端 Pod 为随机选择。
当 Pod 没有响应，连接会失败，并没有健康检查机制。
需要配合 Pod 就绪探测器来确保访问到健康的 Pod。
当集群规模达到上万个服务时，iptables 转发效率会显著降低。

LVS转发：

基于内核哈希表，性能强大，具有更高网络吞吐量。
适用于 Pod 量级大，转发规则更多的大规模集群。
LVS 支持更多的 Pod 负载均衡调度算法。
LVS 只负责负载均衡和代理功能，剩余的包过滤和SNAT等操作还是需要 iptables 处理，但这些操作规则数量不会因 Pod 数量的增加而增加。
也叫 IPVS 。

Service 的默认工作方式

创建 Pod 和默认Service，进行默认工作状态的测试。

先创建3个 Pod

cat nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

创建一个默认类型的 Service，名称为 nginx-service

cat nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

port: 80
是 service 在集群内部的VIP端口

targetPort: 80
是 Pod 的端口

执行创建

kubectl apply -f nginx.yaml 
kubectl apply -f nginx-service.yaml

查看运行情况

[root@master01 ~]# kubectl get pod -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP               NODE     NOMINATED NODE   READINESS GATES
nginx-deployment-d46f5678b-cldf4   1/1     Running   0          21m   192.10.137.153   work03              
nginx-deployment-d46f5678b-lnxh9   1/1     Running   0          21m   192.10.205.252   work01              
nginx-deployment-d46f5678b-th8xq   1/1     Running   0          21m   192.10.75.89     work02              

[root@master01 ~]# kubectl get service
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
nginx-service   ClusterIP   192.20.150.26           80/TCP    13m

查看名称为 nginx-service 的 service 成功挂载的后端 Pod

[root@master01 ~]# kubectl get endpoints nginx-service
NAME            ENDPOINTS                                             AGE
nginx-service   192.10.137.153:80,192.10.205.252:80,192.10.75.89:80   14m

可以看到我们创建的名为 nginx-service 的 Service 后端挂载了3个 Pod

给3个 Pod 写入内容，访问 Pod 时返回自身的主机名

kubectl exec nginx-deployment-d46f5678b-cldf4 -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html';
kubectl exec nginx-deployment-d46f5678b-lnxh9 -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html';
kubectl exec nginx-deployment-d46f5678b-th8xq -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html';

我们访问 Service IP 看看

[root@master01 ~]# curl 192.20.150.26
nginx-deployment-d46f5678b-th8xq
[root@master01 ~]# curl 192.20.150.26
nginx-deployment-d46f5678b-cldf4
[root@master01 ~]# curl 192.20.150.26
nginx-deployment-d46f5678b-lnxh9

可以看到 Service 成功将请求代理到了后端的一组 Pod，并且进行了流量的分配。

这是 Service 的默认工作类型，只能在集群所属的节点上访问到，离开集群后无法被访问到。

这种工作类型叫做 ClusterIP。

Service 对外提供服务的三种方式

上一节可以看到，Service 默认不对集群外部提供服务，那么如何才能在集群外部访问到呢，有三种方案。

externalIPs 方式

Service 中配置可以 externalIPs，IP 为本集群中 work 节点宿主机 IP。

apiVersion: v1
kind: Service
。。。
。。。
spec:
  。。。
  。。。
  externalIPs:
    - 192.168.10.16
    - 192.168.10.17

在 192.168.10.16/17 上执行 ss -lntp 可以看到 Service 定义的暴露端口。
在集群外部访问 192.168.10.16/17 上 Service 暴露的端口即可。

NodePort 方式

改造 nginx-service.yaml，增加一行 type: NodePort

cat nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

创建 service

kubectl apply -f nginx-service.yaml

查看运行情况

[root@master01 ~]# kubectl get service
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
nginx-service   NodePort    192.20.167.221           80:30913/TCP   13m

参数 PORT(S) 80:30913/TCP，其中 30913 就是用来集群外部访问的端口。

可以访问任何一台物理宿主机的 ip:30913 来访问到 Pod。

30913 是 K8S 从固定范围 30000-32767 中选择的，也可以通过参数 nodePort 指定固定端口。

可选择范围可以通过 kube-apiserver 的 –service-node-port-range 参数来修改。

[root@master01 ~]# ss -nltp | grep 30913
LISTEN     0      128          *:30913                    *:*

可以看到宿主机上监听了 30913 端口。

测试

在没有运行 K8S 集群的机器上访问 K8S 宿主机

[root@192-168-10-18 ~]# curl 192.168.10.12:30913
nginx-deployment-d46f5678b-2pmts
[root@192-168-10-18 ~]# curl 192.168.10.12:30913
nginx-deployment-d46f5678b-zv8m4
[root@192-168-10-18 ~]# curl 192.168.10.12:30913
nginx-deployment-d46f5678b-2pmts

可以看到从集群外部可以成功访问到 Pod 中内容，并且为随机分配。

原理

kube-proxy 在宿主机上创建了 iptables 规则，对宿主机 IP:30913 的访问将被转发到 Service IP，然后 Service 再通过自己的 iptables 规则分发到 Pod

LoadBalancer 方式

NodePort 方式中，如果要正式对外提供服务，我们需要在集群外部再创建一个高可用的负载均衡器，以方便把流量转发到宿主机开放的端口上，如果宿主机开放端口发生了变更，我们需要手工修改前端负载均衡器。

公有云的 LoadBalancer 自动化了这一过程。

LoadBalancer 这种方式应用于公有云，提交一个 type: LoadBalancer 的 Service 创建申请后，公有云会帮我们创建一个负载均衡器，该负载均衡器会把请求直接分发给 Pod，同时 Pod IP 发生变化后，会自动更新到负载均衡器上。

其他：Headless Service

通过指定 spec.clusterIP 的值为 "None" 可以创建 Headless Service。

Headless Service 不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。

定义了 selector 的无头服务，Endpoint 控制器会在 API 中创建 Endpoints 记录，并且修改 DNS 配置返回 A 记录，通过这个地址，请求可以直接到达 Service 的后端 Pod 上。

结束语

Service 对 IP 信息易变的 Pod 提供了服务发现、负载均衡等管理功能，同时提供了外部访问的能力，从而使外部用户能够稳定的访问到运行在集群内部的 Pod 提供的服务。

上面说的三种工作方式有如下问题：

ClusterIP 方式默认工作在集群内部，使用参数 externalIPs 可指定哪个及诶按暴露端口，但无法进行7层的URL跳转等控制
NodePort 方式下，全部节点都会暴露该端口，但一个端口只能对应一个业务，适合业务比较少的环境或者测试环境，业务多了以后无法有效管理
LoadBalance 方式只适合于现有的公有云平台，无法用于自建集群，同时还需要额外费用

这些问题导致无法直接应用于生产环境中。

如果想提供给自建集群的生产环境使用，需要在 Service 前面再加一层 Ingress Controller。