Kubernetes-säiliöiden parhaat käytännöt: terveystarkastukset

TL; DR

• Säiliöiden ja mikropalvelujen korkean havaittavuuden saavuttamiseksi lokit ja ensisijaiset mittarit eivät riitä.
• Nopeamman palautumisen ja joustavuuden lisäämiseksi sovellusten tulee soveltaa High Observability Principle (HOP) -periaatetta.
• Sovellustasolla NOP edellyttää: asianmukaista kirjaamista, tarkkaa seurantaa, järkeviä tarkistuksia ja suorituskyvyn/siirtymän seurantaa.
• Käytä sekkejä NOR:n osana valmius Anturi и elävyyden koetin Kubernetes.

Mikä on terveystarkastusmalli?

Tehtäväkriittistä ja erittäin saatavilla olevaa sovellusta suunniteltaessa on erittäin tärkeää pohtia sellaista näkökohtaa kuin vikasietoisuus. Sovellusta pidetään vikasietoisena, jos se toipuu nopeasti epäonnistumisesta. Tyypillinen pilvisovellus käyttää mikropalveluarkkitehtuuria – jossa jokainen komponentti sijoitetaan erilliseen säiliöön. Ja varmistaaksesi, että k8s-sovellus on erittäin saatavilla, kun suunnittelet klusterin, sinun on noudatettava tiettyjä malleja. Niiden joukossa on Health Check Template. Se määrittää, kuinka sovellus viestii k8s:lle, että se on terve. Tämä ei ole vain tietoa siitä, onko pod käynnissä, vaan myös siitä, kuinka se vastaanottaa pyyntöjä ja vastaa niihin. Mitä enemmän Kubernetes tietää podin kunnosta, sitä älykkäämpiä päätöksiä se tekee liikenteen reitittämisestä ja kuormituksen tasapainotuksesta. Siten High Observability Principle mahdollistaa sovelluksen vastata pyyntöihin ajoissa.

High Observability Principle (HOP)

Korkean havaittavuuden periaate on yksi konttisovellusten suunnittelun periaatteet. Mikropalveluarkkitehtuurissa palvelut eivät välitä siitä, kuinka heidän pyyntönsä käsitellään (ja aivan oikein), vaan sillä on merkitystä, miten ne saavat vastaukset vastaanottavilta palveluilta. Esimerkiksi käyttäjän todentamiseksi yksi säilö lähettää HTTP-pyynnön toiselle odottaen vastausta tietyssä muodossa - siinä kaikki. PythonJS voi myös käsitellä pyynnön, ja Python Flask voi vastata. Säiliöt ovat kuin mustia laatikoita, joissa on piilotettu sisältö toisilleen. NOP-periaate edellyttää kuitenkin, että jokainen palvelu paljastaa useita API-päätepisteitä, jotka osoittavat sen terveellisyyden sekä sen valmiuden ja vikasietoisuuden. Kubernetes pyytää näitä indikaattoreita miettiäkseen reitityksen ja kuormituksen tasapainotuksen seuraavia vaiheita.

Hyvin suunniteltu pilvisovellus kirjaa tärkeimmät tapahtumansa käyttämällä tavallisia I/O-virtoja STDERR ja STDOUT. Seuraavaksi tulee apupalvelu, esimerkiksi filebeat, logstash tai fluentd, joka toimittaa lokit keskitettyyn valvontajärjestelmään (esim. Prometheus) ja lokinkeruujärjestelmään (ELK-ohjelmistopaketti). Alla oleva kaavio näyttää, kuinka pilvisovellus toimii Health Test Patternin ja High Observability -periaatteen mukaisesti.

Miten terveystarkastusmallia käytetään Kubernetesissa?

Pakkauksesta otettuna k8s tarkkailee podien tilaa käyttämällä yhtä ohjaimista (käyttöönottoja, ReplicaSets, DaemonSets, StatefulSets jne., jne.). Huomattuaan, että pod on jostain syystä pudonnut, ohjain yrittää käynnistää sen uudelleen tai siirtää sen toiseen solmuun. Pod voi kuitenkin ilmoittaa, että se on käynnissä, mutta se ei itse toimi. Otetaan esimerkki: sovelluksesi käyttää Apachea verkkopalvelimena, olet asentanut komponentin useisiin klusterin koteloihin. Koska kirjasto on määritetty väärin, kaikki sovelluksen pyynnöt vastaavat koodilla 500 (sisäinen palvelinvirhe). Toimitusta tarkasteltaessa palojen tilan tarkistaminen antaa onnistuneen tuloksen, mutta asiakkaat ajattelevat toisin. Kuvaamme tätä ei-toivottua tilannetta seuraavasti:

