Kubernetes Service详解

Kubernetes Service详解一、Service介绍

kubernetes提供service资源，service将聚合多个提供相同服务的pod，并提供统一的入口地址。以后的pod服务可以通过访问service的入口地址来访问。

在很多情况下，Service只是一个概念，真正起作用的其实是kube-proxy服务流程，每个Node节点都有kube-proxy服务流程。创建service时，创建的service信息会通过api-server写入etcd，kube-proxy会根据监控机制发现service的变化，然后将最新的service信息转换为相应的访问规则。

#10.97.97.97:80 是service提供的访问入口

#访问这个入口时，可以发现后面有三个pod服务等待调用。

#kube-基于rr(轮询)策略，proxy将要求分发给其中一个pod

#该规则将同时在集群中的所有节点上生成，因此可以访问任务中的一个节点。

[root@master ~]# ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 10.97.97.97:80 rr

-> 10.244.1.39:80 Masq 1 0 0

-> 10.244.1.40:80 Masq 1 0 0

-> 10.244.1.33:80 Masq 1 0 0

 

kube-proxy 目前支持三种工作模式：userspace、iptables、ipvs

在 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.0版本， Service是 4 层（ TCP/ UDP over IP）概念。在 Kubernetes v1.1版本，新增 Ingress API（ beta版)，用来表示 7 层（ HTTP）为什么不使用服务？ round-robin DNS？

DNS将缓存在许多客户端，许多服务将在访问中 DNS完成域名分析，得到地址后不会进行域名分析 DNS的分析是用来清除缓存的，所以一旦有了他的地址信息，无论是访问多少次还是原来的地址信息，负载都是平衡无效的。

userspace模式下，kube-proxy将为每个Service创建一个监控端口，发送到Cluster Iptables规则将IP请求重新定位到kube-proxy监控的端口，kube-proxy根据LB算法选择提供服务的pod并与其建立链接，以将请求转发给pod。

该模式下，kube-proxy扮演着负责平衡器的四层角色。由于kube-proxy在userspace中运行，在转发过程中会增加核心和用户空间之间的数据副本。虽然它相对稳定，但效率相对较低。

在iptables模式下，kube-proxy为service后端的每个Pod创建相应的iptables规则，直接发送到cluster 将IP请求重定向到Pod IP。
该模式下，kube-proxy不承担四层平衡器的角色，只创建iptables规则。该模型的优点是效率高于userspace模型，但不能提供灵活的LB策略，当后端Pod不可用时也不能重试。

