欢迎光临
我们一直在努力
当前位置：云搜网 聚合分类 正文

Kubernetes 控制器之 Service 讲解(七)

2024-03-31 分类：聚合分类

一、背景介绍

我们这里准备三台机器，一台master，两台node，采用kubeadm的方式进行安装的，安装过程大家可以参照我之前的博文。

IP 角色 版本
192.168.1.200 master kubeadm v1.13.0
192.168.1.201 node01 kubeadm v1.13.0
192.168.1.202 node02 kubeadm v1.13.0

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

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

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

Kubernetes 给出的解决方案是 Service。

二、创建 Service

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

1、创建 Deployment

创建文件mytest-deploy.yaml文件，增加如下内容：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mytest
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: mytest
    spec:
      containers:
      - name: mytest
        image: wangzan18/mytest:v1
        ports:
        - containerPort: 80

创建我们的 Pod。

[root@master ~]# kubectl apply -f mytest-deploy.yaml 
deployment.extensions/mytest created
[root@master ~]# 
[root@master ~]# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
mytest-88d46bf99-cd4zk   1/1     Running   0          70s   10.244.2.2   node02   <none>           <none>
mytest-88d46bf99-fsmcj   1/1     Running   0          70s   10.244.1.3   node01   <none>           <none>
mytest-88d46bf99-ntd5n   1/1     Running   0          70s   10.244.1.2   node01   <none>           <none>

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

2、创建 Service

创建文件mytest-svc.yaml，新增如下内容：

apiVersion: v1
kind: Service
metadata:
  name: mytest-svc
spec:
  selector:
    run: mytest
  ports:
  - port: 80
    targetPort: 8080

创建service。

[root@master ~]# kubectl apply -f mytest-svc.yaml 
service/mytest-svc created
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   33m
mytest-svc   ClusterIP   10.100.77.149   <none>        80/TCP    8s

mytest-svc 分配到一个 CLUSTER-IP 10.100.77.149。可以通过该 IP 访问后端的 mytest Pod。

[root@master ~]# curl 10.100.77.149
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-ntd5n | v=1

通过 kubectl describe 可以查看 mytest-svc 与 Pod 的对应关系。

