k8s 之服务发现（service）

一、基本概念

Pod 是有生命周期的，可以被创建且销毁之后不会再启动。而使用 Deployment 来运行您的应用程序，则它可以动态创建和销毁 Pod。就之前学习的知识，我们都是部署单独的服务，并没有应用实际的示例。比如，我们现在部署一个前后端分离的项目，前端是一组 Pod，后端也是一组 Pod，那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用后端部分？

Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 来实现的。

Service 能够提供负载均衡的能力，但是在使用上有以下限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的。

二、类型介绍

Service 在 K8S 中有以下四种类型

类型	用途介绍
`clusterIp`	默认类型，自动分配一个仅`clusterIp`内部可以访问的虚拟ip地址
`NodePort`	在`ClusterIP`基础上为`Service`在没太机器上绑定一个端口，这样就可以通过`:NodePort`来访问改服务
`LoadBalancer`	在`NodePort`基础上借助`Cloud provider`创建一个外部负载均衡器，并将请求转发到`:NodePort`来访问改服务
`ExternalName`	把集群外部的服务引入到季军内部来，在集群内部直接使用，没有任何类型代理被创建，这只有`kubernetes1.7`或者更高版本的`kube-dns`才支持

VIP(虚拟 IP 地址)和 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 1.14 版本开始默认使用 ipvs 代理。在 Kubernetes v1.0 版本，Service 是 “4 层”(TCP/UDP over IP)概念。在 Kubernetes v1.1 版本，新增了 Ingress API(beta版)，用来表示 “7 层”(HTTP)服务。

注意，ipvs 模式假定在运行 kube-proxy 之前的节点上都已经安装了 IPVS 内核模块。当 kube-proxy 以 ipvs 代理模式启动时，kube-proxy 将验证节点上是否安装了 IPVS 模块。如果未安装的话，则 kube-proxy 将回退到 iptables 的代理模式。

三、代理模式

userspace 代理模式

iptables 代理模式

ipvs 代理模式

这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints，调用 netlink 接口以相应地创建 ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。

与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

类型	用途介绍
`rr`	轮询调度
`lc`	最小连接数
`dh`	目标哈希
`sh`	源哈希
`sed`	最短期望延迟
`nq`	不排队调度

四、ClusterIP

ClusterIP 主要在每个 node 节点使用 ipvs/iptables，将发向 ClusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 Service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。

为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver 用户通过 kubectl命令向 apiserver 发送创建 service 的命令，apiserver 接收到请求后将数据存储到 etcd 中。
kube-proxy 在 kubernetes 的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知 service 和 pod 的变化，并将变化的信息写入本地的 ipvs/iptables 规则中。
ipvs/iptables 使用 NAT 等技术将 VirtualIP 的流量转至 endpoint 中。

对应配置文件，如下所示：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-apps
  namespace: test-hl
  labels:
    app: nginx        
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginxapps
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports: 
        - containerPort: 88
        resources:
          limits:
            cpu: '1'
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 512Mi
---                      
apiVersion: v1
kind: Service
metadata:
  name: nginx-apps
  namespace: test-hl
spec:
  selector:
    app: nginx  # 具有app=nginx-app标签的pod都属于该服务
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 88 # 该服务的可用端口
    targetPort: 80  # 服务将连接转发的容器的端口

启动服务

$ kubectl apply -f 01-create-clusterIp.yaml

查看SVC服务

$ kubectl get svc -n test-hl
NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP      PORT(S)                      AGE
nginx-apps           ClusterIP   10.233.61.228   <none>           88/TCP                       2m1s

查看POD服务

kubectl get pod -n test-hl

查看对应的IPVS防火墙规则

$ ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
 -> RemoteAddress:Port         Forward  Weight  ActiveConn  InActConn
TCP  10.99.10.103:80 rr
 -> 10.244.1.66:80         Masq     1       0           0
 -> 10.244.1.68:80         Masq     1       0           0
 -> 10.244.1.69:80         Masq     1       0           0

五、Headless

