技术教程 编程教程 一文看懂 Kubernetes 服务发现： Service 正文

一文看懂 Kubernetes 服务发现： Service

2023-06-07,,

Service 简介

 
K8s 中提供微服务的实体是 Pod，Pod 在创建时 docker engine 会为 pod 分配 ip，“外部”流量通过访问该 ip 获取微服务。但是，Pod 的状态是不稳定的，它容易被销毁，重建，一旦重建， Pod 的 ip 将改变，那么继续访问原来 ip 是不现实的。针对这个问题 K8s 引入 services 这一 kind，它提供类似负载均衡的作用。与 Pod 不同 service 在创建时 K8s 会为其分配一固定 ip，叫做 ClusterIP。外部流量访问 ClusterIP 即可实现对 Pods 的访问。
 
进一步的，通过以下示意图说明 service 的工作原理：
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd-deployment
spec:
replicas: 3
selector:
matchLabels:
app: web_server
template:
metadata:
labels:
app: web_server
spec:
containers:
- name: httpd-demo
image: httpd

 
分别介绍上面参数：
apiVersion: 创建资源的 api 版本，这里是 apps/v1。
kind: 创建的资源类型为 Deployment。
metadata.name: 创建的 Deployment 名字。
replicas: 资源 Deployment 包括三个 Pods 副本。
matchLabels: 匹配到对应的 Pod 标签。
labels: 副本 Pod 的标签。
containers: Pod 内的 container，它是实际提供微服务的单元。
 
上面我们创建了三个副本，且标签为 app:web_server，RC(replicationController) 通过 matchLabels 和创建的三个副本关联。
 
继续创建 service：

apiVersion: v1

kind: Service

metadata:

  name: httpd-svc

spec:

  selector:

    app: web_server

  ports:

  - protocol: TCP

    port: 8080

    targetPort: 80

 
创建名为 httpd-svc 的 service，标签选择器将 service 的标签 app:web_server 和对应的 pods 关联。service “对外”(对外实际上还是在集群内)开放的端口为 8080，它将映射到 Pods 中的 80 端口。
 
Deployment，service 创建好后，我们构建了如下的测试场景：

## 创建 Deployment

$ kubectl apply -f deployment-test.yaml

deployment.apps/bootcamp-deployment created

$ kubectl get deployments.apps

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE

bootcamp-deployment   3/3     3            3           2m5s

$ kubectl get replicasets.apps

NAME                            DESIRED   CURRENT   READY   AGE

bootcamp-deployment-f94bcd74c   3         3         3       2m16s

$ kubectl get pods -o wide

NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES

bootcamp-deployment-f94bcd74c-k4mrc   1/1     Running   0          3m17s   172.18.0.5   minikube   <none>           <none>

bootcamp-deployment-f94bcd74c-q2x6c   1/1     Running   0          3m17s   172.18.0.6   minikube   <none>           <none>

bootcamp-deployment-f94bcd74c-wwcqx   1/1     Running   0          3m17s   172.18.0.4   minikube   <none>           <none>

## 创建 Service

$ kubectl get services

NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE

httpd-svc    ClusterIP   10.108.52.85   <none>        8080/TCP   41s

kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP    10m

## frontend pod

$ kubectl run kubernetes-bootcamp --image=docker.io/jocatalin/kubernetes-bootcamp:v1 --port=8080 --labels="app=bootcamp"

deployment.apps/kubernetes-bootcamp created

$ kubectl get pods -o wide

NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES

bootcamp-deployment-f94bcd74c-k4mrc   1/1     Running   0          6m53s   172.18.0.5   minikube   <none>           <none>

bootcamp-deployment-f94bcd74c-q2x6c   1/1     Running   0          6m53s   172.18.0.6   minikube   <none>           <none>

bootcamp-deployment-f94bcd74c-wwcqx   1/1     Running   0          6m53s   172.18.0.4   minikube   <none>           <none>

