Kubernetes limitează numărul de reporniri simultane a podului pe întregul cluster

Avem un cluster Kubernetes cu 6 noduri care rulează aproximativ 20 de încărcături de lucru mari de set de replică (servicii Java). Fiecare pod de sarcină de lucru (1 pod per sarcină de lucru) durează în medie aproximativ 30 de secunde pentru a porni și a utiliza o mulțime de CPU. Acest lucru face ca pornirea mai multor pod-uri/încărcări de lucru în același timp să fie o problemă - până la punctul în care, atunci când 2 sau 3 pornesc în același timp pe același nod, durează câteva minute pentru a porni și în cele din urmă sunt uciși de sonda de pregătire. Sonda de pregătire este destul de relaxată, dar prelungirea timpului de grație la infinit nu pare a fi o practică bună.

După cum se poate imagina, acest lucru face problematică cordonarea și drenarea unui nod - dacă drenăm un nod, toate podurile repornesc în același timp în altă parte și îl putem supraîncărca un lucrător (sau îl pot opri, provocând reporniri multiple, care în cele din urmă duc la blocarea bazei de date ).

Pentru a ocoli acest lucru, am scris un script shell care folosește kubectl pentru a lista pod-urile, reporniți fiecare (prin corecția metadatelor), așteptați ca starea să devină disponibilă și treceți la următorul.

Scripturile funcționează bine pentru corecțiile serverului sau pentru upgrade-urile sarcinii de lucru, dar nu rezolvă problema unei întreruperi de nod - totul rulează în AWS și când un nod eșuează, se creează unul nou prin autoscaling, dar înseamnă că 4 poduri încearcă și repornesc în același timp ora (de obicei duminica dimineata la 3 dimineata desigur).

O idee ar fi să existe un container init care să fie conștient de celelalte încărcături de lucru de pornire - dacă nicio altă încărcătură de lucru nu pornește în prezent pe același nod, atunci containerul init se iese permițând containerului principal să pornească. Acest lucru ar necesita un cont de serviciu și permisiuni, dar ar putea fi o soluție, dar mă întrebam dacă există o modalitate mai standard de a face acest lucru prin configurare (reguli de afinitate etc.)?

Acesta este genul de problemă cu care se confruntă când podurile sunt programabile oriunde. Ești pe drumul cel bun cu regulile de afinitate.

Puteți face ca aceste poduri să-și exprime o anti-afinitate între ele, făcând ca podurile din cadrul unui set de replică al implementării să exprime afinitate negativă unul pentru celălalt (deci să se răspândească printre noduri). Acest lucru face programarea oarecum grea, dar reușește să împiedice pod-urile să provoace eșecuri în cascadă atunci când un nod este pierdut. De asemenea, face o treabă destul de bună de a se asigura că acestea sunt răspândite printre domeniile de eșec, dar acesta este mai mult un efect secundar.

Cu toate acestea, există o modalitate mai bună de a realiza acest lucru - prin constrângerile de răspândire a topologiei pod. Prin specificarea unei constrângeri de răspândire, planificatorul se va asigura că podurile sunt fie echilibrate între domeniile de eșec (fie ele AZ-uri sau noduri) și că eșecul de a echilibra pod-urile are ca rezultat o eșec de planificare.

S-ar putea scrie acest lucru într-un mod care să garanteze că podurile sunt distribuite între noduri și că o defecțiune a nodului nu va provoca „grupare”. Aruncă o privire la acest exemplu de pod:

fel: Pod
apiVersion: v1
metadate:
  nume: mypod
  etichete:
    foo: bar
specificație:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zonă
    când Nesatisfăcător: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: nod
    când Nesatisfăcător: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containere:
  - nume: pauză
    imagine: k8s.gcr.io/pause:3.1

Acest lucru poate fi combinat cu reguli de afinitate dacă, de asemenea, nu doriți ca implementările și seturile de replica ale acestora să fie programate cu alte implementări pe același nod, reducând și mai mult efectul de „grupare”. O anti-afinitate moale este de obicei adecvată într-un astfel de caz, astfel încât planificatorul va „încerca să nu” colocați acele sarcini de lucru atunci când este posibil.