pod-urile din kubernetes nu pot comunica cu alte pod-uri și gazdele din afara clusterului

Am 2 noduri master și 3 noduri de lucru și un proxy HA pentru controlePlan, Am multe microservicii java care comunică împreună și comunică cu DB sau KAFKA în afara clusterului kubernetes. accesul la rețea este oricare pentru orice deschis în toate gazdele. Creez implementare pentru fiecare microserviciu. Dar când execut la container, nu am conexiune tcp pe porturile dintre pod-uri și DB sau KAFKA în afara clusterului kubernetes.

de la gazde am telnet la DB sau KAFKA Dar in containere nu acces.

de la gazde:

[root@master1 ~]# telnet oracle.local 1521
Încercând 192.198.10.30...
Conectat la oracle.local.
Caracterul de evacuare este „^]”.
^C^CConexiune închisă de gazda străină.
[root@master1 ~]#

de la pod, de exemplu, busybux:

[root@master1 ~]# kubectl run -i --tty busybox --image=busybox --restart=Never -- sh
Dacă nu vedeți un prompt de comandă, încercați să apăsați pe Enter.
/ # telnet 192.168.10.30 1521
telnet: nu se poate conecta la gazda la distanță (192.168.10.30): conexiune a expirat

starea clusterului:

[root@master1 ~]# kubectl obține noduri -o lățime
NUME STARE ROLURI VÂRSTA VERSIUNE INTERN-IP EXTERN-IP OS-IMAGE KERNEL-VERSIUNE CONTAINER-RUNTIME
master1.project.co Control-plane gata, master 11d v1.22.2 192.168.10.1 <niciunul> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
master2.project.co Ready control-plane,master 11d v1.22.2 192.168.10.2 <niciunul> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker1.project.co Gata <niciun> 11d v1.22.2 192.168.10.3 <niciun> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker2.project.co Gata <niciun> 11d v1.22.2 192.168.10.4 <niciun> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9
worker3.project.co Gata <niciun> 11d v1.22.2 192.168.10.5 <niciun> Oracle Linux Server 8.3 5.4.17-2011.7.4.el8uek.x86_64 containerd://1.4.9

descrieți pod busybox:

[root@master1 ~]# kubectl descriu pod busybox
Nume: busybox
Spațiu de nume: implicit
Prioritate: 0
Nod: worker3.project.co/192.168.10.5
Ora de începere: Sâmbătă, 02 Oct 2021 10:27:05 +0330
Etichete: run=busybox
Adnotări: cni.projectcalico.org/containerID: 75d7222e8f402c68d9161a7b399df2de6b45e7194b2bb3b0b2730adbdac680c4
              cni.projectcalico.org/podIP: 192.168.205.76/32
              cni.projectcalico.org/podIPs: 192.168.205.76/32
Stare: în așteptare
IP:
IP-uri: <niciunul>
Containere:
  busybox:
    ID container:
    Imagine: busybox
    ID imagine:
    Port: <niciun>
    Port gazdă: <niciun>
    Argumente:
      SH
    Stare: În așteptare
      Motiv: ContainerCreating
    Gata: Fals
    Număr de reporniri: 0
    Mediu: <niciun>
    Suporturi:
      /var/run/secrets/kubernetes.io/serviceaccount de la kube-api-access-69snv (ro)
Conditii:
  Tastați Stare
  Adevărat inițializat
  Gata Fals
  ContainersReady False
  PodScheduled Adevărat
Volume:
  kube-api-access-69snv:
    Tip: Proiectat (un volum care conține date injectate din mai multe surse)
    TokenExpirationSeconds: 3607
    ConfigMapName: kube-root-ca.crt
    ConfigMapOptional: <nil>
    DownwardAPI: adevărat
Clasa QoS: BestEffort
Selectori de noduri: <niciunul>
Tolerări: node.kubernetes.io/not-ready:NoExecute op=Există pentru 300 de secunde
                             node.kubernetes.io/unreachable:NoExecute op=Există timp de 300 de secunde
Evenimente:
  Introduceți Motivul Vârsta din mesaj
  ---- ------ ---- ---- -------
  Programator normal de 21 de secunde Alocat cu succes default/busybox la worker3.project.co
  Normal Tragere 20s kubelet Tragere imagine „busybox”

O serie de motive pot fi cauza acestui lucru. Fără o perspectivă adecvată asupra cluster-ului și arhitecturii de rețea, acest lucru nu va fi rezolvat, totuși, iată câteva idei:

1. Verificați dacă există Politici de rețea aplicate prin executare kubectl -n <namespace> obține netpol. NetworkPolicies poate restricționa comunicarea în interiorul și în exteriorul clusterului.
2. Lasă un Pod să ruleze cu hostNetwork: adevărat opțiune (nu de făcut în producție, doar ca test) și încercați din nou câteva teste de conectivitate (în ambele direcții).
3. Verificați dacă rețeaua clusterului dvs. este configurată corect prin urmărirea unui apel de rețea. Routerele sunt configurate corect și pot fi utilizate de aplicațiile din cluster?
4. Verificați dacă dvs accesul la rețea este oricare pentru orice deschis în toate gazdele afirmația este adevărată, poate fi o problemă cu configurațiile firewall.

Primă: Se pare că aveți doar 2 noduri master, ceea ce are nu are deloc sens dacă etcd rulează în clusterul Kubernetes (kubectl -n kube-system obține pods | grep etcd va afișa 2 păstăi dacă acesta este cazul). A avea 2 membri etcd vă oferă exact aceeași toleranță la eșec ca un cluster cu 1 nod, dar ați irosit resurse pentru a avea un alt VM care ocupă memorie, CPU etc.. Luați în considerare creșterea nodurilor master la 3 pentru a avea o toleranță la eșec de unul. Trebuie să existe întotdeauna majoritatea a clusterului etcd care rulează. Rețineți că majoritatea celor 2 sunt încă 2.