Service的基础应用

一.1 什么是Service？
Service可以简单的理解为逻辑上的一组Pod。一种可以访问Pod的策略，而且其他Pod可以通过这个Service访问到这个Service代理的Pod。相对于Pod而言，它会有一个固定的名称，一旦创建就固定不变。

Service的基础应用
二、 基本概念
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。

三、 创建一个Service
先用deployment创建2个pod

[root@master01 ~]# kubectl create -f nginx-deploy.yaml

[root@master01 ~]# kubectl get pods -l app=nginx


[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如下：

上述配置创建一个名为my-service的Service对象，它会将请求代理到TCP端口为9376并且具有标签app=MyApp的Pod上。这个Service会被分配一个IP地址，通常称为ClusterIP，它会被服务的代理使用。

需要注意的是，Service能够将一个接收端口映射到任意的targetPort。默认情况下，targetPort将被设置为与Port字段相同的值。targetPort可以设置为一个字符串，引用backend Pod的一个端口的名称。

定义没有Selector的Service

Service抽象了该如何访问Kubernetes Pod，但也能够抽象其他类型的backend，例如：

l 希望在生产环境中访问外部的数据库集群。

l 希望Service指向另一个NameSpace中或其他集群中的服务。

l 正在将工作负载转移到Kubernetes集群，和运行在Kubernetes集群之外的backend。

在任何这些场景中，都能定义没有Selector的Service：

由于这个Service没有Selector，就不会创建相关的Endpoints对象，可以手动将Service映射到指定的Endpoints：


访问没有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记录：

externalName: my.database.example.com

同一namespace下，直接访问http://nginx-svc就可以访问，不同namespace下访问Pod可以通过
http://nginx-svc.namespace(名称)就可以访问

1 、使用Service代理k8s外部应用

使用场景：

Ø 希望在生产环境中使用某个固定的名称而非IP地址进行访问外部的中间件服务

Ø 希望Service指向另一个Namespace中或其他集群中的服务

Ø 某个项目正在迁移至k8s集群，但是一部分服务仍然在集群外部，此时可以使用service代理至k8s集群外部的服务

查看是否有同名的endpoint

创建没有selector的svc是不会创建同名的endpoint

[root@master01 ~]# kubectl create -f nginx-ep-external.yaml

endpoints/nginx-svc-external created

测试访问百度

访问svc

要代理至其它服务，可直接修改ep的ip地址

四、 使用Service反代域名
无需endpoint,service中也无需selector

[root@master01 ~]# kubectl apply -f nginx-externalName.yaml

service/nginx-externalname created


五、 Service类型
Ø ClusterIP：在集群内部使用，也是默认值。

Ø ExternalName：通过返回定义的CNAME别名。

Ø NodePort：在所有安装了kube-proxy的节点上打开一个端口，此端口可以代理至后端Pod，然后集群外部可以使用节点的IP地址和NodePort的端口号访问到集群Pod的服务。NodePort端口范围默认是30000-32767。

Ø LoadBalancer：使用云提供商的负载均衡器公开服务。

将svc的类型由ClusterIP修改为NodePort

[root@master01 ~]# kubectl edit svc nginx-svc


访问任何一台宿主机的31000端口