Kubernetes基础：Service
本文的试验环境为CentOS 7.3，Kubernetes集群为1.11.2，安装步骤参见kubeadm安装kubernetes V1.11.1 集群
Service 介绍
我们通过Pod、Deployment等可以将应用发布到Kubernetes平台中，但是如果我们如何才能访问我们部署的应用呢？有一个办法就是通过节点的IP加上节点的端口来访问这个节点上的容器应用，但是如果我们有多个跨节点的相通应用时该怎么办呢？特别是应用发生扩容、缩容时应该如何处理，这时我们就需要利用Service来实现。
在Kubernetes中，Service是一种资源，提供了我们访问单个或多个容器应用的能力。每个服务在其生命周期内，都拥有一个固定的IP地址和端口。每个服务对应了后台的一个或多个Pod，通过这种方式，客户端就不需要关心Pod所在的位置，方便后端进行方便的Pod扩容、缩容等操作。
可以通过下面的示意图来理解Service的作用。
由此可知，服务可以被外部的客户访问，也可以被内部的客户访问。Service通过创建时指定的标签选择器来决定用户的请求转发到后台的哪些Pods中。看一下Service创建的具体例子。
apiVersion: v1
kind: Service
metadata:
name: tomcat-svc
spec:
sessionAffinity: ClientIP # 该参数可以设置相同IP的请求总是定位到同一个Pod
ports:
- port: 8080
targetPort: 8080
selector:
app: tomcat这个例子定义了一个Service名为tomcat-svc，端口为8080，该服务会将用户的请求转发到后台带有app=tomcat标签的Pods上。
kubectl get svc 我们在测试服务是否正常的时候，不能使用ping命令。因为Kubernetes中实现服务时，并不支持ping。因此不能使用ping的方式检查服务是否正常，应当使用telnet或者nc等命令进行测试。 Pod中的应用访问Service有两种方式，一种是通过向Pod中注入环境变量的方式，这种方式缺点很明显，必须首先创建Service，Pod内的应用才能通过环境变量访问；另一种方式是通过DNS的方式，这种方式非常灵活。
Service 与 endpints
Endpoints 是组成Service的一组IP地址和端口资源。
kubectl get endpoints kubia默认情况下创建Service的时候，会创建一个同名的Endpoints资源，通过kubectl descirbe svc svc-name可以看到这个服务对应的Endpoints。
如果创建Service的时候，不指定Pod的选择器，则不会创建Endpoints资源。也可以手工创建Endpoints类型。创建时需要注意名称要与Service的名称一致。
apiVersion: v1
kind: Endpoints
metadata:
name: external-service
subsets:
- addresses:
- ip: 11.11.11.11
- ip: 22.22.22.22
ports:
- port: 80Service 的类型
- NodePort
- Loadbalance
- Ingress
实例解析
1. 创建内部服务
创建用于内部访问的服务很简单，创建后服务将在生命周期内拥有固定的IP和端口。
apiVersion: v1
kind: Service
metadata:
name: tomcat-svc
spec:
sessionAffinity: ClientIP # 该参数可以设置相同IP的请求总是定位到同一个Pod
ports:
- port: 8080
targetPort: 8080
selector:
app: tomcat客户每次链接Service时，都会对应到后端的一个Pod上，如果客户需要链接所有的后端Pod呢，可以使用headless service。通过这种方式，Kubernetes内部的DNS服务会将Service对应的所有IP返回。
apiVersion: v1
kind: Service
metadata:
name: tomcat-headless
spec:
clusterIP: None
ports:
- port: 8080
targetPort: 8080
selector:
app: tomcat或者可以在客户端通过程序调用Kubernetes API的方式获取地址列表。
2. 为外部服务创建一个内部别名
容器内部的应用要访问外部应用时，可以直接在容器内访问外部服务地址，也可以通过创建一个外部服务的别名进行转发，这样相当于将内外部调用关系解耦了，每次外部发生变化的时候，可以不用修改应用的代码。
apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
type: ExternalName
externalName: api.baidu.com
ports:
- port: 803. 向外部暴露内部服务
向外部暴露内部服务有三种方式：
- NodePort
- LoadBalancer
- Ingress，7层负载均衡
3.1 NodePort 方式
创建这种方式的Service，内部可以通过ClusterIP进行访问，外部用户可以通过NodeIP:NodePort的方式单独访问每个Node上的实例。这种方式有很多问题，直接访问节点的地址和端口需要在客户端记录很多信息，Pod发生迁移后这些信息没办法动态更新，节点的防火墙及节点所在网络区域的防火墙策略配置会比较麻烦。
apiVersion: v1
kind: Service
metadata:
name: nodeport
spec:
type: NodePort
ports:
- port: 80
targetPort: 8080
nodePort: 30123
selector:
app: httpd端口如果忽略，Kubernetes会自动生成。
$ kubectl get svc nodeport获取一些信息
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type="InternalIP")].address}'3.2 load balancer 方式
这种方式一般需要云供应商的支持，或者一些本地资源如F5的支持。这里不做过多介绍了。
3.3 Ingress 方式
LoadBalancer要求的IP资源较多，每个负载均衡服务都需要一个IP，Ingress可以只用一个IP，通过URL来判断需要访问的服务。Ingress工作在HTTP层，配置与使用更加灵活。目前为止还是一个beta特性。
目前有很多Ingress的支持：
- Kubernetes提供的基于GCE、Nginx的Ingress控制器
- F5提供的控制器
- Kong提供的Kong Ingress Controller for Kubernetes
- Traefik提供收费的解决方案
- NGINX提供的NGINX Ingress Controller for Kubernetes
- 基于HAProxy的HAProxy Ingress Controller for Kubernetes
- Istio提供的Control Ingress Traffic
使用过程中的最佳实践：
- 总是添加 Readiness 探测
- 不要在探测中使用关闭的逻辑
参考资料
- Kubernetes in action
- JSONPath Support