Pod容器内部无法ping 通ClusterIP(或ServiceName)

Pod容器内部无法ping 通ClusterIP(或ServiceName)

环境信息

  • 系统:Ubuntu18.04
  • k8s版本:1.14.0
  • 网络插件:flannel

进入容器内部测试

ping ClusterIP:无法ping通

coder@user1-container10-79754b6fcd-vmrhp:~/project$ ping 10.103.84.93
PING 10.103.84.93 (10.103.84.93) 56(84) bytes of data.
^C
--- 10.103.84.93 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11244ms

ping servicename:无法ping通

coder@user1-container10-79754b6fcd-vmrhp:~/project$ ping user1-container0
PING user1-container0.iblockchain.svc.cluster.local (10.107.200.99) 56(84) bytes of data.
^C
--- user1-container0.iblockchain.svc.cluster.local ping statistics ---
69 packets transmitted, 0 received, 100% packet loss, time 69610ms

查看kube-proxy日志

k8s@master:~$ kubectl logs -n kube-system kube-proxy-6lw4d
W0521 14:10:15.618034       1 server_others.go:295] Flag proxy-mode="" unknown, assuming iptables proxy
I0521 14:10:15.640642       1 server_others.go:148] Using iptables Proxier.
I0521 14:10:15.640845       1 server_others.go:178] Tearing down inactive rules.
E0521 14:10:15.690628       1 proxier.go:583] Error removing iptables rules in ipvs proxier: error deleting chain "KUBE-MARK-MASQ": exit status 1: iptables: Too many links.
I0521 14:10:16.294665       1 server.go:555] Version: v1.14.0
I0521 14:10:16.307621       1 conntrack.go:52] Setting nf_conntrack_max to 1310720
I0521 14:10:16.308167       1 config.go:102] Starting endpoints config controller
I0521 14:10:16.308247       1 controller_utils.go:1027] Waiting for caches to sync for endpoints config controller
I0521 14:10:16.308300       1 config.go:202] Starting service config controller
I0521 14:10:16.308339       1 controller_utils.go:1027] Waiting for caches to sync for service config controller
I0521 14:10:16.408477       1 controller_utils.go:1034] Caches are synced for endpoints config controller
I0521 14:10:16.408477       1 controller_utils.go:1034] Caches are synced for service config controller

原因:kube-proxy使用了iptable模式,修改为ipvs模式则可以在pod内ping通clusterIP或servicename

解决

查看kube-proxy configMapkubectl get cm kube-proxy -n kube-system -o yaml

发现执行命令后输出的mode: ""

k8s@master:~$ kubectl get cm kube-proxy -n kube-system -o yaml
apiVersion: v1
data:
  config.conf: |-
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    bindAddress: 0.0.0.0
    clientConnection:
      acceptContentTypes: ""
      burst: 10
      contentType: application/vnd.kubernetes.protobuf
      kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
      qps: 5
    clusterCIDR: 10.244.0.0/16
    configSyncPeriod: 15m0s
    conntrack:
      max: null
      maxPerCore: 32768
      min: 131072
      tcpCloseWaitTimeout: 1h0m0s
      tcpEstablishedTimeout: 24h0m0s
    enableProfiling: false
    healthzBindAddress: 0.0.0.0:10256
    hostnameOverride: ""
    iptables:
      masqueradeAll: false
      masqueradeBit: 14
      minSyncPeriod: 0s
      syncPeriod: 30s
    ipvs:
      excludeCIDRs: null
      minSyncPeriod: 0s
      scheduler: ""
      syncPeriod: 30s
    kind: KubeProxyConfiguration
    metricsBindAddress: 127.0.0.1:10249
    mode: ""
    nodePortAddresses: null
    oomScoreAdj: -999
    portRange: ""
    resourceContainer: /kube-proxy
    udpIdleTimeout: 250ms
    winkernel:
      enableDSR: false
      networkName: ""
      sourceVip: ""
  kubeconfig.conf: |-
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        server: https://172.18.167.38:6443
      name: default
    contexts:
    - context:
        cluster: default
        namespace: default
        user: default
      name: default
    current-context: default
    users:
    - name: default
      user:
        tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
