开启 K8s 服务异常排障过程前,须对 K8s 服务的访问路径有一个全面的了解,下面我们先介绍目前常用的 K8s 服务访问方式(不同云原生平台实现方式可能基于部署方案、性能优化等情况会存在一些差异,但是如要运维 K8s 服务,则需要在一开始就对访问方式有一个了解)。
方式一:集群内客户端通过 ClusterIP 访问集群内服务
集群内客户端通过 ClusterIP 访问集群内服务
从访问逻辑拓扑
来分析,集群内客户端 POD 访问的是集群内服务的 svc_name,然后在 svc 层进行 DNAT,将请求转发到对应的后端 POD。这个过程对应的访问实现拓扑
则要复杂不少:
- step 1: client_pod 根据 DNS 配置,请求 DNS 服务器解析 svc_name,DNS 服务器会返回 svc_name 对应的 ClusterIP
- step 2: client_pod 请求 ClusterIP,Node 根据 kube-proxy 配置的 IPVS/IPTABLES 完成 DNAT
- step 3: 根据 DNAT 的结果,Node 将请求转发给对应的 server_pod,server_pod 可能与 client_pod 在同一个 Node,也可能在不同 Node,此差异主要体现在网络转发层面
方式二:集群外客户端通过 NodePort 访问集群内服务
集群外客户端通过 NodePort 访问集群内服务
相比方式一
,访问逻辑拓扑
上 client 访问的区别是从 svc_name 替换为 nodeip:port。访问实现拓扑
主要过程如下:
- step 1: client 直接请求 svc 对外暴露的 nodeip:port,如果是 LoadBalance 类型的服务,在此之前还会访问 LB(因为并不是 K8s 服务的中的特别能力,所以此处并无特别说明),请求转发到对应的 Node 上,Node 也会根据kube-proxy 配置的 IPVS/IPTABLES 完成 DNAT
- step 2: 与
方式一
的 step 3 一致
方式三:集群外客户端通过 Ingress 访问集群内服务
集群外客户端通过 Ingress 访问集群内服务
方式三
相比前两种方式,引入了 Ingress 的概念,因此复杂度增加了非常多。访问逻辑拓扑
中外部 client 可以直接请求 url 而不是 ip 了,请求 url 会先到达 Ingress,由 Ingress 完成反向代理,转发给后端的 svc,svc 再完成 DNAT 转发给后端 POD。访问实现拓扑
会根据 ingress-controller 部署形式不同而有差异,ingress-controller 非 hostnetwork 部署下文简称部署模式一
,ingress-controller hostnetwork 部署下文简称部署模式二
- step 1:外部 client 请求 DNS 服务器解析 url 的域名,DNS 服务会返回 ingress-controller 服务所在的 IP (如果前面有挂 LB,则访问的是 LB 的 IP,否则返回的是 ingress-controller 服务的 nodeip:port)
- step 2:此时
部署模式一
,则需要按方式二
访问 ingress-controller(为避免画图过于复杂,未画出 ingress_controller_pod 分布在不同 Node 场景);部署模式二
,请求到达 Node 后,则直接转给 ingress_controller_pod - step 3:此为
部署模式一
特有的步骤,参考方式二
- step 4/5/6:请求经过 ingress_controller_pod 后,已经确定需要转发的后端 svc,则按
方式一
进行转发即可(为避免画图过于复杂,未画出 server_pod 分布在同 Node 场景)