Service 简介
K8s 中提供微服务的实体是 Pod，Pod 在创建时 docker engine 会为 pod 分配 ip，“外部”流量通过访问该 ip 获取微服务。但是，Pod 的状态是不稳定的，它容易被销毁，重建，一旦重建， Pod 的 ip 将改变，那么继续访问原来 ip 是不现实的。针对这个问题 K8s 引入 services 这一 kind，它提供类似负载均衡的作用。与 Pod 不同 service 在创建时 K8s 会为其分配一固定 ip，叫做 ClusterIP。外部流量访问 ClusterIP 即可实现对 Pods 的访问。
进一步的，通过以下示意图说明 service 的工作原理：
如图所示，service 定义了微服务的入口地址，它通过标签选择器匹配到需要转发流量的 pod，将外部来的流量这里是 frontend pod 来的流量引入到 Pod 中。
创建 service
根据上节分析，这里我们通过配置 yaml 文件来创建 service，首先创建 service 需要“引流”的 Pods：
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 就介绍到这里，想继续深入了解，推荐看这篇博文。