kubernetes-bootcamp-9966c6d5-qpr9w    1/1     Running   0          14s     172.18.0.7   minikube   <none>           <none>

 
开始访问 Service：

## cluster node 访问

$ curl 172.18.0.5:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1

$ curl 10.108.52.85:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1

$ curl 10.108.52.85:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1

$ curl 10.108.52.85:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-wwcqx | v=1

 
## frontend pod 访问

$ kubectl exec -it kubernetes-bootcamp-9966c6d5-qpr9w /bin/bash

root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 172.18.0.5:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1

root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 10.108.52.85:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1

root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 10.108.52.85:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1

root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 10.108.52.85:8080

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-wwcqx | v=1

 
可以看出，访问 service 即是访问与 service 关联的 pod。这里未指定 service 的负载分发策略，它有两种策略 RoundRobin 和 SessionAffinity。默认策略为 roundRobin 轮询，即轮询将请求转发到后端各个 Pod。service 的 spec.sessionAffinity 字段可修改访问策略，当值为 ClientIP(默认为空) 即表示将同一个客户端的访问请求转发到同一个后端 Pod。
 
集群外部访问 Service
service 是 K8s 中的概念，它分配的 ip 是逻辑的，没有实体的 ip。所以在 K8s 集群外无法访问 service 的 ip，K8s 提供了 NodePort 和 LoadBalancer 两种方式实现集群外访问 Service。这里因实验环境限制只介绍 NodePort 方式。
 
创建类型为 NodePort 的 service：

## 命令行创建 service, 也可通过 yaml 文件创建

$ kubectl expose deployment/bootcamp-deployment --type="NodePort" --port 8080

service/bootcamp-deployment exposed

$ kubectl get service

NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE

bootcamp-deployment   NodePort    10.107.172.165   <none>        8080:32150/TCP   5s

httpd-svc             ClusterIP   10.108.52.85     <none>        8080/TCP         36m

kubernetes            ClusterIP   10.96.0.1        <none>        443/TCP          46m

$ kubectl describe service bootcamp-deployment

Name:                     bootcamp-deployment

Namespace:                default

Labels:                   <none>

Annotations:              <none>

Selector:                 app=web_server

Type:                     NodePort

IP:                       10.107.172.165

Port:                     <unset>  8080/TCP

TargetPort:               8080/TCP

NodePort:                 <unset>  32150/TCP

Endpoints:                172.18.0.4:8080,172.18.0.5:8080,172.18.0.6:8080

Session Affinity:         None

External Traffic Policy:  Cluster

Events:                   <none>

 
可以看出，K8s 将 Service 的 8080 端口和 node 上的 32150 端口关联，并且 node 上的 32150 端口被 (kube-proxy) 监听：

$ netstat -antp | grep 32150

tcp6       0      0 :::32150                :::*                    LISTEN      4651/kube-proxy

$ ps aux | grep 4651 | grep -v grep

root      4651  0.0  1.2 140108 31048 ?        Ssl  07:15   0:01 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=minikube

 
外部访问 NodePort Service 的 ClusterIP + Port，即可访问到对应的 Pod：

$ curl 172.17.0.72:32150

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1

$ curl 172.17.0.72:32150

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1

 
Service 的底层实现
探究 service 的底层实现就不得不提到 K8s 的核心组件 kube-proxy，它是一个位于 kube-system namespace 的 Pod，其核心功能是将到 service 的访问请求转发到后端 Pods：

$ kubectl get pods --namespace=kube-system | grep kube-proxy

