7. Kubernetes 进阶之服务（Service）

伟大的大威

已于 2022-10-18 16:42:20 修改

阅读量418

点赞数

于 2022-10-18 14:55:16 首次发布

本文链接：https://blog.csdn.net/u010026928/article/details/127324805

版权

k8s 同时被 3 个专栏收录

14 篇文章 4 订阅

订阅专栏

docker

6 篇文章 1 订阅

订阅专栏

DevOps

5 篇文章 1 订阅

订阅专栏

Service详解

为何需要 Service

Kubernetes 中 Pod 是随时可以消亡的（节点故障、容器内应用程序错误等原因）。如果使用 Deployment 运行您的应用程序，Deployment 将会在 Pod 消亡后再创建一个新的 Pod 以维持所需要的副本数。每一个 Pod 有自己的 IP 地址，然而，对于 Deployment 而言，对应 Pod 集合是动态变化的。

这个现象导致了如下问题：

如果某些 Pod（假设是 ‘backends’）为另外一些 Pod（假设是 ‘frontends’）提供接口，在 ‘backends’ 中的 Pod 集合不断变化（IP 地址也跟着变化）的情况下，‘frontends’ 中的 Pod 如何才能知道应该将请求发送到哪个 IP 地址？

Service 存在的意义，就是为了解决这个问题。

Service介绍

Kubernetes 中 Service 是一个 API 对象，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到指定条件的 Pod 服务。

Service 是 Kubernetes 中的一种服务发现机制：

Pod 有自己的 IP 地址
Service 被赋予一个唯一的 dns name
Service 通过 label selector 选定一组 Pod
Service 实现负载均衡，可将请求均衡分发到选定这一组 Pod 中

例如，假设有一个无状态的图像处理后端程序运行了 3 个 Pod 副本。这些副本是相互可替代的（前端程序调用其中任何一个都可以）。在后端程序的副本集中的 Pod 经常变化（销毁、重建、扩容、缩容等）的情况下，前端程序不应该关注这些变化。

Kubernetes 通过引入 Service 的概念，将前端与后端解耦。

在这里插入图片描述

Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。

在这里插入图片描述

# 当访问service这个入口的时候，可以发现后面有三个pod的服务在等待调用，
# kube-proxy会基于rr（轮询）的策略，将请求分发到其中一个pod上去
# 这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点，访问都可以。
[root@node1 ~]# 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.2.33:80               Masq    1      0          0

proxy mode（代理模式）

版本兼容性如下：

代理模式	Kubernetes 版本	是否默认
User space proxy mode	v1.0 +
Iptables proxy mode	v1.1 +	默认
Ipvs proxy mode	v1.8 +

User space 代理模式

在 user space proxy mode 下：

kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
kube-proxy 在其所在的节点（每个节点都有 kube-proxy）上为每一个 Service 打开一个随机端口
kube-proxy 安装 iptables 规则，将发送到该 Service 的 ClusterIP（虚拟 IP）/ Port 的请求重定向到该随机端口
任何发送到该随机端口的请求将被代理转发到该 Service 的后端 Pod 上（kube-proxy 从 Endpoint 信息中获得可用 Pod）
kube-proxy 在决定将请求转发到后端哪一个 Pod 时，默认使用 round-robin（轮询）算法，并会考虑到 Service 中的 SessionAffinity 的设定

如下图所示：
在这里插入图片描述

Iptables 代理模式默认模式

在 iptables proxy mode 下：

kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
kube-proxy 在其所在的节点（每个节点都有 kube-proxy）上为每一个 Service 安装 iptable 规则
iptables 将发送到 Service 的 ClusterIP / Port 的请求重定向到 Service 的后端 Pod 上
- 对于 Service 中的每一个 Endpoint，kube-proxy 安装一个 iptable 规则
- 默认情况下，kube-proxy 随机选择一个 Service 的后端 Pod

如下图所示：

在这里插入图片描述

iptables proxy mode 的优点：

更低的系统开销：在 linux netfilter 处理请求，无需在 userspace 和 kernel space 之间切换
更稳定

与 user space mode 的差异：

使用 iptables mode 时，如果第一个 Pod 没有响应，则创建连接失败
使用 user space mode 时，如果第一个 Pod 没有响应，kube-proxy 会自动尝试连接另外一个后端 Pod

