Service基础应用
[if !supportLists]一.1 [endif]什么是Service？
Service可以简单的理解为逻辑上的一组Pod。一种可以访问Pod的策略，而且其他Pod可以通过这个Service访问到这个Service代理的Pod。相对于Pod而言，它会有一个固定的名称，一旦创建就固定不变。
[if !supportLists]一.1.1.1 [endif]基本概念
Service主要用于Pod之间的通信，对于Pod的IP地址而言，Service是提前定义好并且是不变的资源类型。
Kubernetes Pod具有生命周期的概念，它可以被创建、删除、销毁，一旦被销毁就意味着生命周期的结束。通过ReplicaSet能够动态地创建和销毁Pod，例如进行扩缩容和执行滚动升级。每个Pod都会获取到它自己的IP地址，但是这些IP地址不总是稳定和可依赖的，这样就会导致一个问题：在Kubernetes集群中，如果一组Pod（比如后端的Pod）为其他Pod（比如前端的Pod）提供服务，那么如果它们之间使用Pod的IP地址进行通信，在Pod重建后，将无法再进行连接。
为了解决上述问题，Kubernetes引用了Service这样一种抽象概念：逻辑上的一组Pod，即一种可以访问Pod的策略——通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector（标签选择器）实现的。
举个例子，有一个用作图片处理的backend（后端），运行了3个副本，这些副本是可互换的，所以frontend（前端）不需要关心它们调用了哪个backend副本，然而组成这一组backend程序的Pod实际上可能会发生变化，即便这样frontend也没有必要知道，而且也不需要跟踪这一组backend的状态，因为Service能够解耦这种关联。
对于Kubernetes集群中的应用，Kubernetes提供了简单的Endpoints API，只要Service中的一组Pod发生变更，应用程序就会被更新。对非Kubernetes集群中的应用，Kubernetes提供了基于VIP的网桥的方式访问Service，再由Service重定向到backend Pod。
[if !supportLists]一.1 [endif]创建一个Service
先用deployment创建2个pod
# cat nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: default
spec:
progressDeadlineSeconds: 600
replicas: 2
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
- image: nginx:1.15.2
imagePullPolicy: IfNotPresent
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
[root@master01 ~]# kubectl create -f nginx-deploy.yaml
[root@master01 ~]# kubectl get pods -l app=nginx
# cat nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-svc
name: nginx-svc
spec:
ports:
- name: http # Service端口的名称
port: 80 # Service自己的端口, servicea --> serviceb http://serviceb, http://serviceb:8080
protocol: TCP # UDP TCP SCTP default: TCP
targetPort: 80 #后端应用的端口
- name: https
port: 443
protocol: TCP
targetPort: 443
selector:
app: nginx
sessionAffinity: None
type: ClusterIP
[root@master01 ~]# kubectl create -f nginx-svc.yaml
service/nginx-svc created
访问svc测试，可以访问到后端的pod
[root@master01 ~]# curl http://10.20.65.127#但是不建议使用ip，因为svc再删除之后ip会变
进入busybox容器之后，用svc名称访问
[root@master01 ~]# kubectl exec -it busybox -- sh
/ # wget http://nginx-svc
Connecting to nginx-svc (10.20.65.127:80)
index.html 100% |*****************************| 612 0:00:00 ETA
/ # cat index.html
单独删除pod之后，并不影响svc的访问，因为pod所有的ip地址和端口号都会被记录到endpoint,endpoint在创建svc时自动创建，endpoint会动态的将svc跟pod结合起来
定义Service
一个Service在Kubernetes中是一个REST对象，和Pod类似。像所有REST对象一样，Service的定义可以基于POST方式，请求APIServer创建新的实例。例如，假定有一组Pod，它们暴露了9376端口，同时具有app=MyApp标签。此时可以定义Service如下：
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
上述配置创建一个名为my-service的Service对象，它会将请求代理到TCP端口为9376并且具有标签app=MyApp的Pod上。这个Service会被分配一个IP地址，通常称为ClusterIP，它会被服务的代理使用。
需要注意的是，Service能够将一个接收端口映射到任意的targetPort。默认情况下，targetPort将被设置为与Port字段相同的值。targetPort可以设置为一个字符串，引用backend Pod的一个端口的名称。
定义没有Selector的Service
Service抽象了该如何访问Kubernetes Pod，但也能够抽象其他类型的backend，例如：
[if !supportLists]l [endif]希望在生产环境中访问外部的数据库集群。
[if !supportLists]l [endif]希望Service指向另一个NameSpace中或其他集群中的服务。
[if !supportLists]l [endif]正在将工作负载转移到Kubernetes集群，和运行在Kubernetes集群之外的backend。
在任何这些场景中，都能定义没有Selector的Service：
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
由于这个Service没有Selector，就不会创建相关的Endpoints对象，可以手动将Service映射到指定的Endpoints：
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
subsets:
- addresses:
- ip: 1.2.3.4
ports:
- port: 9376
Endpoint IP地址不能是 loopback（127.0.0.0/8）、link-local（169.254.0.0/16）或者link-local
访问没有Selector的Service与有Selector的Service的原理相同。请求将被路由到用户定义的Endpoint，该示例为1.2.3.4:9376。
ExternalName Service是Service的特例，它没有Selector，也没有定义任何端口和Endpoint，它通过返回该外部服务的别名来提供服务。
比如当查询主机my-service.prod.svc时，集群的DNS服务将返回一个值为my.database.example.com的CNAME记录：
kind: Service
apiVersion: v1
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
同一namespace下，直接访问http://nginx-svc就可以访问，不同namespace下访问Pod可以通过http://nginx-svc.namespace(名称)就可以访问
[if !supportLists]一.1 [endif]使用Service代理k8s外部应用
使用场景：
[if !supportLists]Ø [endif]希望在生产环境中使用某个固定的名称而非IP地址进行访问外部的中间件服务
[if !supportLists]Ø [endif]希望Service指向另一个Namespace中或其他集群中的服务
[if !supportLists]Ø [endif]某个项目正在迁移至k8s集群，但是一部分服务仍然在集群外部，此时可以使用service代理至k8s集群外部的服务
# cat nginx-svc-external.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-svc-external
name: nginx-svc-external
spec:
ports:
- name: http # Service端口的名称
port: 80 # Service自己的端口, servicea --> serviceb http://serviceb, http://serviceb:8080
protocol: TCP # UDP TCP SCTP default: TCP
targetPort: 80 #后端应用的端口
sessionAffinity: None
type: ClusterIP
[root@master01 ~]# kubectl create -f nginx-svc-external.yaml
service/nginx-svc-external created
查看是否有同名的endpoint
创建没有selector的svc是不会创建同名的endpoint
# cat nginx-ep-external.yaml
apiVersion: v1
kind: Endpoints
metadata:
labels:
app: nginx-svc-external
name: nginx-svc-external#ep名称要和svc的名称一致
namespace: default
subsets:
- addresses:
- ip: 182.61.200.6 #代理外部服务的ip地址，此处可以填写百度的IP地址
ports:
- name: http#端口名称要和svc的名称一致
port: 80#代理外部服务的端口号
protocol: TCP
[root@master01 ~]# kubectl create -f nginx-ep-external.yaml
endpoints/nginx-svc-external created
测试访问百度
访问svc测试
要代理至其它服务，可直接修改ep的ip地址
[if !supportLists]一.1 [endif]使用Service反代域名
无需endpoint,service中也无需selector
# cat nginx-externalName.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-externalname
name: nginx-externalname
spec:
type: ExternalName
externalName: www.baidu.com
[root@master01 ~]# kubectl apply -f nginx-externalName.yaml
service/nginx-externalname created
[if !supportLists]一.1 [endif]Service类型
[if !supportLists]Ø [endif]ClusterIP：在集群内部使用，也是默认值。
[if !supportLists]Ø [endif]ExternalName：通过返回定义的CNAME别名。
[if !supportLists]Ø [endif]NodePort：在所有安装了kube-proxy的节点上打开一个端口，此端口可以代理至后端Pod，然后集群外部可以使用节点的IP地址和NodePort的端口号访问到集群Pod的服务。NodePort端口范围默认是30000-32767。
[if !supportLists]Ø [endif]LoadBalancer：使用云提供商的负载均衡器公开服务。
将svc的类型由ClusterIP修改为NodePort
[root@master01 ~]# kubectl edit svc nginx-svc
访问任何一台宿主机的31000端口
