K8s-----（六）Service的类型

1 Service的介绍

Kubernetes Pod是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 通过ReplicationController能够动态地创建和销毁Pod， 每个 Pod 都会获取它自己的 IP 地址，可一旦销毁后，重新创建后，IP地址会产生改变。 这会导致一个问题：在 Kubernetes 集群中，如果一组 Pod(称为 backend)为其它 Pod (称为 frontend)提供服务，一旦backend的Pod重新创建，那么frontend的Pod该如何发现，并连接到这组 Pod 中的哪些 backend 呢?

1.1 为什么要使用Service

Service资源用于为pod对象提供一个固定、统一的访问接口及负载均衡的能力，并借助新一代DNS系统的服务发现功能，解决客户端发现并访问容器化应用的问题。

在kubernetes中，在收到rc调控的时候，pod副本数是变化的，对应的虚IP也是变化的，比如发生迁移或者伸缩时。这对于pod的访问来说是不能接受的，kubernetes中的service是一种逻辑概念。它定义了一个pod逻辑集合以及访问它们的策略，service与pod的关联同样是通过label完成的。service的目标是提供一种桥梁，他会为访问者提供一个固定的访问IP地址，用于在访问时重定向到相应的后端，这可以使一些非kubernetes原生应用程序，在无需为kubernetes编写特定代码的前提下轻松访问后端。

注意： service只是在k8s集群内部起作用，集群外部访问是无效的

• Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。
• Service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）

2 service的类型

• ClusterIP：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。一个Service可能对应多个EndPoint(Pod)，client访问的是Cluster IP，通过iptables规则转到Real Server，从而达到负载均衡的效果
• NodePort：将Service通过指定的Node上的端口暴露给外部，访问任意一个
• NodeIP：nodePort都将路由到ClusterIP。
• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到<NodeIP>:NodePort，此模式只能在云服务器上使用。
• ExternalName：将服务通过 DNS CNAME记录方式转发到指定的域名（通过 spec.externlName 设定）

2 集群内部访问

Service 是由 kube-proxy 组件，加上 iptables 来共同实现的.

## 创建控制器
kubectl create deployment nginx --image=myapp:v1 --replicas=3 
## 暴露服务的80端口
kubectl expose deployment nginx --port=80 
kubectl get pod ## 查看pod的信息
## 查看nginx服务的信息，类型ClusterIP：k8s系统给service自动分配的虚拟IP，只能在集群内部访问
kubectl describe svc nginx 

• 查看iptables的规则：iptables -t nat -nL |grep 80，iptables 使用NAT等技术将virtualIP的流量转至endpoint中，容器内暴露的端口是80

• kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源

2.1 IPVS模式的service

IPVS模式的service，可以使K8s集群支持更多量级的Pod

pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换

（1）开启kube-proxy的ipvs模式

• 所有节点安装ipvsadm：yum install ipvsadm -y
• 修改IPVS模式：kubectl edit cm kube-proxy -n kube-system

• 更新kube-proxy pod：

kubectl get pod -n kube-system |grep kube-proxy |awk '{system("kubectl delete pod "$1" -n kube-system")}'

• IPVS模式下，kube-proxy会在service创建后，在宿主机上添加一个虚拟网卡：kube-ipvs0，并分配service IP

（3）应用文件：kubectl apply -f demo.yml

---
apiVersion: v1
kind: Service  ## 服务
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
 - protocol: TCP
    port: 80
    targetPort: 80
---
apiVersion: apps/v1
kind: Deployment  ## 控制器创建pod
metadata:
  name: deployment
spec:
  replicas: 5  ## 副本数
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1

• 查看服务的信息：kubectl get svc

• IPVS模式下，kube-proxy会在service创建后，在宿主机上添加一个虚拟网卡：kube-ipvs0，并分配service IP
  查看IP信息：ip addr

• kube-proxy通过IPVS模块,以rr轮询方式调度service中的Pod
  查看当前配置的虚拟服务和各个RS的权重：ipvsadm -ln

（2）扩容：

