Service

Kubernetes的Pods是有生命周期的。他们可以被创建，而且销毁不会再启动。如果使用Deployment来运行应用程序，则它可以动态创建和销毁 Pod。

一个Kubernetes的Service是一种抽象，它定义了一组Pods的逻辑集合和一个用于访问它们的策略 - 有的时候被称之为微服务。一个Service的目标Pod集合通常是由Label Selector 来决定的。

举个例子，想象一个处理图片的后端运行了三个副本。这些副本都是可以替代的 - 前端不关心它们使用的是哪一个后端。尽管实际组成后端集合的Pod可能会变化，前端的客户端却不需要知道这个变化，也不需要自己有一个列表来记录这些后端服务。Service抽象能达到这种解耦。

不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。相反，使用 iptables（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的Endpoint。环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。

kube-proxy支持三种代理模式: 用户空间，iptables和IPVS

• Userspace代理模式

  Client Pod要访问Server Pod时,它先将请求发给本机内核空间中的service规则，由它再将请求,转给监听在指定套接字上的kube-proxy，kube-proxy处理完请求，并分发请求到指定Server Pod后,再将请求递交给内核空间中的service,由service将请求转给指定的Server Pod。由于其需要来回在用户空间和内核空间交互通信，因此效率很差 。

  当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 Service代理 的端口。Service代理 选择一个 backend，并将客户端的流量代理到 backend 上。

  这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。客户端可以简单地连接到一个 IP 和端口，而不需要知道实际访问了哪些 Pod。

• iptables代理模式

  当一个客户端连接到一个 VIP，iptables 规则开始起作用。一个 backend 会被选择（或者根据会话亲和性，或者随机），数据包被重定向到这个 backend。不像 userspace 代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行，并且客户端 IP 是不可更改的。当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程，但是在那些案例中客户端 IP 是可以更改的。

• IPVS代理模式

  在大规模集群（例如10,000个服务）中，iptables 操作会显着降低速度。IPVS 专为负载平衡而设计，并基于内核内哈希表。因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。

  在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

  在 Kubernetes v1.0 版本，代理完全在userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是iptables 代理。 在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理在 Kubernetes 1.14 版本开始默认使用 ipvs 代理。在 Kubernetes v1.0 版本， Service 是 “4层”（TCP/UDP over IP）概念。 在Kubernetes v1.1 版本，新增了Ingress API（beta 版），用来表示 “7层”（HTTP）服务 。这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项。

Service 在 K8s 中有以下四种类型：

• ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP
• NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 NodePort 来访问该服务
• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到NodePort。是付费服务，而且价格不菲
• ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的kube-dns 才支持

ClusterIP

docker pull tomcat:9.0.20-jre8-alpine

clusteripdemo.yml

apiVersion: apps/v1
kind: Deployment
metadata:
name: clusteripdemo
labels:
 app: clusteripdemo
spec:
replicas: 3
template:
 metadata:
  name: clusteripdemo
  labels:
  	app: clusteripdemo
 spec:
  containers:
   - name: clusteripdemo
    image: tomcat:9.0.20-jre8-alpine
    imagePullPolicy: IfNotPresent
    ports:
     - containerPort: 8080
  restartPolicy: Always
selector:
 matchLabels:
  app: clusteripdemo
---
apiVersion: v1
kind: Service
metadata:
name: clusterip-svc
spec:
selector:
 app: clusteripdemo
ports:
 - port: 8080
  targetPort: 8080
type: ClusterIP

运行服务
kubectl apply -f clusteripdemo.yml

查看服务
kubectl get svc

访问服务
curl 10.1.15.24:8080

删除服务
kubectl delete -f clusteripdemo.yml

NodePort

docker pull tomcat:9.0.20-jre8-alpine 

nodeportdemo.yml

apiVersion: apps/v1
kind: Deployment
metadata:
name: clusteripdemo
labels:
 app: clusteripdemo
spec:
replicas: 3
template:
 metadata:
  name: clusteripdemo
  labels:
   app: clusteripdemo
 spec:
  containers:
   - name: clusteripdemo
    image: tomcat:9.0.20-jre8-alpine
    imagePullPolicy: IfNotPresent
    ports:
     - containerPort: 8080
  restartPolicy: Always
selector:
 matchLabels:
  app: clusteripdemo
---
apiVersion: v1
kind: Service
metadata:
name: clusterip-svc
spec:
selector:
 app: clusteripdemo
ports:
 - port: 8080
  targetPort: 8080
  nodePort: 30088
type: NodePort

运行服务
kubectl apply -f nodeportdemo.yml

查看服务
kubectl get svc

访问服务
curl 10.1.61.126:8080

浏览器访问服务
http://192.168.198.156:30088

删除服务
kubectl delete -f nodeportdemo.yml