如何在智能告警平台CA触发测试告警
719
2023-03-07
k8s通过service访问pod(五)
service
每个 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 没有变。
第一步:创建下面的这个 Deployment:
查看支持的apiversion使用命令kubectl api-versions
第二步:部署并查看pod
第三步:集群内部测试连通性
Pod 分配了各自的 IP,这些 IP 只能被 Kubernetes Cluster 中的容器和节点访问。
[root@ken ~]# curl 10.244.1.28<html><body><h1>It works!</h1></body></html>[root@ken ~]# curl 10.244.1.27<html><body><h1>It works!</h1></body></html>[root@ken ~]# curl 10.244.2.18<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 10.244.1.28
第四步:接下来创建 Service,其配置文件如下:
① v1 是 Service 的 apiVersion。
② 指明当前资源的类型为 Service。
⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 协议。
[root@ken ~]# curl 10.106.64.97:8080<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 10.106.64.97:8080
Endpoints 罗列了三个 Pod 的 IP 和端口。
service ip底层原理分析
我们知道 Pod 的 IP 是在容器中配置的,那么 Service 的 Cluster IP 又是配置在哪里的呢?CLUSTER-IP 又是如何映射到 Pod IP 的呢?
答案是 iptables
Service Cluster IP 是一个虚拟 IP,是由 Kubernetes 节点上的 iptables 规则管理的。
查看svc
[root@ken1 ~]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 15dmy-svc ClusterIP 10.107.111.108 <none> 80/TCP 16s
[root@ken1 ~]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1
可以通过 iptables-save 命令打印出当前节点的 iptables 规则,因为输出较多,这里只截取与my-svc Cluster IP 10.99.229.179 相关的信息:
这两条规则的含义是:
KUBE-SVC-NSPZQM4WNKQARS3D规则如下:
1/3 的概率跳转到规则 KUBE-SEP-PHYMVJLGA3SBF53W1/3 的概率(剩下 2/3 的一半)跳转到规则 KUBE-SEP-6WM3EVRMZRPSARU61/3 的概率跳转到规则 KUBE-SEP-MF65K4BIWBNT73JP
上面三个跳转的规则如下:
[root@ken1 ~]# iptables-save | grep KUBE-SEP-PHYMVJLGA3SBF53W-A KUBE-SEP-PHYMVJLGA3SBF53W -s 10.244.1.50/32 -j KUBE-MARK-MASQ-A KUBE-SEP-PHYMVJLGA3SBF53W -p tcp -m tcp -j DNAT --to-destination 10.244.1.50:80[root@ken1 ~]# iptables-save | grep KUBE-SEP-6WM3EVRMZRPSARU6-A KUBE-SEP-6WM3EVRMZRPSARU6 -s 10.244.2.129/32 -j KUBE-MARK-MASQ-A KUBE-SEP-6WM3EVRMZRPSARU6 -p tcp -m tcp -j DNAT --to-destination 10.244.2.129:80[root@ken1 ~]# iptables-save | grep KUBE-SEP-MF65K4BIWBNT73JP-A KUBE-SEP-MF65K4BIWBNT73JP -s 10.244.2.130/32 -j KUBE-MARK-MASQ-A KUBE-SEP-MF65K4BIWBNT73JP -p tcp -m tcp -j DNAT --to-destination 10.244.2.130:80
[root@ken1 ~]# iptables-save | grep KUBE-SEP-PHYMVJLGA3SBF53W-A KUBE-SEP-PHYMVJLGA3SBF53W -s 10.244.1.50/32 -j KUBE-MARK-MASQ-A KUBE-SEP-PHYMVJLGA3SBF53W -p tcp -m tcp -j DNAT --to-destination 10.244.1.50:80[root@ken1 ~]# iptables-save | grep KUBE-SEP-6WM3EVRMZRPSARU6-A KUBE-SEP-6WM3EVRMZRPSARU6 -s 10.244.2.129/32 -j KUBE-MARK-MASQ-A KUBE-SEP-6WM3EVRMZRPSARU6 -p tcp -m tcp -j DNAT --to-destination 10.244.2.129:80[root@ken1 ~]# iptables-save | grep KUBE-SEP-MF65K4BIWBNT73JP-A KUBE-SEP-MF65K4BIWBNT73JP -s 10.244.2.130/32 -j KUBE-MARK-MASQ-A KUBE-SEP-MF65K4BIWBNT73JP -p tcp -m tcp -j DNAT --to-destination 10.244.2.130:80
即将请求分别转发到后端的三个 Pod。通过上面的分析,我们得到如下结论:
iptables 将访问 Service 的流量转发到后端 Pod,而且使用类似轮询的负载均衡策略。
另外需要补充一点:Cluster 的每一个节点都配置了相同的 iptables 规则,这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service。
DNS访问service
在 Cluster 中,除了可以通过 Cluster IP 访问 Service,Kubernetes 还提供了更为方便的 DNS 访问。
第一步:查看coredns
kubeadm 部署时会默认安装 coredns 组件。
[root@ken ~]# kubectl get deployment --namespace=kube-systemNAME READY UP-TO-DATE AVAILABLE AGEcoredns 2/2 2 2 11h
[root@ken ~]# kubectl get deployment --namespace=kube-systemNAME READY UP-TO-DATE AVAILABLE AGEcoredns 2/2 2 2 11h
coredns 是一个 DNS 服务器。每当有新的 Service 被创建,coredns 会添加该 Service 的 DNS 记录。Cluster 中的 Pod 可以通过
第二步:dns访问
第三步:查看namespace
如果要访问其他 namespace 中的 Service,就必须带上 namesapce 了。kubectl get namespace 查看已有的 namespace。
[root@ken ~]# kubectl get namespaceNAME STATUS AGEdefault Active 11hkube-public Active 11hkube-system Active 11h
[root@ken ~]# kubectl get namespaceNAME STATUS AGEdefault Active 11hkube-public Active 11hkube-system Active 11h
配置如下:
第五步:创建资源
通过 namespace: kube-public 指定资源所属的 namespace。多个资源可以在一个 YAML 文件中定义,用 — 分割。执行 kubectl apply 创建资源:
第六步:查看 kube-public 的 Service:
外网访问service
除了 Cluster 内部可以访问 Service,很多情况我们也希望应用的 Service 能够暴露给 Cluster 外部。Kubernetes 提供了多种类型的 Service,默认是 ClusterIP。
ClusterIP
Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 ClusterIP。
NodePort
Service 通过 Cluster 节点的静态端口对外提供服务。Cluster 外部可以通过
LoadBalancer
Service 利用 cloud provider 特有的 load balancer 对外提供服务,cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
第二步:创建service
EXTERNAL-IP 为 nodes,表示可通过 Cluster 每个节点自身的 IP 访问 Service。
PORT(S) 为 8080:31785。8080 是 ClusterIP 监听的端口(每个节点都有该端口),31785 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口,每个节点都会监听此端口并将请求转发给 Service。
[root@ken ~]# ss -tnl | grep 31785LISTEN 0 128 :::31785 :::*
[root@ken ~]# ss -tnl | grep 31785LISTEN 0 128 :::31785 :::*
第三步:测试nodeport是否正常工作
[root@ken ~]# curl 172.20.10.2:31785<html><body><h1>It works!</h1></body></html>[root@ken ~]# curl 172.20.10.7:31785<html><body><h1>It works!</h1></body></html>[root@ken ~]# curl 172.20.10.9:31785<html><body><h1>It works!</h1></body></html>
[root@ken ~]# curl 172.20.10.2:31785
第四步:指定特定端口
NodePort 默认是的随机选择,不过我们可以用 nodePort 指定某个特定端口。
现在配置文件中就有三个 Port 了:
nodePort 是节点上监听的端口。
port 是 ClusterIP 上监听的端口。
targetPort 是 Pod 监听的端口。
最终,Node 和 ClusterIP 在各自端口上接收到的请求都会通过 iptables 转发到 Pod 的 targetPort。
第四步:应用新的 nodePort 并验证:
nodePort: 30000 已经生效了。
接下来我们深入探讨一个问题:Kubernetes 是如何将
与 ClusterIP 一样,也是借助了 iptables。与 ClusterIP 相比,每个节点的 iptables 中都增加了下面两条规则:
第一步:查看svc端口
[root@ken1 ~]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 15dmy-svc NodePort 10.107.111.108 <none> 80:32287/TCP 14m
[root@ken1 ~]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1
第二步:查看iptables规则
规则的含义是:访问当前节点 32312 端口的请求会应用规则 KUBE-SVC-NSPZQM4WNKQARS3D
第三步:相应规则KUBE-SVC-NSPZQM4WNKQARS3D
其作用就是负载均衡到每一个 Pod。
发表评论
暂时没有评论,来抢沙发吧~