kind: ConfigMap
metadata:
  creationTimestamp: "2020-05-02T04:00:39Z"
  labels:
    app: kube-proxy
  name: kube-proxy
  namespace: kube-system
  resourceVersion: "231"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kube-proxy
  uid: 7bfe9acc-8c29-11ea-bf4b-be066b02b900

编辑kube-proxy configMap,修改mode为ipvskubectl edit cm kube-proxy -n kube-system

...
iptables:
  masqueradeAll: false
  masqueradeBit: 14
  minSyncPeriod: 0s
  syncPeriod: 30s
ipvs:
  excludeCIDRs: null
  minSyncPeriod: 0s
  scheduler: ""
  syncPeriod: 30s
kind: KubeProxyConfiguration
metricsBindAddress: 127.0.0.1:10249
mode: "ipvs"
...

使用ipvs需要执行以下操作

cat > /etc/sysconfig/modules/ipvs.modules <<EOF
 #!/bin/bash 
 modprobe -- ip_vs 
 modprobe -- ip_vs_rr 
 modprobe -- ip_vs_wrr 
 modprobe -- ip_vs_sh 
 modprobe -- nf_conntrack_ipv4 
EOF
k8s@master:~$ sudo chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4
ip_vs_sh               16384  0 
ip_vs_wrr              16384  0 
ip_vs_rr               16384  0 
ip_vs                 151552  6 ip_vs_rr,ip_vs_sh,ip_vs_wrr
nf_defrag_ipv6         20480  2 nf_conntrack_ipv6,ip_vs
nf_conntrack_ipv4      16384  47 
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_conntrack          131072  12 xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat,nf_nat_ipv6,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_conntrack_netlink,ip_vs,xt_REDIRECT
libcrc32c              16384  4 nf_conntrack,nf_nat,xfs,ip_vs

重启kube-proxy

k8s@master:~$ kubectl get pod -n kube-system | grep kube-proxy |awk '{system("kubectl delete pod "$1" -n kube-system")}'
pod "kube-proxy-6lw4d" deleted

查看kube-proxy日志

k8s@master:~$  kubectl get pod -n kube-system |grep kube-proxy
kube-proxy-7sxpv                       1/1     Running   0          86s
k8s@master:~$  kubectl logs -n kube-system kube-proxy-7sxpv
I0522 15:41:32.391309       1 server_others.go:189] Using ipvs Proxier.
W0522 15:41:32.391855       1 proxier.go:381] IPVS scheduler not specified, use rr by default
I0522 15:41:32.391999       1 server_others.go:216] Tearing down inactive rules.
I0522 15:41:32.477963       1 server.go:555] Version: v1.14.0
I0522 15:41:32.490131       1 conntrack.go:52] Setting nf_conntrack_max to 1310720
I0522 15:41:32.490544       1 config.go:102] Starting endpoints config controller
I0522 15:41:32.490604       1 controller_utils.go:1027] Waiting for caches to sync for endpoints config controller
I0522 15:41:32.490561       1 config.go:202] Starting service config controller
I0522 15:41:32.490659       1 controller_utils.go:1027] Waiting for caches to sync for service config controller
I0522 15:41:32.590799       1 controller_utils.go:1034] Caches are synced for endpoints config controller
I0522 15:41:32.590894       1 controller_utils.go:1034] Caches are synced for service config controller

至此问题解决

再次进入Pod容器内部进行测试

查看svc

k8s@master:~$ kubectl get svc -n iblockchain
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
mysql               ClusterIP   10.103.84.93    <none>        3306/TCP       15d
user1-container0    ClusterIP   10.107.200.99   <none>        80/TCP         6d21h
user1-container10   ClusterIP   10.110.35.111   <none>        80/TCP         6d13h
user1-container12   ClusterIP   10.97.251.199   <none>        80/TCP         5d13h
user1-container13   ClusterIP   10.98.144.124   <none>        80/TCP         5d13h
webapp              NodePort    10.102.63.171   <none>        80:30000/TCP   6d15h

进入pod ping servicename

coder@user1-container10-79754b6fcd-vmrhp:~/project$ ping user1-container0
PING user1-container0.iblockchain.svc.cluster.local (10.107.200.99) 56(84) bytes of data.
64 bytes from user1-container0.iblockchain.svc.cluster.local (10.107.200.99): icmp_seq=1 ttl=64 time=0.102 ms
64 bytes from user1-container0.iblockchain.svc.cluster.local (10.107.200.99): icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from user1-container0.iblockchain.svc.cluster.local (10.107.200.99): icmp_seq=3 ttl=64 time=0.074 ms

这里有个小坑,若两个pod处于不同的命名空间,ping servicename需要输入完整的dns,如:

k8s@master:~$ kubectl get svc -A
NAMESPACE     NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
admin         dl1588401175722-tensorflow-cpu   ClusterIP   10.99.220.121    <none>        8000/TCP,8080/TCP,6080/TCP   20d
admin         dl1588401391658-tensorflow-cpu   ClusterIP   10.102.167.253   <none>        8000/TCP,8080/TCP,6080/TCP   20d
admin         dl1588401420047-tensorflow-gpu   ClusterIP   10.109.168.48    <none>        8000/TCP,8080/TCP,6080/TCP   20d
admin         dl1588698113367-tensorflow-cpu   ClusterIP   10.97.78.194     <none>        8000/TCP,8080/TCP,6080/TCP   16d
default       kubernetes                       ClusterIP   10.96.0.1        <none>        443/TCP                      20d
iblockchain   mysql                            ClusterIP   10.103.84.93     <none>        3306/TCP                     15d
iblockchain   user1-container0                 ClusterIP   10.107.200.99    <none>        80/TCP                       6d21h
iblockchain   user1-container10                ClusterIP   10.110.35.111    <none>        80/TCP                       6d13h
iblockchain   user1-container12                ClusterIP   10.97.251.199    <none>        80/TCP                       5d13h
iblockchain   user1-container13                ClusterIP   10.98.144.124    <none>        80/TCP                       5d13h
iblockchain   webapp                           NodePort    10.102.63.171    <none>        80:30000/TCP                 6d15h
kube-system   kube-dns                         ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP       20d

servicename:dl1588401175722-tensorflow-cpu

coder@user1-container10-79754b6fcd-vmrhp:~/project$ ping dl1588401175722-tensorflow-cpu
ping: dl1588401175722-tensorflow-cpu: Name or service not known

完整DNS:dl1588401175722-tensorflow-cpu.admin.svc.cluster.local

