k8s在pod内无法ping通servicename和ClusterIP

该博客详细介绍了如何在Kubernetes集群中将iptables替换为IPVS作为服务负载均衡器。首先,通过修改`/etc/sysctl.conf`并应用设置来开启内核支持。接着,安装并加载IPVS相关模块。然后,编辑kube-proxy的配置文件,将模式改为ipvs。完成配置后,重启kube-proxy服务,并通过查看kube-proxy日志确认已切换到IPVS模式。最后,验证服务间通信恢复正常,不再出现iptables时的错误。

需要使用 ipvs 替换iptables,操作是在所有节点上

1:开启内核支持

1

2

3

4

5

6

7

cat >> /etc/sysctl.conf << EOF

net.ipv4.ip_forward = 1

net.bridge.bridge-nf-call-iptables = 1

net.bridge.bridge-nf-call-ip6tables = 1

EOF

sysctl -p

  

2:开启ipvs支持

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

yum -y install ipvsadm  ipset

# 临时生效

modprobe -- ip_vs

modprobe -- ip_vs_rr

modprobe -- ip_vs_wrr

modprobe -- ip_vs_sh

modprobe -- nf_conntrack_ipv4

# 永久生效

cat > /etc/sysconfig/modules/ipvs.modules <<EOF

modprobe -- ip_vs

modprobe -- ip_vs_rr

modprobe -- ip_vs_wrr

modprobe -- ip_vs_sh

modprobe -- nf_conntrack_ipv4

EOF

  

3:配置kube-proxy,在master上操作,因使用kubeadmin安装,所以操作方式如下

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

[root@master] # kubectl edit cm kube-proxy -n kube-system

configmap/kube-proxy edited

#修改如下

kind: MasterConfiguration

apiVersion: kubeadm.k8s.io/v1alpha1

...

ipvs:

      excludeCIDRs: null

      minSyncPeriod: 0s

      scheduler: ""

      syncPeriod: 30s

    kind: KubeProxyConfiguration

    metricsBindAddress: 127.0.0.1:10249

    mode: "ipvs"                  #修改

  

4:在master重启kube-proxy

1

kubectl  get pod -n kube-system | grep kube-proxy | awk '{print $1}' | xargs kubectl delete pod -n kube-system

  

5:验证ipvs是否开启

1

2

3

4

5

6

7

8

9

10

11

[root@k8s-m mytest]# kubectl logs kube-proxy-cvzb4 -n kube-system

I0409 03:37:29.194391       1 server_others.go:170] Using ipvs Proxier.

W0409 03:37:29.194779       1 proxier.go:401] IPVS scheduler not specified, use rr by default

I0409 03:37:29.194981       1 server.go:534] Version: v1.15.3

I0409 03:37:29.214255       1 conntrack.go:52] Setting nf_conntrack_max to 524288

I0409 03:37:29.216744       1 config.go:96] Starting endpoints config controller

I0409 03:37:29.216812       1 controller_utils.go:1029] Waiting for caches to sync for endpoints config controller

I0409 03:37:29.217445       1 config.go:187] Starting service config controller

I0409 03:37:29.218320       1 controller_utils.go:1029] Waiting for caches to sync for service config controller

I0409 03:37:29.318218       1 controller_utils.go:1036] Caches are synced for endpoints config controller

I0409 03:37:29.318564       1 controller_utils.go:1036] Caches are synced for service config controller

  

6:进入pod内,现在可以ping通servicename了,使用iptables时,发现ping的时候出现了如下错误,执行完上述操作,一切正常

1

2

3

4

root@xxxxxx-cb4c9cb8c-hpzdl:/opt# ping xxxxxx

PING xxxxxx.xxxxx.svc.cluster.local (172.16.140.78) 56(84) bytes of data.

From 172.16.8.1 (172.16.8.1) icmp_seq=1 Time to live exceeded

From 172.16.8.1 (172.16.8.1) icmp_seq=2 Time to live exceeded

