Nu se poate ajunge la mașina gazdă de la pod din clusterul kubernetes

Am 1 master și 1 lucrător cu configurarea cluster Kubernetes folosind kubeadm pe mediul de virtualizare Fedora Linux KVM cu interval pod cidr - 10.244.0.0/16. Folosirea politicii de rețea flanel.

Nod principal: nume de gazdă - fedkubemaster adresa ip - 192.168.122.161 Nod lucrat: numele gazdă - fedkubenode adresa ip - 192.168.122.27 (NOTĂ - FQDN-urile gazdei mele nu pot fi rezolvate prin DNS)

$ kubectl obține noduri -o lățime
NUME STARE ROLURI VÂRSTA VERSIUNE INTERN-IP EXTERN-IP OS-IMAGE KERNEL-VERSIUNE CONTAINER-RUNTIME
fedkubemaster Ready control-plane,master 2d20h v1.23.3 192.168.122.161 <niciunul> Fedora Linux 35 (Workstation Edition) 5.15.16-200.fc35.x86_64 docker://20.10.12
fedkubenode Ready <niciun> 2d6h v1.23.3 192.168.122.27 <niciun> Fedora Linux 35 (Workstation Edition) 5.15.16-200.fc35.x86_64 docker://20.10.12

Iată ruta mea de la nodul master, nodul lucrător

[admin@fedkubemaster ~]$ ruta -n
Tabelul de rutare IP kernel
Destination Gateway Genmask Flags Metric Ref Utilizare Iface
0.0.0.0 192.168.122.1 0.0.0.0 UG 100 0 0 enp1s0
10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flanel.1
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-25b1faebd814
192.168.122.0 0.0.0.0 255.255.255.0 U 100 0 0 enp1s0

[admin@fedkubenode ~]$ ruta -n
Tabelul de rutare IP kernel
Destination Gateway Genmask Flags Metric Ref Utilizare Iface
0.0.0.0 192.168.122.1 0.0.0.0 UG 100 0 0 enp1s0
10.244.0.0 10.244.0.0 255.255.255.0 UG 0 0 0 flanel.1
10.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.122.0 0.0.0.0 255.255.255.0 U 100 0 0 enp1s0

Folosesc această definiție dnsutil pod yml pentru a-mi testa conectivitatea la mașinile mele gazdă

apiVersion: v1
fel: Pod
metadate:
  nume: dnsutils
  spatiu de nume: implicit
specificație:
  containere:
  - nume: dnsutils
    imagine: k8s.gcr.io/e2e-test-images/jessie-dnsutils:1.3
    comanda:
      - dormi
      - „3600”
    imagePullPolicy: IfNotPresent
  restartPolicy: Întotdeauna

Iată ieșirea mea pentru adresa IP și ruta IP din interiorul podului dnsutils.

root@dnsutils:/# adresă ip
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP grup implicit 
    link/ether 7a:50:37:bc:4b:45 brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.2/24 brd 10.244.1.255 scope global eth0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
root@dnsutils:/# 
root@dnsutils:/# afișare rută ip
implicit prin 10.244.1.1 dev eth0 
10.244.0.0/16 prin 10.244.1.1 dev eth0 
10.244.1.0/24 dev eth0 proto kernel scope link src 10.244.1.2 

Încerc să fac o căutare nslookup și să ping la mașinile mele gazdă FQDN și nu se rezolvă. Apoi am încercat să fac ping cu adresa lor IP respectivă, în care nodul master arată ieșirea ca pachet filtrat și nodul lucrător este capabil să răspundă cu adresa IP.

root@dnsutils:/# nslookup fedkubemaster
;; conexiunea a expirat; niciun server nu a putut fi atins

root@dnsutils:/# nslookup fedkubenode  
;; conexiunea a expirat; niciun server nu a putut fi atins

root@dnsutils:/# ping fedkubemaster
ping: gazdă necunoscută fedkubemaster
root@dnsutils:/# ping fedkubenode  
ping: gazdă necunoscută fedkubenode

root@dnsutils:/# ping 192.168.122.161
PING 192.168.122.161 (192.168.122.161) 56(84) octeți de date.
De la 10.244.1.1 icmp_seq=1 Pachet filtrat
De la 10.244.1.1 icmp_seq=2 Pachetul filtrat
^C
--- 192.168.122.161 statistici ping ---
2 pachete transmise, 0 primite, +2 erori, 100% pierdere de pachete, timp 1013 ms

root@dnsutils:/# ping 192.168.122.27 
PING 192.168.122.27 (192.168.122.27) 56(84) octeți de date.
64 de octeți de la 192.168.122.27: icmp_seq=1 ttl=64 time=0,286 ms
64 de octeți de la 192.168.122.27: icmp_seq=2 ttl=64 time=0,145 ms

Problema este că vreau ca FQDN-ul mașinilor mele gazdă să poată fi rezolvat din Pod, dar nu pot înțelege cum îl pot remedia. Se pare că nu există nicio rută pentru a rezolva FQDN-ul meu gazdă din interiorul podului, care se reflectă și în jurnalele coredns. Aici este eroarea.

[admin@fedkubemaster networkutils]$ kubectl logs -f coredns-64897985d-8skq2 -n kube-system
.:53
[INFO] plugin/reîncărcare: rulează configurația MD5 = db32ca3650231d74073ff4cf814959a7
CoreDNS-1.8.6
linux/amd64, go1.17.1, 13a9191
[EROARE] plugin/erori: 2 2603559064493035223.1593267795798361043. HINFO: citiți udp 10.244.0.2:38440->192.168.122.1:53: citiți: nicio rută către gazdă
[EROARE] plugin/erori: 2 2603559064493035223.1593267795798361043. HINFO: citiți udp 10.244.0.2:34275->192.168.122.1:53: citiți: nicio rută către gazdă

Încerc să-mi dau seama dacă există oricum pot adăuga ruta la poduri în mod implicit, dar nu sunt atât de familiar cu ele pentru a o remedia.

Sugerați vă rog. Anunțați-mă dacă sunt necesare alte detalii.

Mulțumiri Sudhir

Am reușit să-mi rezolv problema dezactivând temporar serviciul firewall atât pe master cât și pe worker.

[admin@fedkubemaster ~]$ sudo systemctl stop firewalld.service
[admin@fedkubemaster ~]$ sudo systemctl dezactivează firewalld.service

[admin@fedkubenode ~]$ sudo systemctl stop firewalld.service
[admin@fedkubenode ~]$ sudo systemctl dezactivează firewalld.service

Dar lucrul pe care încă trebuie să îl înțeleg de ce, deși toate porturile necesare conform documentației kubernetes, au fost activate de ce a cauzat această problemă.