[root@master ~]# kubectl describe svc mytest-svc
Name:              mytest-svc
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"mytest-svc","namespace":"default"},"spec":{"ports":[{"port":80,"t...
Selector:          run=mytest
Type:              ClusterIP
IP:                10.100.77.149
Port:              <unset>  80/TCP
TargetPort:        8080/TCP
Endpoints:         10.244.1.2:8080,10.244.1.3:8080,10.244.2.2:8080
Session Affinity:  None
Events:            <none>

Endpoints 罗列了三个 Pod 的 IP 和端口。我们知道 Pod 的 IP 是在容器中配置的，那么 Service 的 Cluster IP 又是配置在哪里的呢？CLUSTER-IP 又是如何映射到 Pod IP 的呢？

三、Cluster IP 底层实现

1、开启 iptables

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

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

[root@master ~]# iptables-save |grep 10.100.77.149
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.100.77.149/32 -p tcp -m comment --comment "default/mytest-svc: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.100.77.149/32 -p tcp -m comment --comment "default/mytest-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-XKNZ3BN47GCYFIPJ

这两条规则的含义是：

  1. 如果 Cluster 内的 Pod（源地址来自 10.244.0.0/16）要访问 mytest-svc，则允许。
  2. 其他源地址访问 mytest-svc，跳转到规则 KUBE-SVC-XKNZ3BN47GCYFIPJ。

那我们查看一下KUBE-SVC-XKNZ3BN47GCYFIPJ规则是什么，内容如下：

-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-6VUP2B3YLPPLYJJV
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ENVKJLELDEHDNVGK
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -j KUBE-SEP-IZPSUB6K7QCCEPS3
  1. 1/3 的概率跳转到规则 KUBE-SEP-6VUP2B3YLPPLYJJV。
  2. 1/3 的概率（剩下 2/3 的一半）跳转到规则 KUBE-SEP-ENVKJLELDEHDNVGK。
  3. 1/3 的概率跳转到规则 KUBE-SEP-IZPSUB6K7QCCEPS3。

上面的三条规则内容分别如下：
转发到Pod 10.244.1.2。

-A KUBE-SEP-6VUP2B3YLPPLYJJV -s 10.244.1.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-6VUP2B3YLPPLYJJV -p tcp -m tcp -j DNAT --to-destination 10.244.1.2:8080

转发到Pod 10.244.1.3。

-A KUBE-SEP-ENVKJLELDEHDNVGK -s 10.244.1.3/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-ENVKJLELDEHDNVGK -p tcp -m tcp -j DNAT --to-destination 10.244.1.3:8080

转发到Pod 10.244.2.2。

-A KUBE-SEP-IZPSUB6K7QCCEPS3 -s 10.244.2.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-IZPSUB6K7QCCEPS3 -p tcp -m tcp -j DNAT --to-destination 10.244.2.2:8080

可以看到讲请求分别转发到了后端的三个 Pod。由此我们可以看出 iptables将访问 Service 的流量转发到后端 Pod，而且使用类似轮询的负载均衡策略。

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

开启 ipvs

默认缺省使用的是iptables，如果kube-proxy使用ipvs进行转发的话，需要我们开启ipvs，具体可以查看我之前的部署博文。
开启ipvs之后的规则如下，看起来更加直观，建议大家启用ipvs。

[root@master ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.17.0.1:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  192.168.1.200:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  10.96.0.1:443 rr
  -> 192.168.1.200:6443           Masq    1      0          0         
TCP  10.96.0.10:53 rr
  -> 10.244.0.4:53                Masq    1      0          0         
  -> 10.244.0.5:53                Masq    1      0          0         
TCP  10.99.143.93:80 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  10.244.0.0:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  10.244.0.1:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
TCP  127.0.0.1:32501 rr
  -> 10.244.1.4:8080              Masq    1      0          0         
  -> 10.244.1.5:8080              Masq    1      0          0         
  -> 10.244.2.4:8080              Masq    1      0          0         
UDP  10.96.0.10:53 rr
  -> 10.244.0.4:53                Masq    1      0          0         
  -> 10.244.0.5:53                Masq    1      0          0

四、DNS 访问 Service

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

kubeadm 部署时会默认安装 coredns 组件。

[root@master ~]# kubectl get deploy -n kube-system
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
coredns   2/2     2            2           84m

coredns 是一个 DNS 服务器。每当有新的 Service 被创建，coredns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过 &lt;SERVICE_NAME&gt;.&lt;NAMESPACE_NAME&gt; 访问 Service。

比如可以用 mytest-svc.default 访问 Service mytest-svc。

[root@master ~]# kubectl run busybox --rm -it --image=busybox /bin/sh
If you don't see a command prompt, try pressing enter.
/ # wget mytest-svc.default
Connecting to mytest-svc.default (10.100.77.149:80)
index.html           100% |*********************************************************|    70  0:00:00 ETA
/ #

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

五、外网访问 Service

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

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

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

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

下面我们来实践 NodePort，Service mytest-svc.yaml 的配置文件修改如下：

apiVersion: v1
kind: Service
metadata:
  name: mytest-svc
spec:
  type: NodePort
  selector:
    run: mytest
  ports:
  - port: 80
    targetPort: 8080

添加 type: NodePort，重新创建 mytest-svc。

[root@master ~]# kubectl apply -f mytest-svc.yaml 
service/mytest-svc configured
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        98m
mytest-svc   NodePort    10.100.77.149   <none>        80:31298/TCP   65m

Kubernetes 依然会为 mytest-svc 分配一个 ClusterIP，不同的是：PORT(S) 为 80:31298。80 是 ClusterIP 监听的端口，31298 则是节点上监听的端口，我们可以使用节点的 IP:PORT 访问 Pod。Kubernetes 会从 30000-32767 中分配一个可用的端口，每个节点都会监听此端口并将请求转发给 Service。

[root@master ~]# curl 192.168.1.200:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
[root@master ~]# curl 192.168.1.201:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
[root@master ~]# curl 192.168.1.202:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1

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

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

-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mytest-svc:" -m tcp --dport 31298 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mytest-svc:" -m tcp --dport 31298 -j KUBE-SVC-XKNZ3BN47GCYFIPJ

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

-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-6VUP2B3YLPPLYJJV
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ENVKJLELDEHDNVGK
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -j KUBE-SEP-IZPSUB6K7QCCEPS3

其作用就是负载均衡到每一个 Pod。NodePort 默认是的随机选择，不过我们可以用 nodePort 指定某个特定端口。

apiVersion: v1
kind: Service
metadata:
  name: mytest-svc
spec:
  type: NodePort
  selector:
    run: mytest
  ports:
  - port: 80
    nodePort: 30000
    targetPort: 8080
  • nodePort 是节点上监听的端口。
  • port 是 ClusterIP 上监听的端口。
  • targetPort 是 Pod 监听的端口。

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

赞(0)
【声明】：本博客不参与任何交易，也非中介，仅记录个人感兴趣的主机测评结果和优惠活动，内容均不作直接、间接、法定、约定的保证。访问本博客请务必遵守有关互联网的相关法律、规定与规则。一旦您访问本博客，即表示您已经知晓并接受了此声明通告。
分享到

相关推荐

热门推荐

分类目录

香港VPS 欧洲VPS 日本VPS 印尼VPS 外贸VPS 美国VPS 迪拜VPS 德国VPS 韩国VPS 便宜VPS 英国VPS 荷兰VPS 南非VPS 印度VPS 越南VPS 法国VPS 埃及VPS 巴林VPS 波兰VPS 巴西VPS 台湾VPS 纽约VPS 高防VPS 西雅图VPS 圣何塞VPS 芝加哥VPS 达拉斯VPS 土耳其VPS 新加坡VPS 菲律宾VPS 俄罗斯VPS 柬埔寨VPS 搬瓦工VPS 大硬盘VPS 卢森堡VPS 孟加拉国VPS 澳大利亚VPS 保加利亚VPS 马来西亚VPS 印度尼西亚VPS 沙特阿拉伯VPS CDN 高防CDN 云服务器 香港服务器 日本服务器 欧洲服务器 美国服务器 德国服务器 韩国服务器 英国服务器 荷兰服务器 南非服务器 外贸服务器 印度服务器 非洲服务器 站群服务器 越南服务器 台湾服务器 高防服务器 新加坡服务器 菲律宾服务器 俄罗斯服务器