kube-proxy-gk8zm                   1/1     Running   0          37s

 
kube-proxy 的工作流程大致为，查询和监听 API server 的 services 和 Endpoints 变化，如果有变化则修改本机的 iptables。
kube-proxy 在 iptables 中自定义了 KUBE-SERVICES, KUBE-NODEPORTS，KUBE-POSTROUTING，KUBE-MARK-MASQ 和 KUBE-MARK-DROP 五个链，其中 KUBE-SERVICES 链用来添加流量路由规则。每个链的作用分别为：
KUBE-SERVICES：操作跳转规则的主要链。
KUBE-NODEPORTS：通过 nodeport 访问的流量经过的链。
KUBE-POSTROUTING：post 路由经过的链。
KUBE-MARK-MASQ：对符合条件的 package set MARK0x4000，有此标记的数据包会在 KUBE-POSTROUTING 链中做 MASQUERADE。
KUBE-MARK-DROP：对未能匹配到跳转规则的package set mark 0x8000，有该标记的包会在 filter 表中被 drop 掉。
 
查看路由表，以类型为 ClusterIP 的 service 为例：

-A KUBE-SERVICES -d 10.108.52.85/32 -p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP

 
链 KUBE-SERVICES 的规则为访问目的地址 10.108.52.85，端口为 8080 的数据包都被转发到规则 KUBE-SVC-RL3JAE4GN7VOGDGP：

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-NGIJJXQTL6LQACUG

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KSASEUT37GIWYDZK

-A KUBE-SVC-RL3JAE4GN7VOGDGP -j KUBE-SEP-TTP6SZ4CLZYRFEZJ

 
规则 RL3JAE4GN7VOGDGP 有三条，三条规则分别是数据包随机 1/3 的概率发到规则 KUBE-SEP-NGIJJXQTL6LQACUG，KSASEUT37GIWYDZK 和 KUBE-SEP-TTP6SZ4CLZYRFEZJ。再看这三条定义的是什么规则：

-A KUBE-SEP-NGIJJXQTL6LQACUG -s 172.18.0.4/32 -j KUBE-MARK-MASQ

-A KUBE-SEP-NGIJJXQTL6LQACUG -p tcp -m tcp -j DNAT --to-destination172.18.0.4:8080

 
三条规则都是类似的，以规则 NGIJJXQTL6LQACUG 为例，其定义了两条规则。第一条，如果发往 ClusterIP 的源 ip 地址是 172.18.0.4 则进入到链 KUBE-MARK-MASQ。第二条，如果是“外部”协议为 tcp 的数据包进入该规则，则做目的 NAT 转换，将目的地址转换为 Pod 的地址 172.18.0.4:8080。
 
继续，查看类型为 NodePort 的 service：

-A KUBE-SERVICES -d 10.107.172.165/32 -p tcp -m comment --comment "default/bootcamp-deployment: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-7BU2JDGBFZPRVB5H

 
路由表中定义，集群外部访问 10.107.172.165 端口为 8080 的地址的流量将跳转到规则 KUBE-SVC-7BU2JDGBFZPRVB5H：

-A KUBE-SVC-7BU2JDGBFZPRVB5H -m statistic --mode random --probability0.33333333349 -j KUBE-SEP-JRC46L5OEHUJ3JOG

-A KUBE-SVC-7BU2JDGBFZPRVB5H -m statistic --mode random --probability0.50000000000 -j KUBE-SEP-RVACF472KUDH2WI5

-A KUBE-SVC-7BU2JDGBFZPRVB5H -j KUBE-SEP-NHLSGKWGDK2BACCW

 
类似的，规则 KUBE-SVC-7BU2JDGBFZPRVB5H 分别是数据包随机 1/3 的概率发到规则 KUBE-SEP-JRC46L5OEHUJ3JOG，KUBE-SEP-RVACF472KUDH2WI5 和 KUBE-SEP-NHLSGKWGDK2BACCW。查看规则 KUBE-SEP-JRC46L5OEHUJ3JOG 定义：

-A KUBE-SEP-JRC46L5OEHUJ3JOG -s 172.18.0.4/32 -j KUBE-MARK-MASQ

-A KUBE-SEP-JRC46L5OEHUJ3JOG -p tcp -m tcp -j DNAT --to-destination 172.18.0.4:8080

 
它有两条规则，重点是第二条，当外部协议为 tcp 的数据包到达该规则，则做目的 NAT 将数据包直接发到目的地址 172.18.0.4:8080。
 
