Closed amshankaran closed 11 months ago
Hm, it does appear like Calico is selecting a different address.
Could you share the startup log output from the calico/node pod on that Node?
@amshankaran Any update on this? Could you share the log output?
Hi @sridhartigera, I have printed the Node object where I could see the Node object itself is having the VIP address as Node address instead of the InternalIP. Please find the below log. Whereas the node describe is showing the proper address. I'm redeploying the stack, I'll upload the complete log soon.
023-02-16 15:54:10.445 [INFO][9] startup/startup.go 485: Initialize BGP data
2023-02-16 15:54:10.445 [INFO][9] startup/autodetection_methods.go 171: ****PRINTING Node &Node{ObjectMeta:{capocluster-cp-4v875 d41
3ac0c-b0bb-46ef-999c-8c2f72c7ae2e 609 0 2023-02-16 15:52:24 +0000 UTC
calico-node.log @caseydavenport PFA calico-node pod log.
@amshankaran yeah, your log shows that it is picking up the IP provided by the Node object Addresses:[]NodeAddress{NodeAddress{Type:InternalIP,Address:10.0.100.6,},NodeAddress{Type:Hostname,Address:capocluster-cp-jlfxj,},}
as InternalIP
@tomastigera whereas, the node describe shows the Kubernetes nodes InternalIP as 10.0.0.1(expected), which is different than the Calicos node objects Internal IP(10.0.100.6). How this is possible?
Addresses: InternalIP: 10.0.0.1 Hostname: cp-tp888
@amshankaran Sorry for not responding earlier. Any development on this? What entiry has 10.0.100.6? Ar the logs from the same node? It does not seem like it is picking a random address from any device on that node :thinking:
@tomastigera IP 10.0.100.6 is in the same node for different interface (eth2 address). (It was 10.14.100.21 in my first message, I redeployed the stack and got 10.0.100.6 for eth2. Basically it is taking the eth2 address) kubernetes-internal-ip is 10.0.0.1, expecting this address for calico-node.
But from the above logs it is confirmed that Calico receives the Node's internal IP as Type:InternalIP,Address:10.0.100.6 while the node describe gives Addresses: InternalIP: 10.0.0.1
@amshankaran could you please change logSeverityScreen
in the default FelixConfig
to debug
and post the calico logs again? (https://docs.tigera.io/calico/latest/reference/resources/felixconfig for reference)
Also, could you post updated kubectl describe
of both the k8s node and calico-node corresponding to those logs?
It does seem like calico finds 10.0.100.6 as the InternalIP, can we make sure it wasn't the case at some point in time and that changed? Just trying to better understand how this issue came about...
On a more practical note, does your setup use a "predictable" interface for the node's IP? If so, IP_AUTODETECTION_METHOD=interface=eth0
or something similar might be a viable workaround...
ip_auto_detection set to "kubernetes-internal-ip" is not using the nodes (host) internal-ip, instead using another IP of the host, this causing the mesh failure
Expected Behavior
kubernetes_internal_ip should use the nodes InternalIP to form the calico mesh and as bind ip (BindMode is NodeIP)
Current Behavior
Below is the output describing the node. Where calico IPv4Address annotation is different and InternalIP of the node is not used.
Possible Solution
Steps to Reproduce (for bugs)
IP addresses of the Node
Describe output of the Pod
Context
calico mesh is not forming
Your Environment