Krátke výpadky pri nasadení: nechajte požiadavky dobehnúť
Nová verzia funguje, ale počas výmeny procesov klienti dostávajú chyby. Ako zosúladiť pripravenosť, smerovanie prevádzky a riadené vypnutie.
Nasadenie sa dokončí úspešne, no v jeho priebehu klientom zlyhá niekoľko požiadaviek. Pri hľadaní príčiny skontrolujte aj spôsob vypínania starej verzie. Proces môže skončiť skôr, než dokončí odpoveď alebo než sa zmena smerovania prejaví na celej ceste. Riadené vypnutie, často označované ako graceful shutdown, má rozpracovanej práci poskytnúť čas na dokončenie. Konkrétne príklady nižšie používajú Kubernetes a HTTP server v Node.js na Linuxe.
Najprv overte, kedy nová verzia prijíma prevádzku
V Kubernetes readiness probe určuje, či je kontajner pripravený prijímať prevádzku. Nastavte ju tak, aby nová verzia prešla kontrolou až po inicializácii potrebnej na obsluhu požiadaviek. Startup probe môže počas pomalého štartu odložiť ostatné kontroly. Samotný bežiaci proces vám ešte neposkytne dostatočný podklad na presmerovanie klientov.
Pri RollingUpdate preskúmajte maxUnavailable, ktoré obmedzuje nedostupné pody, a maxSurge, ktoré povoľuje pody navyše. Pre súbeh verzií potrebujete kapacitu. Tieto nastavenia však samy nevyriešia dokončenie už prijatých požiadaviek. V časovej osi nasadenia sledujte pripravenosť novej verzie aj ukončovanie starej.
Oddeľte zmenu smerovania od konca procesu
EndpointSlice v Kubernetes rozlišuje stavy ready, serving a terminating. Bežné smerovanie spravidla vynecháva ukončované endpointy; pri všetkých ukončovaných endpointoch existuje výnimka. Používate aj ingress alebo externý load balancer? Overte jeho správanie pri ukončení backendu. Zo zmeny jedného stavu nevyvodzujte, že všetky vrstvy už prestali posielať nové požiadavky.
Pri vypnutí nechajte rozpracované odpovede dobehnúť, až potom uzatvárajte zdroje, ktoré potrebujú. Zaznamenajte čas začiatku vypínania, počet aktívnych požiadaviek a čas ich dokončenia. Ak proces stále prijíma novú prácu, zistite, z ktorej vrstvy prichádza. Náhodne predlžovaná pauza vám tento rozdiel nevysvetlí.
Dajte aplikácii vlastný postup vypnutia
V Node.js na Linuxe inštalácia obsluhy SIGTERM odstráni predvolené ukončenie po tomto signále. Aplikácia preto musí zabezpečiť aj dokončenie vypnutia. Pre HTTP/1 server v Node.js 19 a novšom server.close() zastaví prijímanie nových spojení a uzavrie neaktívne spojenia. Dokončenie uzatvárania overte cez callback; nespoliehajte sa len na zavolanie metódy.
Metóda server.closeAllConnections() násilne uzavrie aj aktívne HTTP spojenia a sama neukončuje spojenia prepnuté na WebSocket. Pre dlhé odpovede, WebSocket a prácu na pozadí pripravte príslušný postup s konečnou lehotou. Neuzatvárajte databázový pool, kým ho dokončovaná práca ešte používa. Log má rozlíšiť dokončenie od prerušenia po vyčerpaní lehoty.
Overte celý časový rozpočet pod záťažou
V Kubernetes sa preStop vykoná pred odoslaním ukončovacieho signálu a spotrebúva tú istú lehotu terminationGracePeriodSeconds ako vypínanie kontajnera. Predvolená lehota je 30 sekúnd; jej vyčerpanie môže viesť k SIGKILL. Overte aj prípadný vlastný stop signál. Čas na hook, dobehnutie požiadaviek a uzatvorenie zdrojov posudzujte spoločne.
V oddelenom prostredí spustite súvislú prevádzku cez rovnakú cestu ako klienti a počas nej nasaďte novú verziu. Zahrňte dlhšiu odpoveď aj pomalší štart. Zmerajte chyby, prerušené spojenia a čas vypnutia. Potom skúste rovnaký postup pri návrate na predchádzajúcu verziu. Úspech nasadzovacieho príkazu porovnajte s výsledkom klientskych požiadaviek.
- Overte pripravenosť novej verzie pred prijatím prevádzky.
- Skontrolujte smerovanie pri ukončení backendu.
- Sledujte dobehnutie požiadaviek a uzatvorenie zdrojov.
- Otestujte nasadenie aj návrat počas súvislej záťaže.
Čo si odniesť
Pri krátkych výpadkoch počas nasadenia porovnajte tri časy: pripravenosť novej verzie, zmenu smerovania a koniec starej verzie. Postup overte z pohľadu klienta a podľa nameraného priebehu nastavte lehotu vypnutia.