您可以配置 Pod 就绪检查（readiness probe）确保后端 Pod 正常工作，此时，在 iptables 模式下 kube-proxy 将只使用健康的后端 Pod，从而避免了 kube-proxy 将请求转发到已经存在问题的 Pod 上。

IPVS 代理模式

在 IPVS proxy mode 下：

kube-proxy 监听 kubernetes master 以获得添加和移除 Service / Endpoint 的事件
kube-proxy 根据监听到的事件，调用 netlink 接口，创建 IPVS 规则；并且将 Service/Endpoint 的变化同步到 IPVS 规则中
当访问一个 Service 时，IPVS 将请求重定向到后端 Pod

在这里插入图片描述

IPVS 模式的优点

IPVS proxy mode 基于 netfilter 的 hook 功能，与 iptables 代理模式相似，但是 IPVS 代理模式使用 hash table 作为底层的数据结构，并在 kernel space 运作。这就意味着

IPVS 代理模式可以比 iptables 代理模式有更低的网络延迟，在同步代理规则时，也有更高的效率
与 user space 代理模式 / iptables 代理模式相比，IPVS 模式可以支持更大的网络流量

IPVS 提供更多的负载均衡选项：

rr: round-robin
lc: least connection (最小打开的连接数)
dh: destination hashing
sh: source hashing
sed: shortest expected delay
nq: never queue

TIP

如果要使用 IPVS 模式，您必须在启动 kube-proxy 前为节点的 linux 启用 IPVS
kube-proxy 以 IPVS 模式启动时，如果发现节点的 linux 未启用 IPVS，则退回到 iptables 模式

代理模式总结

在所有的代理模式中，发送到 Service 的 IP:Port 的请求将被转发到一个合适的后端 Pod，而无需调用者知道任何关于 Kubernetes/Service/Pods 的细节。

Service 中额外字段的作用：

```
service.spec.sessionAffinity
```
- 默认值为 “None”
- 如果设定为 “ClientIP”，则同一个客户端的连接将始终被转发到同一个 Pod
```
service.spec.sessionAffinityConfig.clientIP.timeoutSeconds
```
- 默认值为 10800 （3 小时）
- 设定会话保持的持续时间

Service 类型

Service的资源清单文件：

kind: Service  # 资源类型
apiVersion: v1  # 资源版本
metadata: # 元数据
  name: service # 资源名称
  namespace: dev # 命名空间
spec: # 描述
  selector: # 标签选择器，用于确定当前service代理哪些pod
    app: nginx
  type: # Service类型，指定service的访问方式
  clusterIP:  # 虚拟服务的ip地址
  sessionAffinity: # session亲和性，支持ClientIP、None两个选项
  ports: # 端口信息
    - protocol: TCP 
      port: 3017  # k8s集群的端口(k8s集群内部服务之间访问service的入口)
      targetPort: 5003 # pod 容器里面的端口(最终流量的端口,经过kube-prosy流入到后端的pod的targetPort上，最终进入容器。)
      nodePort: 31122 # k8s主机的端口(供给外部流量访问k8s集群中service的入口)

ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
ExternalName：把集群外部的服务引入集群内部，直接使用

Service使用

实验环境准备

在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置app=nginx-pod的标签

创建pc-deployment.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

root@master:~# kubectl apply -f pc-deployment.yaml
deployment.apps/pc-deployment created

# 查看pod详情
root@master:~# kubectl get pods -n dev -o wide --show-labels
NAME                             READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES   LABELS
pc-deployment-66d5c85c96-jhdxb   1/1     Running   0          24s   10.244.1.231   node1    <none>           <none>            app=nginx-pod,pod-template-hash=66d5c85c96
pc-deployment-66d5c85c96-jw6h9   1/1     Running   0          24s   10.244.0.103   master   <none>           <none>            app=nginx-pod,pod-template-hash=66d5c85c96
pc-deployment-66d5c85c96-t88mt   1/1     Running   0          24s   10.244.0.104   master   <none>           <none>            app=nginx-pod,pod-template-hash=66d5c85c96

# 为了方便后面的测试，修改下三台nginx的index.html页面（三台修改的IP地址不一致）
# kubectl exec -it pc-deployment-66d5c85c96-jhdxb -n dev /bin/bash
# root@pc-deployment-66d5c85c96-jhdxb:/# echo "10.244.1.231" > /usr/share/nginx/html/index.html

#修改完毕之后，访问测试
root@master:~# curl 10.244.1.231
10.244.1.231
root@master:~# curl 10.244.0.103
10.224.0.103
root@master:~# curl 10.244.0.104
10.244.0.104