### 3.1 检查 CoreDNS 的 ClusterIP 服务配置 CoreDNS 作为集群内部的 DNS 服务,常以 Service 形式暴露在 `kube-system` 命名空间中,其 ClusterIP 常是 `10.96.0.10`。首先应确认该 Service 是否正常存在并配置正确: ```bash kubectl get service kube-dns -n kube-system ``` 输出应包含如下信息: ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 1d ``` 如果 ClusterIP 不一致或服务不存在,则可能是 CoreDNS 配置错误或未正确部署。 ### 3.2 确认 CoreDNS Pod 运行状态 CoreDNS Pod 应该位于 `kube-system` 命名空间,并且处于 Running 状态: ```bash kubectl get pods -n kube-system -l k8s-app=kube-dns ``` 若 Pod 处于 Pending、CrashLoopBackoff 或 Error 状态,需进一步查看日志排查原因: ```bash kubectl logs <coredns-pod-name> -n kube-system ``` 若发现日志中有频繁重启或网络连接失败的信息,可能与 CNI 插件(如 Kube-OVN)配置有关,需结合网络插件日志进行分析[^2]。 ### 3.3 检查 Pod 内部 `/etc/resolv.conf` 配置 进入目标 Pod 容器内,查看其 DNS 解析配置是否指向正确的 CoreDNS 地址: ```bash kubectl exec -it <pod-name> -- cat /etc/resolv.conf ``` 正常情况下应包含如下内容: ``` nameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5 ``` 如果 `nameserver` 不是 `10.96.0.10`,说明 Pod 的 DNS 设置被覆盖,可能是因为设置了自定义 DNS 配置(如 `dnsPolicy` 或 `dnsConfig` 字段),需检查 Deployment 或 PodSpec 中的相关字段。 ### 3.4 测试 Pod 到 CoreDNS ClusterIP 的连性 使用 `nslookup` 或 `dig` 测试从 Pod 到 CoreDNS 的解析能力: ```bash kubectl exec -it <pod-name> -- nslookup kubernetes.default ``` 如果返回超时或无法解析,可尝试使用 `tcpdump` 抓包分析 DNS 请求是否到达 CoreDNS Pod: ```bash kubectl exec -it <coredns-pod-name> -n kube-system -- tcpdump -i any port 53 ``` 同时,在测试 Pod 内执行 DNS 查询,观察是否有请求发出及响应返回。 ### 3.5 排查网络插件问题(如 Kube-OVN) Kubernetes 中的 Pod IP 是虚拟 IP 地址,由 CNI 插件分配管理[^3]。若使用 Kube-OVN 等网络插件,需确保其组件正常运行: ```bash kubectl get pods -n ovn-system ``` Kube-OVN 过 OVN-NB 创建虚拟交换机接口,并将 IP、Mac、GW 等信息写入 Pod Annotation,再由 kube-ovn-cni 配置容器网络[^2]。若这些组件异常,可能导致 Pod 无法访问 ClusterIP。 还可以过以下方式测试 Pod 到 CoreDNS ClusterIP 的网络可达性: ```bash kubectl exec -it <pod-name> -- ping 10.96.0.10 ``` 若 Ping,但 CoreDNS Pod 可达,则可能是 kube-proxy 的 Iptables 规则未正确设置,导致 ClusterIP 转发失败[^3]。 ### 3.6 检查 kube-proxy 配置与 Iptables 规则 kube-proxy 负责维护 ClusterIP 到后端 Pod 的转发规则。可以登录到节点上查看 Iptables 规则是否存在: ```bash iptables -t nat -L -v | grep 10.96.0.10 ``` 如果找不到对应的 DNAT 或 MASQUERADE 规则,说明 kube-proxy 未正常工作,可能需要重启 kube-proxy 或检查其配置。 此外,可以过以下命令查看 kube-proxy 的日志: ```bash journalctl -u kube-proxy ``` ### 3.7 使用 NetworkPolicy 限制导致的问题排查 如果启用了 NetworkPolicy 来控制 Pod信,需确保允许 Pod 访问 CoreDNS 的 ClusterIP 端口(53)。例如: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns spec: podSelector: {} ingress: [] policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.96.0.10/32 ports: - protocol: UDP port: 53 - protocol: TCP port: 53 ``` 若无此类策略放行,可能导致 Pod 无法访问 DNS 服务。 --- ###
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值