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
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 (
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:
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
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
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