Esimerkissämme k8s tekee toimivuuden tarkistus. Tämän tyyppisessä varmentamisessa kubelet tarkistaa jatkuvasti prosessin tilan säiliössä. Kun hän ymmärtää, että prosessi on pysähtynyt, hän käynnistää sen uudelleen. Jos virhe voidaan ratkaista yksinkertaisesti käynnistämällä sovellus uudelleen ja ohjelma on suunniteltu sulkeutumaan virheiden sattuessa, prosessin kuntotarkistus on kaikki mitä tarvitset noudattaaksesi NOP:ta ja terveystestimallia. Harmi vain, että kaikki virheet eivät poistu käynnistämällä uudelleen. Tässä tapauksessa k8s tarjoaa kaksi syvempää tapaa tunnistaa pod-ongelmat: elävyyden koetin и valmius Anturi.

LivenessProbe

Aikana elävyyden koetin kubelet suorittaa kolmenlaisia ​​tarkistuksia: ei vain määritä, onko pod käynnissä, vaan myös onko se valmis vastaanottamaan pyyntöjä ja vastaamaan niihin riittävästi:

• Aseta HTTP-pyyntö podille. Vastauksen tulee sisältää HTTP-vastauskoodi välillä 200-399. Siten koodit 5xx ja 4xx osoittavat, että podissa on ongelmia, vaikka prosessi on käynnissä.
• Jos haluat testata podeja muilla kuin HTTP-palveluilla (esimerkiksi Postfix-sähköpostipalvelimella), sinun on muodostettava TCP-yhteys.
• Suorita mielivaltainen komento podille (sisäisesti). Tarkistus katsotaan onnistuneeksi, jos komennon suorituskoodi on 0.

Esimerkki siitä, miten tämä toimii. Seuraava pod-määrittely sisältää NodeJS-sovelluksen, joka antaa HTTP-pyynnöille 500-virheen. Varmistaaksemme, että säilö käynnistetään uudelleen tällaisen virheen saapuessa, käytämme livenessProbe-parametria:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

Tämä ei eroa muista pod-määrityksistä, mutta lisäämme objektin .spec.containers.livenessProbe... Parametri httpGet hyväksyy polun, johon HTTP GET -pyyntö lähetetään (esimerkissämme tämä on /, mutta taisteluskenaarioissa voi olla jotain sellaista /api/v1/status). Toinen livenessProbe hyväksyy parametrin initialDelaySeconds, joka käskee vahvistusta odottamaan tietyn määrän sekunteja. Viive on tarpeen, koska kontti tarvitsee aikaa käynnistyäkseen, ja uudelleenkäynnistettynä se ei ole käytettävissä jonkin aikaa.

Voit ottaa tämän asetuksen käyttöön klusterissa käyttämällä:

kubectl apply -f pod.yaml

Muutaman sekunnin kuluttua voit tarkistaa podin sisällön seuraavalla komennolla:

kubectl describe pods node500

Etsi tulosteen lopusta se mitä.

Kuten näette, livenessProbe aloitti HTTP GET -pyynnön, säilö loi virheen 500 (mikä se oli ohjelmoitu tekemään), ja kubelet käynnisti sen uudelleen.

Jos mietit, kuinka NideJS-sovellus ohjelmoitiin, tässä on käytetty app.js ja Dockerfile:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

Dockerfile

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

On tärkeää huomata tämä: livenessProbe käynnistää säilön uudelleen vain, jos se epäonnistuu. Jos uudelleenkäynnistys ei korjaa virhettä, joka estää säilön toiminnan, kubelet ei pysty korjaamaan ongelmaa.

valmius Anturi

ReadinessProbe toimii samalla tavalla kuin livenessProbes (GET-pyynnöt, TCP-viestintä ja komentojen suoritus), vianmääritystoimintoja lukuun ottamatta. Säilöä, jossa vika havaitaan, ei käynnistetä uudelleen, vaan se eristetään saapuvasta liikenteestä. Kuvittele, että yksi säiliöistä suorittaa paljon laskutoimituksia tai on raskaan kuormituksen alaisena, mikä saa vasteajat pidentymään. LivenessProben tapauksessa vastauksen saatavuuden tarkistus käynnistyy (timeoutSeconds-tarkistusparametrin kautta), jonka jälkeen kubelet käynnistää säilön uudelleen. Kun säilö käynnistetään, se alkaa suorittaa resurssiintensiivisiä tehtäviä ja käynnistetään uudelleen. Tämä voi olla kriittistä sovelluksille, jotka tarvitsevat vastenopeutta. Esimerkiksi auto tien päällä odottaa vastausta palvelimelta, vastaus viivästyy - ja auto joutuu onnettomuuteen.

Kirjoitetaan redinessProbe-määritelmä, joka asettaa GET-pyynnön vastausajaksi korkeintaan kaksi sekuntia ja sovellus vastaa GET-pyyntöön 5 sekunnin kuluttua. Pod.yaml-tiedoston pitäisi näyttää tältä:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

Otetaan käyttöön pod kubectl:llä:

kubectl apply -f pod.yaml

Odotetaan pari sekuntia ja katsotaan sitten, kuinka ReadinessProbe toimi:

kubectl describe pods nodedelayed

Tulosteen lopussa näet, että jotkut tapahtumat ovat samanlaisia nyt tämä.

Kuten näet, kubectl ei käynnistänyt podia uudelleen, kun tarkistusaika ylitti 2 sekuntia. Sen sijaan hän peruutti pyynnön. Saapuvat viestit ohjataan muihin, toimiviin podeihin.

Huomaa, että nyt, kun pod on purettu, kubectl reitittää pyynnöt siihen uudelleen: vastaukset GET-pyyntöihin eivät enää viivästy.

Vertailun vuoksi alla on muokattu app.js-tiedosto:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; DR
Ennen pilvisovellusten tuloa lokit olivat ensisijainen tapa seurata ja tarkistaa sovellusten kunto. Ei kuitenkaan ollut keinoja ryhtyä korjaaviin toimiin. Lokit ovat hyödyllisiä tänäkin päivänä, ne täytyy kerätä ja lähettää lokinkeräysjärjestelmään hätätilanteiden analysointia ja päätösten tekemistä varten. [Kaikki tämä onnistui ilman pilvisovelluksia esimerkiksi monitin avulla, mutta k8s:lla siitä tuli paljon helpompaa :) – toimittajan huomautus. ]

Nykyään korjaukset on tehtävä lähes reaaliajassa, joten sovellusten ei enää tarvitse olla mustia laatikoita. Ei, niiden pitäisi näyttää päätepisteitä, joiden avulla valvontajärjestelmät voivat kysyä ja kerätä arvokasta tietoa prosessien tilasta, jotta ne voivat vastata välittömästi tarvittaessa. Tätä kutsutaan suorituskykytestin suunnittelumalliksi, joka noudattaa High Observability Principle (HOP) -periaatetta.

Kubernetes tarjoaa oletuksena kahdenlaisia ​​terveystarkastuksia: ReadinessProbe ja livenessProbe. Molemmat käyttävät samantyyppisiä tarkistuksia (HTTP GET -pyynnöt, TCP-viestintä ja komennon suoritus). Ne eroavat toisistaan ​​siinä, mitä päätöksiä he tekevät vastauksena paloissa esiintyviin ongelmiin. livenessProbe käynnistää säilön uudelleen siinä toivossa, että virhe ei toistu, ja ReadinessProbe eristää podin saapuvasta liikenteestä, kunnes ongelman syy on ratkaistu.

Oikean sovelluksen suunnittelun tulee sisältää molemmat tarkastukset ja varmistaa, että ne keräävät riittävästi tietoa, varsinkin kun tehdään poikkeus. Sen pitäisi myös näyttää tarvittavat API-päätepisteet, jotka tarjoavat seurantajärjestelmälle (Prometheus) tärkeitä terveysmittareita.

Lähde: will.com