ClusterIP类型的Service

创建service-clusterIP.yaml文件

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

# 创建service
root@master:~# kubectl apply -f service-clusterIP.yaml 
service/service-clusterip created

# 查看service
root@master:~# kubectl get svc -n dev -o wide
NAME                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE   SELECTOR
service-clusterip   ClusterIP   10.97.97.97   <none>        80/TCP    10s   app=nginx-pod

# 查看service的详细信息
# 在这里有一个Endpoints列表，里面就是当前service可以负载到的服务入口
root@master:~# kubectl describe svc service-clusterip -n dev
Name:              service-clusterip
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.97.97.97
IPs:               10.97.97.97
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.103:80,10.244.0.104:80,10.244.1.231:80
Session Affinity:  None
Events:            <none>

# 访问10.97.97.97:80观察效果
root@master:~# curl 10.97.97.97:80
10.244.1.231
root@master:~# curl 10.97.97.97:80
10.224.0.103
root@master:~# curl 10.97.97.97:80
10.244.0.104

Endpoint

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。

一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。

在这里插入图片描述

root@master:~# kubectl get endpoints -n dev -o wide
NAME                ENDPOINTS                                         AGE
service-clusterip   10.244.0.103:80,10.244.0.104:80,10.244.1.231:80   7m30s

负载分发策略

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

如果不定义，默认使用kube-proxy的策略，比如随机、轮询
基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个Pod上

此模式可以使在spec中添加sessionAffinity:ClientIP选项

# 查看ipvs的映射规则【rr 轮询】
[root@k8s-master01 ~]# ipvsadm -Ln
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.2.33:80               Masq    1      0          0

# 循环访问测试
[root@k8s-master01 ~]# while true;do curl 10.97.97.97:80; sleep 5; done;
10.244.1.40
10.244.1.39
10.244.2.33
10.244.1.40
10.244.1.39
10.244.2.33

# 修改分发策略----sessionAffinity:ClientIP

# 查看ipvs规则【persistent 代表持久】
[root@k8s-master01 ~]# ipvsadm -Ln
TCP  10.97.97.97:80 rr persistent 10800
  -> 10.244.1.39:80               Masq    1      0          0
  -> 10.244.1.40:80               Masq    1      0          0
  -> 10.244.2.33:80               Masq    1      0          0

# 循环访问测试
[root@k8s-master01 ~]# while true;do curl 10.97.97.97; sleep 5; done;
10.244.2.33
10.244.2.33
10.244.2.33
  
# 删除service
[root@k8s-master01 ~]# kubectl delete -f service-clusterIP.yaml
service "service-clusterip" deleted

Headless类型的Service

在某些场景中，开发人员可能不想使用Service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了Headless Service，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。

创建service-headless.yaml

apiVersion: v1
kind: Service
metadata:
  name: service-headless
  namespace: dev
spec:
  selector:
    app: nginx-pod
  clusterIP: None # 将clusterIP设置为None，即可创建headless Service
  type: ClusterIP
  ports:
  - port: 80    
    targetPort: 80

# 创建service
root@master:~# kubectl apply -f service-headless.yaml 
service/service-headless created

# 获取service， 发现CLUSTER-IP未分配
root@master:~# kubectl get svc service-headless -n dev -o wide
NAME               TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE   SELECTOR
service-headless   ClusterIP   None         <none>        80/TCP    8s    app=nginx-pod

# 查看service详情
root@master:~# kubectl describe svc service-headless  -n dev
Name:              service-headless
Namespace:         dev
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                None
IPs:               None
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.103:80,10.244.0.104:80,10.244.1.231:80
Session Affinity:  None
Events:            <none>



# 查看域名的解析情况
root@master:~# kubectl exec -it pc-deployment-66d5c85c96-jhdxb -n dev /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# cat /etc/resolv.conf
nameserver 10.96.0.10
search dev.svc.cluster.local svc.cluster.local cluster.local

root@master:~# dig @10.96.0.10 service-headless.dev.svc.cluster.local
......
;; ANSWER SECTION:
service-headless.dev.svc.cluster.local. 30 IN A 10.244.0.103
service-headless.dev.svc.cluster.local. 30 IN A 10.244.0.104
service-headless.dev.svc.cluster.local. 30 IN A 10.244.1.231

使用场景

有状态应用，例如数据库

