Service 概念

Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。

Service 通常是通过 Label Selector，也就是 Service 通过标签选择的方式匹配一组 Pod 对外提供访问的机制。

解释上图具体实现过程：

首先、定义一个 Nginx Deployment由它创建三个Pod，每个 Pod 中都有对应的标签mynginx。

第二、定义一个Nginx Service，标签为mynginx，Service 会根据自己的标签去匹配后端的 Pod 标签，从而把它们加入队列中提供对外服务，当然标签可以定义多个。

第三、当我们Client访问Nginx Service的时候，Service 会以轮询的访问策略来对外提供服务。

第四、当我们后端的Pod挂掉的时候，Nginx Deployment会重新创建一个新的Pod来满足期望值，Service 会自动的将新 Pod 加入到负载均衡队列中。

Service提供负载均衡的能力限制：

Service 只提供 4 层负载均衡能力，并没有 7 层功能，也就是说只能基于IP地址和端口进行转发实现负载均衡。

需要提供 7 层负载均衡能力可以通过 Ingress 负载均衡方案来实现，后面的文章中会介绍，欢迎关注我哦。

Service 类型讲解

Service 具有四种类型：

ClusterIP： 默认类型，自动分配一个集群内部虚拟IP地址，只能被集群内部访问。（常用）

NodePort： 通过每个节点上的 IP 和静态端口（NodePort）暴露服务，提供对外访问。也就是说我们可以通过集群中任意一个节点 IP 地址和端口来访问后的 Pod 应用。（常用）

LoadBalancer： 使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。（摘自于官方）

ExternalName： 把集群外部的服务引入到集群内部来，在集群内部直接使用。

也就是说假设外部有一个数据库集群，集群内部的Service只需要写集群外部IP地址信息，集群内部的Pod就可以实现访问。

如果某一天外部集群 IP 地址发生变化，只需要更新集群内部的Service信息，内部的Pod还是可以正常访问外部数据库集群。

VIP 和 Service 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName的形式。

在 Kubernetes v1.0 版本，代理完全在 userspace 。在 Kubernetes V1.1 版本，新增了 iptables 代理，但并不是默认的运行代理模式。

从 Kubernetes V1.2 开始，默认代理模式为 iptables；在 Kubernetes V1.8.0-beta.0 中，添加了 IPVS 代理。

然后从 Kubernetes V1.14 版本开始默认使用 IPVS 代理模式。

userspace 代理模式

当 Client 需要访问 Pod 时，首先需要访问 iptables，再从防火墙访问到 Kube-proxy，再从 Kube-proxy 访问到对应的 Pod。

无论 Client 访问本地的 Pod 还是其他节点的 Pod 都需要通过 Kube-proxy 来代理，包括 apiserver 也会监控 Kube-proxy 进行服务更新等操作，这样会导致 Kube-proxy 压力巨大。

iptables 代理模式

通过如下图可以看到，所有的访问都是通过 iptables 来完成，而不需要通过 Kube-proxy 来调度，这样的话，访问速度加快，而 Kube-proxy 压力减少，稳定性就会提升。

IPVS 代理模式

IPVS 代理模式跟 iptables 代理模式中的区别只是把 iptables 变成 IPVS ，其他的没有变。IPVS 是在内核空间中工作，意味着通信的延迟更短，性能更好。如果没有安装 IPVS 模块，则 kube-proxy 将退回到以 iptables 代理模式运行。

Service 实验演示

ClusterIP 类型

首先创建 Deployment ，my-nginx.yaml文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx   # 标签匹配
  replicas: 3
  template:
    metadata:
      labels:
        run: my-nginx # 定义标签
    spec:
      containers:
      - name: my-nginx
        image: hub.test.com/library/mynginx:v1
        ports:
        - containerPort: 80

创建 Deployment 以及查看状态信息

[root@k8s-master01 ~]# kubectl apply -f my-nginx.yaml 
deployment.apps/my-nginx created
[root@k8s-master01 ~]# kubectl get deploy 
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   3/3     3            3           8s
[root@k8s-master01 ~]# kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-94fb9fc7c-2xjqc   1/1     Running   0          11s
my-nginx-94fb9fc7c-rmwtr   1/1     Running   0          11s
my-nginx-94fb9fc7c-x969q   1/1     Running   0          11s

此时已经可以访问每一个 Pod ，为了防止后端的 Pod 挂掉之后重新创建新的 Pod ，IP地址也会随着改变，所以要通过 Service （服务发现）来保证可靠性。

接下来创建 Service，my-nginx-svc.yaml配置文件如下

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service  # Service 名称
spec:
  type: ClusterIP   # Service 类型
  selector:
    run: my-nginx   # 标签匹配后端 Pod
  ports:
      # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80

创建 Service 和查看状态

[root@k8s-master01 ~]# kubectl apply -f my-nginx-svc.yaml 
service/my-nginx-service created
[root@k8s-master01 ~]# kubectl get svc
NAME               TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
kubernetes         ClusterIP   10.96.0.1     <none>        443/TCP   22d
my-nginx-service   ClusterIP   10.100.13.4   <none>        80/TCP    7s

查看 Service 详细事件时，可以看到后端的 IP 地址都对应着每一个 Pod。

访问 Service IP 地址实际是访问后端的 Pod，Service 做了一个轮询的访问策略。

[root@k8s-master01 ~]# curl 10.100.13.4
version: v1
hostname: my-nginx-94fb9fc7c-2xjqc
[root@k8s-master01 ~]# curl 10.100.13.4
version: v1
hostname: my-nginx-94fb9fc7c-x969q
[root@k8s-master01 ~]# curl 10.100.13.4
version: v1
hostname: my-nginx-94fb9fc7c-rmwtr

NodePort 类型

利用刚刚创建好的 Deployment，这里只需要修改 Service 文件重新创建即可。my-nginx-svc.yaml文件如下

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service  # Service 名称
spec:
  type: NodePort   # Service 类型
  selector:
    run: my-nginx   # 标签匹配后端 Pod
  ports:
      # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767）
      nodePort: 30001

创建 Service 和查看状态

[root@k8s-master01 ~]# kubectl apply -f my-nginx-svc.yaml 
service/my-nginx-service created
[root@k8s-master01 ~]# kubectl get svc
NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes         ClusterIP   10.96.0.1      <none>        443/TCP        22d
my-nginx-service   NodePort    10.104.50.48   <none>        80:30001/TCP   6s

外部访问端口30001，集群中任意一个节点的IP地址加上端口访问即可。

由于实验环境原因LoadBalancer 类型 和ExternalName 类型没有进行实验演示，下一章更新 Ingress 基本概念及功能演示的学习笔记，欢迎关注我。