再战 k8s（14）：service 简介及无头 service

Posted 2022-03-12 看，未来

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了再战 k8s（14）：service 简介及无头 service相关的知识，希望对你有一定的参考价值。

文章目录

Headless Service 和Service
- - 有头service
  - 无头service

1.service简介

我们不应该期望 Kubernetes Pod 是健壮的，而是要假设 Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。

每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址。这样就产生了一个问题：

如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？

Kubernetes 给出的解决方案是 Service。

2.创建 Service

Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 label 来挑选。Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。

来看个例子，创建下面的这个 Deployment

apiVersion: apps/v1beta1                                                                                    
kind: Deployment                                                                                            
metadata:                                                                                                   
  name: httpd                                                                                               
spec:                                                                                                       
  replicas: 3                                                                                                
  template:                                                                                                 
    metadata:                                                                                               
      labels:                                                                                               
        run: httpd                                                                                          
    spec:                                                                                                   
      containers:                                                                                           
      - name: httpd                                                                                         
        image: httpd                                                                                        
        ports:                                                                                              
        - containerPort: 80

我们启动了三个 Pod，运行 httpd 镜像，label 是 run: httpd，Service 将会用这个 label 来挑选 Pod。

Pod 分配了各自的 IP，这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问。

接下来创建 Service，其配置文件如下：

[root@k8s-master k8s]# cat httpd-service.yml 
apiVersion: v1
kind: Service
metadata:
  name: httpd-service
spec:
  selector:
    run: httpd
  ports:
  - protocal: TCP
    port: 8080
    targetPort: 80

① v1 是 Service 的 apiVersion。

② 指明当前资源的类型为 Service。

③ Service 的名字为 httpd-service。

④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。

⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 协议。

执行 kubectl apply 创建 Service httpd-service。

httpd-service 分配到一个 CLUSTER-IP 10.111.195.121。可以通过该 IP 访问后端的 httpd Pod。

根据前面的端口映射，这里要使用 8080 端口。另外，除了我们创建的 httpd-service，还有一个 Service kubernetes，Cluster 内部通过这个 Service 访问 kubernetes API Server。

通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。Endpoints中的地址正好和前面的创建的3个pod的地址相对应

3.Service-IP的工作原理

Service Cluster IP 是一个虚拟 IP，是由 Kubernetes 节点上的 iptables 规则管理的。

可以通过 iptables-save 命令打印出当前节点的 iptables 规则，因为输出较多，这里只截取与httpd-service Cluster IP 10.111.195.121 相关的信息

这两条规则的含义是：

如果 Cluster 内的 Pod（源地址来自 10.244.0.0/16）要访问 httpd-service，则允许。
其他源地址访问 httpd-service，跳转到规则KUBE-SVC-X2P42VLQEZCHLPKZ。

KUBE-SVC-X2P42VLQEZCHLPKZ 规则如下：

1/3 的概率跳转到规则 KUBE-SEP-XXIX5IS7GC2GUSM2
1/3 的概率（剩下 2/3 的一半）跳转到规则 KUBE-SEP-LXY54WDLWY2BJFLU
1/3 的概率跳转到规则 KUBE-SEP-R7HFCFW5PWEDBIAO

上面的转发规则通过DNAT目标地址转换来实现请求转发

iptables 将访问 Service 的流量转发到后端 Pod，而且使用类似轮询的负载均衡策略。

另外需要补充一点：Cluster 的每一个节点都配置了相同的 iptables 规则，这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service。

每个节点都可以通过统一clusterIP 来访问，而且自动实现了应用之间的负载均衡。

4.通过DNS来访问service

在 Cluster 中，除了可以通过 Cluster IP 访问 Service，Kubernetes 还提供了更为方便的 DNS 访问。

kubeadm 部署时会默认安装 kube-dns 组件。

kube-dns 是一个 DNS 服务器。每当有新的 Service 被创建，kube-dns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过 <SERVICE_NAME>.<NAMESPACE_NAME> 访问 Service。

比如可以用 httpd-service.default 访问 Service httpd-service。

如上所示，我们在一个临时的 busybox Pod 中验证了 DNS 的有效性。另外，由于这个 Pod 与 httpd-service同属于 default namespace，可以省略 default 直接用 httpd-service访问 Service。

如果要访问其他 namespace 中的 Service，就必须带上 namesapce 了。kubectl get namespace 查看已有的 namespace。

