本文将介绍 k8s 中的服务如何相互访问，例如后端服务访问数据库，不同类型的服务间的相互访问。并介绍用于实现这种访问的资源 服务service。
挡在 pod 身前的 service
我们现在已经有了 pod ，那让他们相互访问不可以么？答案是，不可以，因为 pod 是有生命周期的，他可能随时被创建也可能随时被销毁，而 每次新建 pod 就会给其分配一个随机的 ip，并且 k8s 也会自动调控 pod 的数量。这就导致了 pod 之间直接访问是不现实的，如果有一个入口，可以动态绑定那些提供相同服务的 pod，并将其开放在固定端口上，这样访问起来不就方便很多了么？这个入口在 k8s 中被称为service。
service(简称svc)是 k8s 中的一种常用资源。配置起来简单的很，现在我们来自己创建一个svc。首先，svc是不会自己提供服务的，他身后一定要有实质的应用来提供服务 (不一定是pod，后面会提到)。所以我们首先来通过一个rs来创建 pod。如果你对rs不是很了解的话，请参考 如何让你的应用活的更久 - rc 与 rs 。
首先新建kubia-replicaset.yaml文件，并填入如下内容：
apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
name: kubia
spec:
replicas: 3
selector:
matchLabels:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia
ports:
- containerPort: 8080
这个文件将创建 3 个 pod，每个 pod 都包含一个app: kubia的标签，并开放提供服务的8080端口。执行如下命令进行创建：
kubectl create -f kubia-replicaset.yaml
然后kubectl get po就可以看到创建出的三个 pod，接下来我们创建一个svc来提供对这三个 pod 的访问。新建kubia-svc.yaml文件，并填入如下内容：
apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
ports:
- name: http # 请为所有端口指定名称
port: 80 # 对外开放的服务端口
targetPort: 8080 # 后方 pod 的服务端口
selector:
app: kubia
可以看到基本svc的配置非常简单，只定义了两个端口和一个选择器，我们在选择器中注明了app: kubia，意思就是让这个svc去将所有携带app: kubia标签的 pod 纳入自己的后方。其实ports.name字段并不是必填项，但是为了方便维护，请为每个端口指定名称。然后我们使用下面命令创建这个svc：
kubectl create -f
创建好了之后来看一下，执行kubectl get svc kubia，我们就可以看到他的信息了：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubia ClusterIP 10.98.237.175 <none> 80/TCP 127m
可以在CLUSTER-IP列看到这个当前的 ip 地址。也就是说，其他 pod 就可以通过这个 ip 访问到其后面的 pod。接下来我们随便使用一个 pod 访问下这个服务。执行kubectl get po并选择一个顺眼的 pod。然后使用下面的命令进行访问svc，注意修改 pod 名和 svc 的 ip 地址：
kubectl exec kubia-7rt2n -- curl -s 10.98.237.175
这条命令里的--是一个分隔符，之前的部分是属于kubectl的，之后的是属于要在 pod 内部执行的命令的。
然后就可以看到来自svc后方 pod 的响应了：
root@master1:~# kubectl exec kubia-7rt2n -- curl -s 10.98.237.175
You've hit kubia-pxfw7
root@master1:~# kubectl exec kubia-7rt2n -- curl -s 10.98.237.175
You've hit kubia-7rt2n
root@master1:~# kubectl exec kubia-7rt2n -- curl -s 10.98.237.175
You've hit kubia-7rt2n
root@master1:~# kubectl exec kubia-7rt2n -- curl -s 10.98.237.175
You've hit kubia-fxqcc
可以看到，svc同时也实现了负载均衡，合理的将请求平摊到了每一个 pod 上。
service 对 pod 的动态绑定
因为svc是通过我们事先定义好的标签选择器来查找 pod 的，所以 pod 的 ip 地址变动对于svc毫无影响，其实在svc和pod之间还包含了一个资源叫做endpoint，endpoint(简称ep)是一组地址及其端口的合集，如下图，只要一个svc有标签选择器的话，他就会自动创建一个同名的ep来标记出自己的要管理的 pod。
我们可以通过如下命令来查看我们刚才创建的kubia服务的ep：
root@master1:~# kubectl describe svc kubia
Name: kubia
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=kubia
Type: ClusterIP
IP: 10.98.237.175
Port: <unset> 80/TCP
TargetPort: 8080/TCP
Endpoints: 10.244.1.18:8080,10.244.2.14:8080,10.244.3.14:8080
Session Affinity: None
Events: <none>
然后就可以在Endpoints列中找到他包含的地址及端口号，这三个用,分隔的地址正是三个 pod 的地址。你可以使用kubectl get pod -o wide来查看 pod 的地址。你可以执行如下命令来重建所有的kubia pod，然后再来查看ep，会发现其ENDPOINTS也会自动更换成这三个 pod 的值。
kubectl delete po -l app=kubia
root@master1:~# kubectl get endpoints kubia
NAME ENDPOINTS AGE
kubia 10.244.1.18:8080,10.244.2.14:8080,10.244.3.14:8080 169m
发现服务
你可能已经发现了，在上文的测试中，我们使用了curl http://x.x.x.x的方式访问的svc，这样的话如果svc重建导致 ip 地址改变了，那我们岂不是访问不到了？k8s 也想到了这一点，所以提供了通过FQDN(全限定域名)访问服务的方式，你可以在任意一个 pod 上直接使用服务的名称来访问服务：
root@master1:~# k exec kubia-5n2m2 -- curl -s http://kubia
You've hit kubia-bv2k8
这种方式可以访问同一命名空间中的服务，k8s 也支持访问其他命名空间的服务。不过域名要长很多。有兴趣的话可以自行了解。
如果你发现你访问不到服务的话请使用
kubectl delete po -l app=kubia重建 pod。因为 k8s 只会在创建时间晚于服务的 pod 中注入服务域名。你可以在容器中查看/etc/resolv.conf文件来找到对应的解析。顺带一提，这个功能是 k8s 的 dns 服务器
coredns实现的，你可以在命名空间kube-system中找到它，让我们为它鼓掌！
访问集群外部的服务
现在问题又来了，对于一个集群内部的 pod 来说，如果他想访问一个集群外部的服务该怎么办呢？例如一个网站的公共 api，或者是一个云数据库。我们就没办法使用svc+标签选择器的方式来获取这些服务了，因为标签选择器只能监测集群内部的 pod 。而无法放眼外部。那么我们应该怎么做呢？
还记得我们之前介绍过的endpoint资源么，没错。我们可以 自定义一个endpoint资源，用它指定外部服务的 ip 及端口，然后绑定到一个svc上，这样内部的 pod 不就通过完全一样的方式访问外部服务了么？
你可以把这张图拿去和"service 对 pod 的动态绑定"小节中的图做对比，你会发现最根本的service > endpoint > 服务提供者的传递流程是没有变的。ok，现在我们来动手操作一下，首先新建一个什么都不会做的呆萌svc，它只告诉别人自己有一个端口80可以提供访问：
external-service.yaml
apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
ports:
- port: 80
然后通过kubectl create -f external-service.yaml创建它。然后查看一下他的信息：
root@master1: ~# kubectl describe svc external-service
Name: external-service
Namespace: default
Labels: <none>
Annotations: <none>
Selector: <none>
Type: ClusterIP
IP: 10.103.101.18
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: <none>
Session Affinity: None
Events: <none>
因为没有标签选择器，所以它不会自己去创建endpoint，现在我们来手动为它创建一个endpoint，只要是和svc同名，那么他们两个就会自动绑定在一起：
external-endpoint.yaml
apiVersion: v1
kind: Endpoints
metadata:
# 和 svc 相同的名称
name: external-service
subsets:
- addresses:
# 这里指定了外部服务的 ip
- ip: 11.11.11.11
# 可以指定多个
- ip: 22.22.22.22
# 还要指定端口号
ports:
- port: 80
然后使用命令kubectl create -f external-endpoint.yaml创建endpoint，之后再查看svc的详情，你会发现他们已经完成了绑定。
root@master1:~/k8s-yaml# kubectl describe svc external-service
Name: external-service
Namespace: default
Labels: <none>
Annotations: <none>
Selector: <none>
Type: ClusterIP
IP: 10.103.101.18
Port: <unset> 80/TCP
TargetPort: 80/TCP
# 看这里！
Endpoints: 11.11.11.11:80,22.22.22.22:80
Session Affinity: None
Events: <none>
其实还有个更简单的方法，可以 通过在svc里的配置项中指定spec.type为ExternalName，然后在使用spec.externalName字段来指定外部服务的完全限定域名，如下：
apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
# 要先指定 svc 的类型
type: ExternalName
# 再在这里指定外部服务的完全限定域名
externalName: someapi.some.company.com
ports:
- port: 80
这样就可以免于新建一个endpoint来直接实现对外部服务的访问。而且使用方式也完全没有变化。
总结
本篇文章讲解了 k8s 中服务的访问入口资源service以及请求的”终点“endpoint。任何可以提供实际请求处理能力的pod最终都要封装成统一的service才能对外提供服务。而service中的标签选择器则可以一直监测pod的状态，从而实现无论是pod增加还是减少对外部请求者来说都是无感知的。