有时不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定 Cluster IP(spec.clusterIP) 的值为 “None” 来创建 Headless Service。这类 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。

对应配置文件，如下所示：

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

启动服务之后，可以查到对应的防火墙规则和默认的 SVC 服务。

# 启动服务
$ kubectl create -f myapp-svc-headless.yaml

# 查看SVC服务
$ kubectl get svc -n default
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP     125d
myapp-headless  ClusterIP   none            <none>        80/TCP      19m

# 查找K8S上面的DNS服务对应IP地址(任意一个即可)
$ kubectl get pod -n kube-system -o wide
NAME                      READY   STATUS    RESTARTS   AGE    IP            NODE           NOMINATED NODE   READINESS GATES
coredns-12xxcxc5a-4129z   1/1     Running   3          23h    10.244.0.7    k8s-master01   <none>           <none>

# 查找对应无头服务的SVC解析的A记录
$ dig -t A myapp-headless.default.svc.cluster.local. @10.244.0.7
;; ANSWER SECTION:
myapp-headless.default.svc.cluster.local.  30  IN  A 10.244.1.66
myapp-headless.default.svc.cluster.local.  30  IN  A 10.244.1.68
myapp-headless.default.svc.cluster.local.  30  IN  A 10.244.1.69

六、NodePort

nodePort 的原理在于在 node 上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy 进一步到给对应的 pod。

编写资源清单文件

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app-nodeport
  labels:
    app: nginx-app        
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-app 
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginxapp
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports: 
        - containerPort: 88
        resources:
          limits:
            cpu: '1'
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 512Mi
---                      
apiVersion: v1
kind: Service
metadata:
  name: nginx-app
spec:
  selector:
    app: nginx-app  # 具有app=nginx-app标签的pod都属于该服务
  type: NodePort
  ports:
  - protocol: TCP
    nodePort: 30001
    port: 88 # 该服务的可用端口
    targetPort: 80  # 服务将连接转发的容器的端口

应用资源清单文件

root@k8s1:/home# kubectl apply -f 05-create-deployment-service-nodeport.yaml 
deployment.apps/nginx-app-nodeport created
service/nginx-app created

验证资源对象创建情况

root@k8s1:/home# kubectl get service
NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP      PORT(S) 
nginx-app            NodePort    10.233.12.32    <none>           88:30001/TCP                 63s

查看k8s集群所有主机30001端口侦听状态

root@k8s1:/home# ss -anput | grep ":30001"
tcp     LISTEN        0         128                            0.0.0.0:30001                                              0.0.0.0:*                              users:(("kube-proxy",pid=1607146,fd=19))

在k8s集群外访问Service

在物理机浏览器中访问即可验证

地址：服务器ip:30001****

七、LoadBalancer

loadBalancer 和 nodePort 其实是同一种方式。区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用 cloud provider 去创建 LB 来向节点导流。

八、ExternalName

这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容，例如：hub.escapelife.site。ExternalName Service是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

当查询主机 my-service.defalut.svc.cluster.local 时，集群的 DNS 服务将返回一个值 hub.escapelife.site 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。

对应配置文件，如下所示：

kind: Service
apiVersion: v1
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName: hub.escapelife.site

启动服务之后，可以查到对应的防火墙规则和默认的 SVC 服务。

# 查看SVC服务
$ kubectl get svc -n default
NAME            TYPE            CLUSTER-IP      EXTERNAL-IP           PORT(S)        AGE
kubernetes      ClusterIP       10.96.0.1       <none>                443/TCP        125d
my-service-1    ExternalName    <none>          hub.escapelife.site   <none>         3m
myapp           NodePort        10.99.10.103    <none>                80:30715/TCP   24m
myapp-headless  ClusterIP       none            <none>                80/TCP         45m

# 查找对应无头服务的SVC解析的A记录
$ dig -t A my-service-1.default.svc.cluster.local. @10.244.0.7
;; ANSWER SECTION:
my-service-1.default.svc.cluster.local.  30  IN  CNAME  hub.escapelife.site

k8s 之服务发现（service）