iptables 是一个 Linux 核心功能是一种高效的防火墙，提供了大量的数据包处理和过滤能力。可用于核心数据包处理管道 Hook 连接一系列规则。iptables 模式中 kube-proxy 在NAT pre-routingHook 中实现它的 NAT 与负载平衡功能。这种方法简单有效，依赖于成熟的核心功能，可以与其他核心功能相匹配 iptables 合作的应用(例如 Calico）融洽相处。

然而 kube-proxy 一种用法 O(n) 算法，其中 n 随着集群规模的同步增长，这里的集群规模更加明确，即服务和后端 Pod 的数量。

iptables模式类似于ipvs模式。kube-proxy监控Pod的变化，创建相应的ipvs规则，ipvs转发效率高于iptables。此外，ipvs还支持更多的LB算法。
ipvs内核模块必须安装在这种模式下，否则会降级为iptables。

IPVS 负载均衡用于负载均衡 Linux 内核功能。IPVS 模式下，kube-proxy 使用 IPVS 替代了负载均衡 iptable。这种模式也有效，IPVS 该设计用于平衡大量服务的负载。它有一套优化的 API，使用优化的搜索算法，而不是简单地从列表中找到规则。

这样一来，kube-proxy 在 IPVS 在模式下，连接过程的复杂性是 O(1)。换句话说，在大多数情况下，他的连接处理效率与集群规模无关。

另外，作为一种独立的负载均衡器，IPVS 它包含各种不同的负载平衡算法，如轮询、最短期望延迟、至少连接和各种哈希方法。 iptables 只有一种随机平等的选择算法。

IPVS 一个潜在的缺点是，IPVS 通常，处理数据包的路径和路径 iptables 过滤器的路径不同。如果计划在其他程序中使用 iptables 在环境中使用 IPVS，我们需要做一些研究，看看他们能否协调工作。（Calico 已经和 IPVS kube-proxy 兼容）

VS/NAT模式，基本原理和过程，

打开ipvs

#编辑kube-proxy kubectl edit cm kube-proxy -n kube-system 修改mode: "ipvs"   #删除kube-proxy对应的pod kubectl delete pod -l k8s-app=kube-proxy -n kube-system   #查看规则 ipvsadm -Ln

二、Service类型

Service资源清单文件：

apiVersion: v1  #版本号 kind: Service #类型 metadata:  #元数据   name: service   #名称   namespace:  dev #命名空间 spec:  #详情描述   selector: #选择器，用于确定当前service代理的podde     app: nginx   type: #Service 类型，指定service的访问方式   clusterIP:  #IP地址虚拟服务   sessionAffinity: #session的亲和力，支持ClientIP支持、None有两个选项   ports: #端口信息     - protocol： TCP       port: 3017 #service端口       targetPort: 3005 #pod端口       nodePort: 31123 #主机端口

type类型如下：

• ClusterIP：默认值是kubernetes系统自动分配的虚拟ip，只能在集群内访问。
• NodePort：将Service通过指定的Node端口暴露到外部，这样就可以访问集群外部的服务。
• LoadBalancer：使用外部负载均衡器完成服务负载分配，请注意，该模式需要外部云环境的支持。
• ExternalName：将集群外部服务引入集群直接使用。

三、Service的使用

在使用service之前，首先使用deployment创建三个pod，注意为pod设置应用程序=nginx-pod标签

创建deploymentt创建deploymenttt.yaml，内容如下：

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

#创建deploymentt创建deploymenttt kubectl create -f deployment.yaml   #查看pod细节 kubectl get pods -n dev --show-labels   #为便于测试，修改三台nginxindex.html页面 kubectl exec -it pc-deployment-66cb59b984-8d48h -n dev /bin/sh   #注意这里的ip是否不同 echo "10.244.1.40" > /usr/share/nginx/html/index.html

创建service-clusterip.yaml文件

apiVersion: apps/v1   kind: Service metadata:              name: service-clusterip   namespace:  dev spec:     selector:      app: nginx-pod   clusterIp: 10.97.97.97 #serviceip地址，如果不写，默认会产生一个   type: ClusterIP   ports:     - port: 80 #service端口       targetPort: 80 #pod端口

#创建service kubectl create -f service-clusterip.yaml   #查看service kubectl get svc -n dev -o wide   #查看service的详细信息 kubectl describe svc -n dev -o wide   #查看ipvs映射规则 ipvsadm -Ln

查看service的详细信息

这里有一个Endpoints列表，目前可以负载到服务入口

kubectl describe svc service-clusterip -n dev

使用kubectl get endpoints -n dev查看endpoints信息

对Service的访问被分发到后端pod上，kubernetes提供了两种负载分发策略：

• 若不定义，默认使用kube-proxy策略，如随机、轮询等。
• 基于客户端地址的会话维护模式，即同一客户端发起的所有请求都将转发到固定的Pod上，可以在spec中添加sessionAffinity: ClientIP 选项。

在某些情况下，开发人员可能不想使用Service提供的负载平衡功能来控制负载平衡器策略针对这种情况，kubernetes提供了HeadLinesss Service，这种Service不会分配Cluster IP，要访问service，只能通过service域名查询。

创建service-headliness.yaml

apiVersion: apps/v1   kind: Service metadata:              name: service-headliness   namespace:  dev spec:     selector:      app: nginx-pod   clusterIp: None #将clusterIP设置为None，可以创建headliness service   type: ClusterIP   ports:     - port: 80 #service端口       targetPort: 80 #pod端口

#创建service kubectl create -f service-headliness.yaml   #查看service，此时，CLUSTER-IP位于None kubectl get svc service-headliness -n dev -o wide   #查看service的详细信息 kubectl describe svc service-headliness -n dev -o wide   #查看pod kubectl get pods -n dev #进入其中一个查看 kubectl exec -it pc-deployment-7878451b7d-gid12 -n dev /bin/sh #查看域名分析 cat /etc/resolv.conf   dig @10.96.0.10 service-headliness.dev.svc.cluster.local

在之前的例子中，创建的Serviceip地址只能在集群内部访问。如果要将Service暴露给集群外部使用，则需要使用Nodeport类型的Service。Nodeport的工作原理实际上是将service端口映射到Node端口，然后通过Nodeip:NodePort访问service。

创建service-nodeport.yaml

apiVersion: apps/v1   kind: Service metadata:              name: service-nodeport   namespace:  dev spec:     selector:      app: nginx-pod   type: NodePort   ports:     - port: 80 #service端口       nodePort: 30002 #node端口(默认范围为30000-32767)，不指定的，默认分配       targetPort: 80 #pod端口

#创建service kubectl create -f service-nodeport.yaml   #查看service kubectl get svc service-nodeport -n dev -o wide   #查看service的详细信息 kubectl describe svc service-headliness -n dev -o wide   #查看pod kubectl get pods -n dev   #使用nodeIpod访问pod + nodePort 访问

LoadBalancer与NodePort相似，其目的是将端口暴露到外部。不同之处在于，LoadBalancer将在集群外部制造另一个负载平衡设备。如果该设备需要外部环境的支持，则外部服务发送到该设备的请求将在设备负载后转发给集群。

Externalname类型的Service用于引入集群外部服务。它通过externalname属性指定外部服务地址，然后访问集群内部的Service访问外部服务

apiVersion: apps/v1   kind: Service metadata:              name: service-externalname   namespace:  dev spec:     type: ExternalName #service类型   externalName: www.baidu.com   #ip或域名都可以

创建service

kubectl create -f service-externalname.yaml

域名解析

dig @10.96.0.10 service-externalname.dev.svc.cluster.local

四、Ingress介绍

前面提到的Service暴露集群外服务的主要方式有两种:NodePort和LoadBalancer，但两者都有一定的缺点：

• NodePort的缺点是会占用很多集群机的端口，所以当集群服务越来越多的时候，这个缺点就越来越明显。
• LB模式的缺点是每个service都需要一个LB，浪费，麻烦，需要kubernetes以外的设备的支持。

基于这种情况，kubernetes提供了ingress资源对象，ingress只需要一个nodeport或一个LB就可以满足暴露多个service的需求，如下图所示:

事实上，Ingress相当于一个7层的负载均衡器，是Kubernetes对反向代理的抽象，其工作原理与Nginx相似，可以理解为在Ingress中建立了许多映射规则，Ingress 通过监控这些配置规则，Controller将其转化为Nginx配置，然后提供外部服务。主要有两个核心概念：

• ingress：kubernetes中的一个对象是定义请求如何转发到service的规则。
• ingress controller：实现反向代理和负载平衡的具体程序，分析Ingress定义的规则，并根据配置规则实现请求转发，如Nginx，Contour，Haproxy等等。

Ingress(以Nginx为例)工作原理如下:

1. 用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service
2. Ingress控制器动态感知Ingress服务规则的变化，然后生成相应的Nginx配置
3. Ingress控制器将生成的Nginx配置写入运行Nginx的服务中，并动态更新
4. 到目前为止，真正在工作的是Nginx，内部配备了用户定义的请求转发规则

五、Ingress使用

#创建文件夹 mkdir ingress-controller cd ingress-controller   #获取ingress-nginx，本案例采用0.3版 wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml   #修改mandatory.yaml文件中的仓库，不需要修改   #创建ingress-nginx kubectl apply -f ./   #查看ingress-nginx kubectl get pod -n ingress-nginx   #查看service kubectl get svc -n ingress-nginx

为便于实验，创建以下模型

创建tomcat-nginx.yaml

apiVersion: apps/v1   kind: Deployment metadata:              name: nginx-deployment   namespace:  dev spec:     replicas: 3   selector:      matchLabels:        app: nginx-pod   template:     metadata:       labels:         app: nginx-pod     spec:       containers:        - name: nginx          image: nginx:1.17.1          ports:            - containerPort: 80 --- apiVersion: apps/v1   kind: Deployment metadata:              name: tomcat-deployment   namespace:  dev spec:     replicas: 3   selector:      matchLabels:        app: tomcat-pod   template:     metadata:       labels:         app: tomcat-pod     spec:       containers:        - name: tomcat          image: tomcat:8.5-jre10-slim          ports:            - containerPort: 8080   ---   apiVersion: v1   kind: Service metadata:              name: nginx-service   namespace:  dev spec:     selector:      app: nginx-pod   clusterIP: None   type: ClusterIP   ports:    - port: 80      targetPort: 80   --- apiVersion: v1   kind: Service metadata:              name: tomcat-service   namespace:  dev spec:     selector:      app: tomcat-pod   clusterIP: None   type: ClusterIP   ports:    - port: 8080      targetPort: 8080

创建

kubectl create -f tomcat-nginx.yaml

创建ingress-http.yaml

apiVersion: extensions/v1beta1   kind: Ingress metadata:              name: ingress-http   namespace:  dev spec:     rules:    - host: nginx.ifun.com      http:       - path: /         backend:           serviceName: nginx-service           servicePort: 80    - host: tomcat.ifun.com      http:       - path: /         backend:           serviceName: tomcat-service           servicePort: 8080

#创建 kubectl create -f ingress-http.yaml   #查看ingress信息 kubectl get ing ingress-http -n dev kubectl describe ing ingress-http -n dev   #查看service信息对应端口信息 kubectl get svc -n ingress-nginx

修改hosts文件

masterIp nginx.ifun.com masterIp tomcat.ifun.com

生成证书

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj /C=CN/ST=BJ/L=BJ/O=nginx/CN=ifun.com

创建秘钥

kubectl create secret tls tls-secret --key tls.key --cert tls.crt

创建ingress-https.yaml

apiVersion: extensions/v1beta1   kind: Ingress metadata:              name: ingress-http   namespace:  dev spec:     tls:     - hosts:       - nginx.ifun.com       - tomcat.ifun.com       secretName: tls-secret # 指定秘钥   rules:    - host: nginx.ifun.com      http:       - path: /         backend:           serviceName: nginx-service           servicePort: 80    - host: tomcat.ifun.com      http:       - path: /         backend:           serviceName: tomcat-service           servicePort: 8080

创建ingress

kubectl create -f ingress-https.yaml

查看端口

kubectl get svc -n ingress-nginx