coder@user1-container10-79754b6fcd-vmrhp:~/project$ ping dl1588401175722-tensorflow-cpu.admin.svc.cluster.local
PING dl1588401175722-tensorflow-cpu.admin.svc.cluster.local (10.99.220.121) 56(84) bytes of data.
64 bytes from dl1588401175722-tensorflow-cpu.admin.svc.cluster.local (10.99.220.121): icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from dl1588401175722-tensorflow-cpu.admin.svc.cluster.local (10.99.220.121): icmp_seq=2 ttl=64 time=0.094 ms
64 bytes from dl1588401175722-tensorflow-cpu.admin.svc.cluster.local (10.99.220.121): icmp_seq=3 ttl=64 time=0.116 ms
64 bytes from dl1588401175722-tensorflow-cpu.admin.svc.cluster.local (10.99.220.121): icmp_seq=4 ttl=64 time=0.127 ms
  • 6
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
### 回答1: ClusterIP Service 是 Kubernetes 中一种 Service 类型,它会为后端 Pod 提供一个虚拟 IP 地址,使得在集群内部可以过这个虚拟 IP 地址来访问后端 Pod,而不需要知道具体的 Pod IP 地址。ClusterIP Service 的优缺点如下: 优点: 1. 高可用性:ClusterIP Service 支持负载均衡,可以将请求均匀地分配给多个后端 Pod,从而提高应用的可用性。 2. 灵活性:ClusterIP Service 支持配置多种负载均衡算法和会话保持方式,可以根据实际需求进行灵活配置。 3. 安全性:ClusterIP Service 只在集群内部暴露虚拟 IP 地址,不会将后端 Pod 直接暴露给外部网络,从而提高了应用的安全性。 缺点: 1. 仅适用于集群内部访问:ClusterIP Service 只能在 Kubernetes 集群内部使用,无法过外部网络直接访问。 2. 不支持动态扩容:ClusterIP Service 只能在创建时指定后端 Pod 的数量,无法动态地根据负载自动扩容。 3. 无法实现跨集群访问:ClusterIP Service 只能在同一集群内部进行负载均衡,无法实现跨集群访问。 ### 回答2: K8s中的ClusterIP Service是一种服务发现和负载均衡机制,它有以下优点: 1. 内部服务访问:ClusterIP Service允许在集群内部创建一个虚拟的固定IP地址,用于访问部署在集群内的服务。这个IP地址可以供其他PodService使用,方便进行内部信,无需暴露到集群外部。 2. 负载均衡:ClusterIP Service,可以将请求均匀地分发到后端的多个Pod上,实现负载均衡。这样可以提高服务的可用性、扩展性和性能。 3. 内部DNS解析:ClusterIP Service会自动为每个Service分配一个唯一的DNS名称,这样可以过名称来访问Service,而无需直接使用Pod的IP地址。这样,当Pod的IP地址发生变化时,不会影响到服务的访问。 然而,ClusterIP Service也有一些缺点: 1. 无法供集群外部访问:ClusterIP Service只能在集群内部使用,无法过集群外部的IP地址直接访问。如果需要集群外部访问,需要结合其他类型的Service,如NodePort或LoadBalancer。 2. 不能实现会话保持:ClusterIP Service默认使用基于IP的负载均衡算法,不保证请求会发送到同一个后端Pod上。这就导致无法实现会话保持,对于需要保持会话状态的应用可能存在问题。 3. 无法处理动态变化:当创建或删除Pod时,ClusterIP Service需要重新配置和更新。在大规模的集群中,频繁的Pod变化可能导致Service的配置更新变得复杂和有延迟。 总的来说,ClusterIP Service在K8s集群中有诸多优点,如方便的内部服务发现和负载均衡,但也有一些限制,无法用于集群外部访问,不支持会话保持,以及对动态变化的响应较慢。 ### 回答3: Kubernetes(k8s)是一个用于自动化管理容器化应用程序的开源平台,而ClusterIP Service是k8s中的一种服务类型。下面是ClusterIP Service的优缺点: 优点: 1. 内部访问:ClusterIP Service内部应用程序提供了一个虚拟的集群IP地址,只对集群内可见。这允许应用程序在集群内部相互信,同时保护应用程序免受来自外部的未经授权的访问。 2. 负载均衡:ClusterIP Service可以在后端Pod之间进行负载均衡。它可以自动将流量分发到后端Pod实例,以提高应用程序的可用性和性能。 3. 简化网络配置:过使用ClusterIP Service,应用程序可以过单个虚拟IP地址访问多个后端Pod实例,而不需要知道每个Pod的具体IP地址。这简化了网络配置和管理的复杂性。 4. 无需暴露端口:ClusterIP Service只在集群内部使用,没有暴露到集群外部。这样可以确保应用程序仅对集群内的其他组件可见,而不受来自外部的潜在攻击。 缺点: 1. 无法从集群外部访问:ClusterIP Service只在集群内可用,无法从集群外部直接访问。如果需要将应用程序暴露给外部用户或设备,则需要使用其他类型的Service如NodePort或LoadBalancer。 2. 需要额外配置:ClusterIP Service需要在k8s集群中进行额外的配置。这包括创建Service对象、定义后端Pod等。相对于其他类型的ServiceClusterIP Service的设置和管理需要一些额外的步骤。 3. 网络层面问题:ClusterIP Service是在网络层面上实现的,因此可能会存在一些网络层面的问题。例如,可能会出现网络延迟或丢包等问题,尤其是在大规模部署时。 总的来说,ClusterIP Service提供了许多方便和安全的特性,但也有一些限制。开发人员需要根据应用程序的具体需求和部署环境来选择合适的Service类型。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值