Probleme DNS pe grupul de noduri doar cu preempțiune pe GKE: punctele finale ale serviciului kube-dns păstrează poduri eșuate

Am un cluster GKE k8s (k8s 1.22) care constă din noduri preemptibile numai, care include servicii critice precum kube-dns. Este o mașină de dezvoltare care poate tolera câteva minute întrerupte pe zi. De fiecare dată când se închide un nod care găzduiește un pod kube-dns, mă confrunt cu probleme de rezoluție DNS care persistă până când șterg podul eșuat (în 1.21, podurile rămân „Stare: Eșuat” / „Motiv: Închidere” până când sunt șterse manual) .

Deși mă aștept la unele probleme la nodurile preemptibile în timp ce sunt reciclate, m-aș aștepta să se repare automat după câteva minute. Motivul de bază al problemelor persistente pare să fie că podul eșuat nu este îndepărtat din k8s Serviciu / Punct final. Iată ce pot vedea în sistem:

Starea păstăilor prin kubectl -n kube-system get po -l k8s-app=kube-dns

STAREA NUMELE GATA REINCEPE VARSTA
kube-dns-697dc8fc8b-47rxd 4/4 Terminat 0 43h
kube-dns-697dc8fc8b-mkfrp 4/4 Alergare 0 78m
kube-dns-697dc8fc8b-zfvn8 4/4 Running 0 19h

IP-ul podului eșuat este 192.168.144.2 - și încă este listat ca unul dintre punctele finale ale serviciului:

kubectl -n kube-system descrie ep kube-dns aduce asta:

Nume: kube-dns
Spațiu de nume: kube-system
Etichete: addonmanager.kubernetes.io/mode=Reconciliere
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
              kubernetes.io/name=KubeDNS
Adnotări: endpoints.kubernetes.io/last-change-trigger-time: 2022-02-21T10:15:54Z
Subseturi:
  Adrese: 192.168.144.2,192.168.144.7,192.168.146.29
  NotReadyAddresses: <niciuna>
  Porturi:
    Nume Port Protocol
    ---- ---- --------
    dns-tcp 53 TCP
    dns 53 UDP

Evenimente: <niciunul>

Știu că alții au rezolvat aceste probleme Programarea kube-dns la alte poduri, dar aș dori mai degrabă să fac această auto-vindecare, deoarece eșecurile nodurilor se pot întâmpla în continuare pe nodurile nepreemptibile, sunt doar mai puțin probabile.

Intrebarile mele:

• De ce podul eșuat este încă listat ca unul dintre punctele finale ale serviciului, chiar și la câteva ore după defecțiunea inițială a nodului?
• Ce pot face pentru a atenua problema (pe lângă adăugarea unor noduri non-efemere)?

Se pare că kube-dns în implementarea implicită în GKE nu are o sondă de pregătire atașată la dnsmasq (portul 53), care este vizată în serviciul kube-dns, și că dacă aceasta ar putea rezolva problema - dar bănuiesc că nu este acolo dintr-un motiv pe care încă nu îl înțeleg.

EDIT: Se pare că asta da nu se întâmplă pe 1.21.6-gke.1500 (canal obișnuit), dar se întâmplă pe 1.22.6-gke.1500 (canal rapid). Nu am o explicație bună, dar, în ciuda faptului că am câteva pod-uri eșuate astăzi, serviciul kube-dns le conține doar pe cele funcționale.

Nodurile preemptibile nu sunt recomandate pentru rularea sarcinilor de lucru critice, cum ar fi kube-dns (1) deci sunt de așteptat situații ca aceasta.

Puteți încerca să atenuați problema marcând pod ca critic (2), folosind furnizarea automată a nodului (3) sau PodDisruptionBudget (4).
Există mai multe informații despre acest subiect în acest document (5).

În plus, unele sugestii au fost deja făcute către Google (6).

Dacă niciuna dintre acestea nu vă rezolvă problema, puteți raporta aceasta prin Urmărirea problemelor publice.

A început să se întâmple și pe env-ul meu (noduri preemptibile pe gke) și se întâmplă cu toate implementările, dar kube-dns este cel mai critic. Cred că ar putea avea legătură cu revisionHistoryLimit parametru. Valoarea implicită este 10, astfel încât replicile vechi de până la un număr de 10 vor fi prezente pentru o anumită perioadă de timp. L-am setat la 0 și mă aștept ca nodurile să fie înlocuite, să vedem :)