例如主节点可以对数据库进行读写操作，而其它的两个工作节点只能读，在这里客户端就没必要指定pod服务的集群地址，直接指定数据库Pod ip地址即可，这里需要绑定dns，客户端访问dns，dns会自动返回pod IP地址列表
在这里插入图片描述

总结

无头服务不需要指定集群地址
无头服务适用有状态应用例如数据库
无头服务dns查询会返回pod列表，开发人员可以自定义负载均衡策略
普通Service可以通过负载均衡路由到不同的容器应用

NodePort类型的Service

在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了。

对于 NodePort 类型的 Service，Kubernetes 为其分配一个节点端口（对于同一 Service，在每个节点上的节点端口都相同），该端口的范围在初始化 apiserver 时可通过参数 --service-node-port-range 指定（默认是：30000-32767），参考修改NodePort的范围。节点将该端口上的网络请求转发到对应的 Service 上。可通过 Service 的 .spec.ports[*].nodePort 字段查看该 Service 分配到的节点端口号。

在这里插入图片描述

创建service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: service-nodeport
  namespace: dev
spec:
  selector:
    app: nginx-pod
  type: NodePort # service类型
  ports:
  - port: 80
    nodePort: 30102 # 指定绑定的node的端口(默认的取值范围是：30000-32767), 如果不指定，会默认分配
    targetPort: 80

# 创建service
root@master:~# kubectl apply -f service-nodeport.yaml
service/service-nodeport created

# 查看service
root@master:~# kubectl get svc -n dev -o wide
NAME                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE     SELECTOR
service-nodeport    NodePort    10.105.109.2   <none>        80:30102/TCP   14s     app=nginx-pod

# 接下来可以通过电脑主机的浏览器去访问集群中任意一个nodeip的30102端口，即可访问到pod

LoadBalancer类型的Service

在支持外部负载均衡器的云环境中（例如 GCE、AWS、Azure 等），将 .spec.type 字段设置为 LoadBalancer，Kubernetes 将为该Service 自动创建一个负载均衡器。负载均衡器的创建操作异步完成，您可能要稍等片刻才能真正完成创建，负载均衡器的信息将被回写到 Service 的 .status.loadBalancer 字段。如下所示：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  loadBalancerIP: 78.11.24.19
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
      - ip: 146.148.47.155

发送到外部负载均衡器的网络请求就像被转发到 Kubernetes 中的后端 Pod 上。负载均衡的实现细节由各云服务上确定。

在这里插入图片描述

External Name类型的Service

ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。

在这里插入图片描述

service-externalname.yaml 内容

apiVersion: v1
kind: Service
metadata:
  name: service-externalname
  namespace: dev
spec:
  type: ExternalName # service类型
  externalName: www.baidu.com  #改成ip地址也可以

# 创建service
root@master:~#  kubectl  apply -f service-externalname.yaml
service/service-externalname created

# 域名解析
root@master:~# dig @10.96.0.10 service-externalname.dev.svc.cluster.local
......
;; ANSWER SECTION:
service-externalname.dev.svc.cluster.local. 30 IN CNAME www.baidu.com.
www.baidu.com.          30      IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       30      IN      A       180.97.34.94
www.a.shifen.com.       30      IN      A       180.97.34.96

注意事项

ExternalName 可以接受一个 IPv4 地址型的字符串作为 .spec.externalName 的值，但是这个字符串将被认为是一个由数字组成的 DNS name，而不是一个 IP 地址。
如果要 hardcode 一个 IP 地址，请考虑使用 headless Service

External IP类型的Service

如果有外部 IP 路由到 Kubernetes 集群的一个或多个节点，Kubernetes Service 可以通过这些 externalIPs 进行访问。externalIP 需要由集群管理员在 Kubernetes 之外配置。

在 Service 的定义中， externalIPs 可以和任何类型的 .spec.type 一通使用。在下面的例子中，客户端可通过 80.11.12.10:80 （externalIP:port）访问my-service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

参考：
kuboard Kubernetes 进阶
 Kubernetes详细教程-调整版

伟大的大威

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
7. Kubernetes 进阶之服务（Service）

Kubernetes 中 Service 是一个 API 对象，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到指定条件的 Pod 服务。Pod 有自己的 IP 地址Service 被赋予一个唯一的 dns nameService 通过 label selector 选定一组 PodService 实现负载均衡，可将请求均衡分发到选定这一组 Pod 中。
复制链接

扫一扫