service 与 Endpoints
细心的读者会发现在 service 的 describe 内容中有个 Endpoints 参数，它描述的是 service 所映射的后端 pod 的地址，如下所示：

$ kubectl describe service httpd-svc

Name:              httpd-svc

Namespace:         default

Labels:            <none>

Annotations:       kubectl.kubernetes.io/last-applied-configuration:

                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"httpd-svc","namespace":"default"},"spec":{"ports":[{"port":8080,"...

Selector:          app=web_server

Type:              ClusterIP

IP:                10.108.52.85

Port:              <unset>  8080/TCP

TargetPort:        8080/TCP

Endpoints:         172.18.0.4:8080,172.18.0.5:8080,172.18.0.6:8080

Session Affinity:  None

Events:            <none>

 
selector 在匹配到对应的后端 pod 后，service 会更新 Endpoints 为后端 pod 的地址。这里我们可以构造这样一种场景，service 不通过 selector 选择后端 pod，而是直接将它与 Endpoints 做关联：
 
创建 Endpoints:

apiVersion: v1

kind: Endpoints

metadata:

  name: httpd-svc-endpoints

subsets:

  - addresses:

    - ip: 1.2.3.4

    ports:

    - port: 80

 
创建 service：

apiVersion: v1

kind: Service

metadata:

  name: httpd-svc-endpoints

spec:

  ports:

  - protocol: TCP

    port: 8080

    targetPort: 80

[centos@k8s-master-node-1 hxia]$ kubectl describe services httpd-svc-endpoints

Name:              httpd-svc-endpoints

Namespace:         default

Labels:            <none>

Annotations:       <none>

Selector:          <none>

Type:              ClusterIP

IP:                10.102.65.186

Port:              <unset>  8080/TCP

TargetPort:        80/TCP

Endpoints:         1.2.3.4:80

Session Affinity:  None

Events:            <none>

 
创建完毕，可以看到 service 的 Endpoints 更新为提前创建好的 Endpoints，且 selector 为 none。相应的，kube-proxy 会在路由表中建立 service 到 Endpoints 的规则。
 
除了不指定 selector，创建 service 时也可以不指定 ClusterIP (ClusterIP: None)，不指定 ClusterIP 的 service 称为 Headless service，使用该 service 即是去中心化，外部流量直接获取到后端 pod 的 Endpoints，然后自行选择该访问哪个 pod。
 
service 与 DNS
除了直接访问 service ClusterIP 访问后端 pod 外，还可以通过 service 名，对于 NodePort 类型的 service 也可通过集群 node 名访问 pod。K8s 中实现名称解析和 ip 对应的核心组件是 coredns： 

$ curl minikube:32150

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1

$ curl minikube:32150

Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-wwcqx | v=1

$ kubectl get pods --namespace=kube-system -o wide | grep dns

coredns-6955765f44-rb828           1/1     Running   0          24m  172.18.0.3    minikube   <none>           <none>

coredns-6955765f44-rm4pv           1/1     Running   0          24m  172.18.0.2    minikube   <none>           <none>

 
集群内部访问 pod 的流量路径大致为流量访问 service，通过 coredns 解析该 service 对应的 ClusterIP，继续访问 ClusterIP，当请求到达宿主机网络后 kube-proxy 会对请求做拦截，根据路由表规则将请求转发到后端 pod 实现服务发现和流量转发。集群外部访问 pod 的流量路径大致类似。
 
 
 
关于 Kubernetes 服务发现 service 就介绍到这里，想继续深入了解，推荐看这篇博文。

 

一文看懂 Kubernetes 服务发现： Service的相关教程结束。

《一文看懂 Kubernetes 服务发现： Service.doc》

下载本文的Word格式文档，以方便收藏与打印。

Copyright 2023. 昆居客 - IT编程,互联网信息技术文档大全!