https://jira.akraino.org This file is an XML representation of an issue en-us 9.4.5 940005 11-04-2023 https://jira.akraino.org/browse/ICN-615 Integrated Cloud Native NFV <p>The Nodus is the primary CNI. </p> <ul> <li>When the POD subnet and the ovn-controller-network configmap are set to 10.244.0.0/16, the DNS lookup fails with the following error messages,</li> </ul> <p>$ kubectl exec -it dnsutils &#8211; nslookup kubernetes.default</p> <p>;; reply from unexpected source: 10.244.0.3#53, expected 10.96.0.10#53</p> <p>;; reply from unexpected source: 10.244.0.3#53, expected 10.96.0.10#53</p> <p>;; reply from unexpected source: 10.244.0.3#53, expected 10.96.0.10#53</p> <p>;; connection timed out; no servers could be reached</p> <ul> <li>But when the POD subnet  and the ovn-controller-network are set to 10.158.142.0/18 (the default value configured in the ovn-controller-network, the dns seems to work fine</li> </ul> <p>$ kubectl exec -it dnsutils &#8211; nslookup kubernetes.default</p> <p>Server:         10.96.0.10</p> <p>Address:        10.96.0.10#53</p> <p> </p> <p>Name:   kubernetes.default.svc.cluster.local</p> <p>Address: 10.96.0.1</p> <ul> <li> But even in the second case above (where the DNS works fine) the emco-monitor errors out and getting restarted continuously on a multi-node cluster. Whereas it works fine in the single node cluster.</li> </ul> <p>Is there any network configuration missing in the host?</p> <p> </p> ICN-615

NS Lookup Failure when Nodus is a Primary CNI

Bug High To Do Unresolved Kuralamudhan Ramakrishnan Palaniappan Ram Thu, 28 Oct 2021 16:31:58 +0000 Sat, 6 Nov 2021 16:46:25 +0000 0 3 <p>Just to ensure that there are no stale files causing the issue, is it possible to create fresh VMs and try installing K8s on top of it.</p> <p>When switching the podCIDR, I removed the kubernetes with </p> <p>kubeadm reset -f</p> <p>iptables -F</p> <p>iptables -X</p> <p>before reinstallation, on all the nodes. </p> <p>There may still be stale config files in the host which need to be removed.</p> <p>We have to do kubeadm reset and IPtable flush, when we change the pod network subnet changes in the kubeadm control plane to clean the setup IPtables already assigned service IP with pod network cidr range. </p> <p>I don't think there is hardcoding on these, we have made them as configmap. But there could be case where the ovn resource is pointing to 10.158.142.0/18 even after changing the 10.244.0.0/16 and restarting the nfn plugins. I delete all the ovn resource including nfn plugins and ovn-daemoenset and ovnfolder before changing the subnet. I think, I should document these and add them in deletion hooks when deleting the containers. But, we have to debug the Palani setup to understand more on this issue.</p> <p>Some hardcoding somewhere?</p> <p>I see some issue with way the subnet changes happening here. we have to delete the ovn resource before changing the subnet. </p> <p>Subnet change should not cause issue dns. Some steps is missing in this case. Let debug today on this.  </p> Development Rank 0|i005mk: