Hajautettuja järjestelmiä voi olla vaikea hallita, koska niissä on monia liikkuvia, muuttuvia elementtejä, joiden kaikkien on toimittava kunnolla, jotta järjestelmä toimisi. Jos jokin elementeistä epäonnistuu, järjestelmän on havaittava se, ohitettava se ja korjattava se, ja kaikki tämä on tehtävä automaattisesti. Tässä Kubernetes Best Practices -sarjassa opimme määrittämään valmius- ja elävyystestejä Kubernetes-klusterin kunnon testaamiseksi.
Terveystarkastus on yksinkertainen tapa ilmoittaa järjestelmälle, onko sovellusesiintymä käynnissä vai ei. Jos sovellusesiintymäsi on poissa käytöstä, muiden palveluiden ei pitäisi käyttää sitä tai lähettää siihen pyyntöjä. Sen sijaan pyyntö on lähetettävä sovelluksen toiseen esiintymään, joka on jo käynnissä tai käynnistetään myöhemmin. Lisäksi järjestelmän pitäisi palauttaa sovelluksesi kadonneet toiminnot.
Oletusarvoisesti Kubernetes alkaa lähettää liikennettä podille, kun kaikki podien sisällä olevat säilöt ovat käynnissä, ja käynnistää säilöt uudelleen, kun ne kaatuvat. Tämä järjestelmän oletuskäyttäytyminen voi olla riittävän hyvä aluksi, mutta voit parantaa tuotteesi käyttöönoton luotettavuutta käyttämällä mukautettuja mielenterveystarkastuksia.
Onneksi Kubernetes tekee tämän melko helpoksi, joten ei ole mitään tekosyytä sivuuttaa näitä tarkistuksia. Kubernetes tarjoaa kahdenlaisia terveystarkastuksia, ja on tärkeää ymmärtää erot kummankin käytössä.
Valmiustesti on suunniteltu kertomaan Kubernetesille, että sovelluksesi on valmis käsittelemään liikennettä. Ennen kuin palvelun sallii lähettää liikennettä podiin, Kubernetesin on varmistettava, että valmiustarkastus on onnistunut. Jos valmiustesti epäonnistuu, Kubernetes lopettaa liikenteen lähettämisen podille, kunnes testi läpäisee.
Elävyystesti kertoo Kubernetesille, onko sovelluksesi elossa vai kuollut. Ensimmäisessä tapauksessa Kubernetes jättää sen rauhaan, toisessa se poistaa kuolleen kotelon ja korvaa sen uudella.
Kuvitellaan skenaario, jossa sovelluksesi lämpeneminen ja käynnistäminen kestää 1 minuutin. Palvelusi ei käynnisty ennen kuin sovellus on täysin ladattu ja käynnissä, vaikka työnkulku on jo alkanut. Sinulla on myös ongelmia, jos haluat skaalata tämän käyttöönoton useiksi kopioiksi, koska näiden kopioiden ei pitäisi vastaanottaa liikennettä ennen kuin ne ovat täysin valmiita. Oletusarvoisesti Kubernetes alkaa kuitenkin lähettää liikennettä heti, kun säilön sisällä olevat prosessit alkavat.
Valmiustestiä käytettäessä Kubernetes odottaa, kunnes sovellus on täysin käynnissä, ennen kuin sallii palvelun lähettää liikennettä uuteen kopioon.
Kuvitellaan toinen skenaario, jossa sovellus jumiutuu pitkään ja lopettaa huoltopyyntöjen. Prosessin jatkuessa oletuksena Kubernetes olettaa, että kaikki on kunnossa ja jatkaa pyyntöjen lähettämistä ei-toimivaan podiin. Mutta kun käytät Livenessia, Kubernetes havaitsee, että sovellus ei enää palvele pyyntöjä, ja käynnistää oletuksena kuolleen podin uudelleen.
Katsotaanpa, kuinka valmiutta ja elinkelpoisuutta testataan. Testausmenetelmiä on kolme - HTTP, Command ja TCP. Voit käyttää mitä tahansa niistä tarkistaaksesi. Yleisin tapa testata käyttäjää on HTTP-anturi.
Vaikka sovelluksesi ei olisi HTTP-palvelin, voit silti luoda kevyen HTTP-palvelimen sovellukseesi, jotta se on vuorovaikutuksessa Liveness-testin kanssa. Tämän jälkeen Kubernetes alkaa pingata podia, ja jos HTTP-vastaus on 200 tai 300 ms alueella, se osoittaa, että pod on terve. Muussa tapauksessa moduuli merkitään "epäterveeksi".
Komentotestejä varten Kubernetes suorittaa komennon säilön sisällä. Jos komento palaa nollalla poistumiskoodilla, kontti merkitään terveeksi, muuten kontti merkitään "sairas" saatuaan poistumistilanumeron 1 - 255. Tämä testausmenetelmä on hyödyllinen, jos et voi tai halua käyttää HTTP-palvelinta, mutta pystyt suorittamaan komennon, joka tarkistaa sovelluksesi kunnon.
Lopullinen varmennusmekanismi on TCP-testi. Kubernetes yrittää muodostaa TCP-yhteyden määritettyyn porttiin. Jos tämä voidaan tehdä, säiliö katsotaan terveeksi, jos ei, se katsotaan käyttökelvottomaksi. Tämä menetelmä voi olla hyödyllinen, jos käytät tilannetta, jossa testaus HTTP-pyynnöllä tai komennon suorittamisella ei toimi kovin hyvin. Esimerkiksi tärkeimmät palvelut TCP:tä käyttävään varmennukseen olisivat gRPC tai FTP.
Testejä voidaan konfiguroida useilla tavoilla eri parametreilla. Voit määrittää, kuinka usein ne tulee suorittaa, mitkä ovat onnistumisen ja epäonnistumisen kynnykset ja kuinka kauan vastauksia tulee odottaa. Lisätietoja on valmius- ja elävyystestien dokumentaatiossa. Elävyystestin asettamisessa on kuitenkin yksi erittäin tärkeä kohta - testausviiveen inicialDelaySeconds alkuasetus. Kuten mainitsin, tämän testin epäonnistuminen johtaa moduulin uudelleenkäynnistykseen. Joten sinun on varmistettava, että testaus ei käynnisty ennen kuin sovellus on valmis käytettäväksi, muuten se alkaa kierrellä uudelleenkäynnistyksiä. Suosittelen käyttämään P99-käynnistysaikaa tai sovelluksen keskimääräistä käynnistysaikaa puskurista. Muista säätää tätä arvoa, kun sovelluksesi käynnistysaika nopeutuu tai hidastuu.
Useimmat asiantuntijat vahvistavat, että terveystarkastukset ovat pakollinen tarkistus kaikille hajautetuille järjestelmille, eikä Kubernetes ole poikkeus. Palvelun kuntotarkastusten käyttäminen varmistaa Kubernetesin luotettavan, ongelmattoman toiminnan ja on vaivatonta käyttäjille.
Jatkuu pian...
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com