Score:0

I Could not ping or curl master node flannel interface

vn flag

I have 3 nodes in the cluster, one is the master node and two are the worker nodes. I use CNI flannel for the Kubernetes cluster. I run an Nginx ingress in my cluster for the load balancer and the hostname is host.com

this is my pods in the cluster

namespace         deploy-4yhghhf4d-345ck                                  1/1     Running   0          2d14h   10.45.0.55     agent-02   <none>           <none>
namespace         deploy-4yhghhf4d-a4fcf                                  1/1     Running   0          2d14h   10.45.1.25     master  <none>           <none>
namespace         deploy-4yhghhf4d-87678                                  1/1     Running   0          2d14h   10.45.2.30     agent-03 <none>           <none>

I tried to access from browser and from the command line. to access the deploy-fdtt88f4d-345ck and deploy-4yhghhf4d-a4fcf is a success via host.com. I can curl on the command line or via browser host.com.

Of course, the pods have an IP address. I want to try to access or ping those IP addresses through the command line.

from master side

master ping itself: ping  10.45.1.25 (success)
master ping agent-02: ping 10.45.0.55 (failed)
master ping agent-03: ping 10.45.2.30 (failed)

from agent side

agent-03 ping agent-02: ping 10.45.0.55 (success)
agent-02 ping agent-03: ping 10.45.2.30 (success)
agent-02 ping master: ping  10.45.1.25 (failed)

the point is whenever we ping or curl to or from master will always fail. no response. but agent to agent was successed.

I flush my iptables on the master side. but it is still not working.

iptables -L

# Warning: iptables-legacy tables present, use iptables-legacy to see them

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         



Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         



Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         



Chain KUBE-EXTERNAL-SERVICES (0 references)

target     prot opt source               destination         



Chain KUBE-FIREWALL (0 references)

target     prot opt source               destination         



Chain KUBE-FORWARD (0 references)

target     prot opt source               destination         



Chain KUBE-KUBELET-CANARY (0 references)

target     prot opt source               destination         



Chain KUBE-NODEPORTS (0 references)

target     prot opt source               destination         



Chain KUBE-NWPLCY-DEFAULT (0 references)

target     prot opt source               destination         



Chain KUBE-PROXY-CANARY (0 references)

target     prot opt source               destination         



Chain KUBE-ROUTER-FORWARD (0 references)

target     prot opt source               destination         



Chain KUBE-ROUTER-INPUT (0 references)

target     prot opt source               destination         



Chain KUBE-ROUTER-OUTPUT (0 references)

target     prot opt source               destination         



Chain KUBE-SERVICES (0 references)

target     prot opt source               destination     
#ip route
10.45.0.0/24 via 10.45.0.0 dev flannel.1 onlink 
10.45.1.0/24 via 10.45.1.0 dev flannel.1 onlink 
10.45.2.0/24 via 10.45.2.0 dev flannel.1 onlink
#cat /run/flannel/subnet.env

FLANNEL_NETWORK=10.45.0.0/16
FLANNEL_SUBNET=10.45.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

kubectl get nodes -o yaml |grep flannel.alpha

      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"16:cb:5c:78:57:cb"}'

      flannel.alpha.coreos.com/backend-type: vxlan

      flannel.alpha.coreos.com/kube-subnet-manager: "true"

      flannel.alpha.coreos.com/public-ip: 192.168.14.3

      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"7e:1e:e8:f6:8f:77"}'

      flannel.alpha.coreos.com/backend-type: vxlan

      flannel.alpha.coreos.com/kube-subnet-manager: "true"

      flannel.alpha.coreos.com/public-ip: 192.168.14.4

      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"06:cd:6a:ba:6b:54"}'

      flannel.alpha.coreos.com/backend-type: vxlan

      flannel.alpha.coreos.com/kube-subnet-manager: "true"

      flannel.alpha.coreos.com/public-ip: 10.0.3.15

      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"96:71:0e:48:52:4d"}'

      flannel.alpha.coreos.com/backend-type: vxlan

      flannel.alpha.coreos.com/kube-subnet-manager: "true"

      flannel.alpha.coreos.com/public-ip: 192.168.14.2

in flag
There are almost infinite things that could be wrong; what troubleshooting steps have you already tried? And do you have similar reachability problems with the Node's IP (not the CNI address)? Are all copies of flannel Running and Ready? You're going to have to edit your question to include more details if you want anyone to be able to help you
newcomers avatar
vn flag
ok, the question has been edited, I hope it is quite clear. thanks
in flag
Are you running in virtualbox? I ask because that 192.168 _and_ 10.0 `public-ip` smells like how vagrant brings up instances with a NAT and a private network, and running k8s in such a setup needs special handling in order to have full reachability. Also, I do appreciate your edit, but you skipped over the rest of my question: what troubleshooting have you already tried? other pods? Node-to-Node (not just Pod-to-Pod)? checking flannel logs?
newcomers avatar
vn flag
yes, I do run the Kubernetes k3s on a virtual machine, I don't use any vagrant or docker. Sorry, I don't get by mean troubleshooting that you mean. everything is working fine, pods are running, I can access them from everywhere. except ping or curl from or to the master node. my master node is ready, I can access pods from node to node. feel like my layer 7 is working but my layer 3 is not working. anyway I tried to check the flannel logs follow is command https://github.com/flannel-io/flannel/blob/master/Documentation/troubleshooting.md , but i don't get anything.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.