• 编辑文件：vim demo.yml

• 应用文件：kubectl apply -f demo.yml，扩容成功

• 查看当前配置的虚拟服务和各个RS的权重：ipvsadm -ln
• 查看指定命名空间pod的详细信息：kubectl -n kube-system get pod -o wide

• 查看指定命名空间的服务：kubectl -n kube-system get svc

• 进入容器的交互界面：kubectl attach demo -c demo -it，访问服务时是负载均衡的

2.2 Headless Service

Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

headless使用场景

第一种：自主选择权，client自己来决定使用哪个Real Server，可以通过查询DNS来获取Real Server的信息。

第二种：Headless Service的对应的每一个Endpoints，即每一个Pod，都会有对应的DNS域名；这样Pod之间就能互相访问，集群也能单独访问pod

• 域名格式：$(servicename).$(namespace).svc.cluster.local

（1）应用文件：kubectl apply -f demo.yml ，修改上面实验中的demo.yml中service的类型为None

clusterIP: None表示是无头service
port: 80  service ip中的端口
targetPort: 80 容器ip中的端口

• 查看服务的信息：kubectl get svc

• 查看当前配置的虚拟服务和各个RS的权重：ipvsadm -ln

• 查看IP的信息：ip addr

• 查看服务的详细信息：kubectl describe svc myservice

• 查看指定命名空间的服务：kubectl -n kube-system get svc
• 查看DNS中的A记录：dig -t A myservice.default.svc.cluster.local @10.96.0.10，Real Server的信息

• 查看指定服务的信息：kubectl describe -n kube-system svc kube-dns

（2）测试：在容器中访问myservice服务，是负载均衡的


（3）Pod滚动更新后，依然可以解析：

• 应用文件：kubectl apply -f demo.yml

• 进入容器的交互式模式：kubectl attach demo -c demo -it，依然可以通过服务的名字访问服务后端的pod，实现负载均衡

3 集群外部访问Service

3.1 NodePort方式

Kubernetes 的控制器能保证在任意副本（Pod）挂掉时自动从其他机器启动一个新的，还可以动态扩容等，通俗地说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了。

这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上

（1）应用文件：kubectl apply -f demo.yml

• 将服务的类型设定为NodePort 模式

• 查看服务的信息：kubectl get svc，服务的80端口绑定到本机的31010端口

• 查看当前配置的虚拟服务和各个RS的权重：ipvsadm -Ln，轮询的方式

• 查看IP地址：ip addr

• 查看31010端口的服务：netstat -antlp| grep 31010，将服务绑定到本地的31010端口

（2）测试：curl 172.25.12.2:31010/hostname.html，实现负载均衡

3.2 ExternalName

从外部访问 Service 的第二种方式

（1）应用文件：kubectl apply -f demo.yml

• 查看服务的信息：kubectl get svc，服务的80端口绑定到本地的31199端口，外部访问的IP状态为prending

• 查看当前配置的虚拟服务和各个RS的权重：ipvsadm -Ln，轮询的方式

• 查看myservice服务的详细信息：kubectl describe svc myservice

（2）service允许为其分配一个公有IP

• 重新应用文件：kubectl apply -f demo.yml

• 查看服务的信息：kubectl get svc，服务中被分配到外部访问的VIP

（3）测试：curl 172.25.12.100/hostname.html，能通过外部IP访问，并且实现负载均衡

4 从内部访问外部

（1）应用文件：kubectl apply -f demo.yml

• Service 定义将ey-service 服务映射到 www.baidu.com

apiVersion: v1
kind: Service
metadata:
  name: ex-service
spec:
  type:  ExternalName
 clusterIP:Name: www.baidu.com

• 查看服务信息：kubectl get svc，ex-service服务的EXTERNAL-IP=www.baidu.com

（2）查看DNS中的A记录：dig -t A ex-service.default.svc.cluster.local @10.96.0.10

当查找主机 ex-service.default.svc.cluster.local 时，群集DNS服务返回 CNAME 记录，其值为www.baidu.com 。 访问 ex-service 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发