înregistrare Logare
Puncte:1
Philippe Hebert avatar Server

Cum se gestionează cererea în curs când se aplică actualizarea continuă?

drapel jp
Philippe Hebert

Având în vedere un set de servere web care fac obiectul actualizării continue, cum ar fi prin intermediul actualizărilor automate Kubernetes, dacă o solicitare este emisă unui astfel de server web în așteptare de terminare cu milisecunde înainte ca un semnal SIGTERM să fie emis către serverul web menționat,

  1. Ar trebui serverul să semnaleze clientului că este SIGTERM și să îi spună clientului să „încerce din nou” folosind o adresă de rețea diferită (sau aceeași) (cu o potențială întârziere)?
  2. Altfel, ar putea serverul să redirecționeze automat cererea către un alt pod/instanță a serverului web care a fost deja acumulat?
  3. În cazul specific al kubernetes, cererea ar putea fi trimisă înapoi la serviciu și anunțat-o să o trimită înapoi odată ce cel puțin unul dintre pod-uri a fost lansat?
39
0 + 0
Puncte:2
avatar Server
drapel jp
AlexD

Când un pod se termină, are ceva timp (în mod implicit 30 de secunde) pentru a finaliza solicitarea atunci când o primește SIGTERM și înainte de a ajunge SIGKILL. Puteți configura timeout-uri mai lungi. Există deasemenea preStop cârlig este numit înainte SIGTERM este trimis la un pod. Vedea Cele mai bune practici Kubernetes: încheierea cu grație postare pe blog pentru detalii.

Alternativ, puteți configura echilibratoarele de încărcare pentru a reîncerca cererile eșuate, dar acest lucru funcționează numai pentru cererile idempotente.

0 + 0
Philippe Hebert avatar
drapel jp
Philippe Hebert
Mulțumesc pentru răspuns, @AlexD! Am știut că activitatea de intrare în rețea este oprită cu `terminationGracePeriodSeconds` secunde înainte de emiterea lui `SIGTERM`, care este implicit `30s`. Acest lucru acoperă într-adevăr majoritatea cazurilor de utilizare, deoarece este cu adevărat rar să aveți cereri mai lungi de `30s`. Acestea fiind spuse, în cazul în care cererea este o cerere de lungă durată și nu se poate rezolva în acest interval de timp, care ați sugera să fie strategia? Puteți presupune că cererea este delimitată de o tranzacție / este impotentă atunci când este returnată mai devreme.
0
Răspunde
drapel jp
AlexD
@PhilippeHebert chiar depinde. Care este costul nereușirii cererii? Ce opțiuni avem pentru a reîncerca această solicitare? Cât timp putem amâna cererea și care este costul întârzierii finalizării cu succes a cererii? Prea multe variabile.
0
Răspunde
Philippe Hebert avatar
drapel jp
Philippe Hebert
Acestea sunt întrebări foarte relevante; Vă sugerez să le adăugați ca parte a răspunsului dvs., alături de „Este cererea idempotentă?”. Pentru a fi complet, dacă tratarea acestor solicitări poate fi clasificată în câteva abordări, aș sugera, de asemenea, să descriem și aceste abordări.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.