在 kube-public 中部署 Service httpd2-service，配置如下：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd2
  namespace: kube-public
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd2
    spec:
      containers:
      - name: httpd2
        image: httpd
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: httpd2-service
  namespace: kube-public
spec:
  selector:
    run: httpd2
  ports:
  - protocol: TCP 
    port: 8080
    targetPort: 80

查看 kube-public 的 Service：

5.外网访问Service

除了 Cluster 内部可以访问 Service，很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service，默认是 ClusterIP。

ClusterIP
Service 通过 Cluster 内部的 IP 对外提供服务，只有 Cluster 内的节点和 Pod 可访问，这是默认的 Service 类型，前面实验中的 Service 都是 ClusterIP。

NodePort
Service 通过 Cluster 节点的静态端口对外提供服务。Cluster 外部可以通过 <NodeIP>:<NodePort> 访问 Service。

LoadBalancer
Service 利用 cloud provider 特有的 load balancer 对外提供服务，cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

下面我们来实践 NodePort，Service httpd-service 的配置文件修改如下：

添加 type: NodePort，重新创建 httpd-service。

Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP，不同的是：

EXTERNAL-IP 为 nodes，表示可通过 Cluster 每个节点自身的 IP 访问 Service。
PORT(S) 为 8080:31650 ``8080 是 ClusterIP 监听的端口，32312 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口，每个节点都会监听此端口并将请求转发给 Service。

下面测试 NodePort 是否正常工作。

通过三个节点 IP + 31650 端口都能够访问 httpd-servicee。

接下来我们深入探讨一个问题：Kubernetes 是如何将 <NodeIP>:<NodePort> 映射到 Pod 的呢？

与 ClusterIP 一样，也是借助了 iptables。与 ClusterIP 相比，每个节点的 iptables 中都增加了下面两条规则

规则的含义是：访问当前节点 32312 端口的请求会应用规则 KUBE-SVC-X2P42VLQEZCHLPKZ ,内容为：

其作用就是负载均衡到每一个 Pod。

NodePort 默认是的随机选择，不过我们可以用 nodePort 指定某个特定端口

现在配置文件中就有三个 Port 了：
nodePort 是节点上监听的端口。
port 是 ClusterIP 上监听的端口。
targetPort 是 Pod 监听的端口。

最终，Node 和 ClusterIP 在各自端口上接收到的请求都会通过 iptables 转发到 Pod 的 targetPort。

应用新的 nodePort 并验证：

nodePort: 30000 已经生效了。

Headless Service 和Service

定于spec:clusterIP: None还记得Service的Cluster IP是做什么的吗？对，一个Service可能对应多个EndPoint(Pod)，client访问的是Cluster IP，通过iptables规则转到Real Server，从而达到负载均衡的效果（实现原理请见这里）。

有头service

kubectl get service
NAME                      CLUSTER-IP       EXTERNAL-IP       PORT(S)           AGE
nginx-service             10.107.124.218   192.168.128.158   80/TCP,443/TCP    1d

kubectl describe  service nginx-service    
Name:                   nginx-service
Namespace:              default
Labels:                 
Selector:               component=nginx
Type:                   ClusterIP
IP:                     10.107.124.218
External IPs:           192.168.128.158
Port:                   nginx-http      80/TCP
Endpoints:              10.244.2.9:80
Port:                   nginx-https     443/TCP
Endpoints:              10.244.2.9:443

nslookup nginx-service.default.svc.cluster.local  10.96.0.10  #这个ip为k8s dns的ip
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   nginx-service.default.svc.cluster.local
Address: 10.107.124.218

虽然service有2个endpoint，但是dns查询时只会返回service的地址。具体client访问的是哪个Real Server，是由iptables来决定的。

无头service

kubectl get service
NAME                      CLUSTER-IP       EXTERNAL-IP       PORT(S)    AGE
nginx                     None                         80/TCP     1h

kubectl describe  service nginx
Name:                   nginx
Namespace:              default
Labels:                 app=nginx
Selector:               app=nginx
Type:                   ClusterIP
IP:                     None
Port:                   web     80/TCP                 
Endpoints:              10.244.2.17:80,10.244.2.18:80 #通过web获取到pod的ip地址

nslookup nginx.default.svc.cluster.local 10.96.0.10
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   nginx.default.svc.cluster.local
Address: 10.244.2.17
Name:   nginx.default.svc.cluster.local
Address: 10.244.2.18