Praktik Paling Apik kanggo Wadah Kubernetes: Priksa Kesehatan

TL; DR

• Kanggo nggayuh kontaner lan layanan mikro sing dhuwur, log lan metrik utami ora cukup.
• Kanggo pemulihan sing luwih cepet lan tambah daya tahan, aplikasi kudu ngetrapake Prinsip Pengamatan Tinggi (HOP).
• Ing tingkat aplikasi, NOP mbutuhake: logging sing tepat, ngawasi sing cedhak, mriksa kewarasan, lan nelusuri kinerja/transisi.
• Gunakake mriksa minangka unsur NOR kesiapanProbe и livenessProbe Kubernetes.

Apa Cithakan Priksa Kesehatan?

Nalika ngrancang aplikasi sing kritis lan kasedhiya banget, penting banget kanggo mikir babagan aspek kayata toleransi kesalahan. Aplikasi dianggep fault tolerant yen cepet pulih saka gagal. Aplikasi maya khas nggunakake arsitektur microservices - ing ngendi saben komponen diselehake ing wadhah sing kapisah. Lan kanggo mesthekake yen aplikasi ing k8s kasedhiya banget nalika sampeyan ngrancang kluster, sampeyan kudu ngetutake pola tartamtu. Ing antarane yaiku Cithakan Priksa Kesehatan. Iku nemtokake cara aplikasi komunikasi kanggo k8s sing sehat. Iki ora mung informasi babagan apa pod mlaku, nanging uga babagan cara nampa lan nanggapi panjaluk. Luwih akeh Kubernetes ngerti babagan kesehatan pod, keputusan sing luwih cerdas babagan rute lalu lintas lan imbangan muatan. Mangkono, Prinsip Pengamatan Dhuwur ngidini aplikasi nanggapi panjaluk kanthi pas wektune.

Prinsip Pengamatan Tinggi (HOP)

Prinsip observasi dhuwur minangka salah sawijining prinsip kanggo ngrancang aplikasi containerized. Ing arsitektur microservices, layanan ora preduli carane panjalukane diproses (lan bener), nanging sing penting yaiku carane nampa respon saka layanan sing nampa. Contone, kanggo otentikasi pangguna, siji wadhah ngirim panjalukan HTTP menyang liyane, ngarepake respon ing format tartamtu - iku kabeh. PythonJS uga bisa ngolah panjaluk kasebut, lan Python Flask bisa nanggapi. Wadah kaya kothak ireng karo isi sing didhelikake. Nanging, prinsip NOP mbutuhake saben layanan mbukak sawetara titik pungkasan API sing nuduhake kesehatan, uga status kesiapan lan toleransi kesalahan. Kubernetes njaluk pratondho kasebut supaya bisa mikir babagan langkah sabanjure kanggo nuntun lan ngimbangi muatan.

Aplikasi awan sing dirancang kanthi apik nyathet acara utama kanthi nggunakake stream I/O standar STDERR lan STDOUT. Sabanjure ana layanan tambahan, contone filebeat, logstash utawa fluentd, ngirim log menyang sistem pemantauan terpusat (contone Prometheus) lan sistem koleksi log (software suite ELK). Diagram ing ngisor iki nuduhake cara kerja aplikasi awan miturut Pola Tes Kesehatan lan Prinsip Pengamatan Tinggi.

Kepiye cara ngetrapake Pola Priksa Kesehatan ing Kubernetes?

Saka kothak kasebut, k8s ngawasi status pod nggunakake salah sawijining pengontrol (Penyebaran, ReplicaSets, DaemonSets, StatefulSets lsp, lsp). Sawise nemokake yen pod wis tiba amarga sawetara alasan, pengontrol nyoba miwiti maneh utawa mindhah menyang simpul liyane. Nanging, pod bisa uga dilaporake yen wis aktif, nanging ora bisa digunakake. Ayo menehi conto: aplikasi sampeyan nggunakake Apache minangka server web, sampeyan nginstal komponen kasebut ing sawetara polong kluster. Wiwit perpustakaan dikonfigurasi kanthi ora bener, kabeh panjalukan kanggo aplikasi kasebut nanggapi kanthi kode 500 (kesalahan server internal). Nalika mriksa pangiriman, mriksa status polong menehi asil sing sukses, nanging para pelanggan mikir kanthi beda. Kita bakal njlèntrèhaké kahanan sing ora dikarepake iki kaya ing ngisor iki:

Ing conto kita, k8s ora mriksa fungsi. Ing jinis verifikasi iki, kubelet terus mriksa kahanan proses ing wadhah kasebut. Sawise dheweke ngerti yen proses wis mandheg, dheweke bakal miwiti maneh. Yen kesalahan bisa dirampungake kanthi mung miwiti maneh aplikasi, lan program kasebut dirancang kanggo mateni kesalahan apa wae, mula priksa kesehatan proses mung sampeyan kudu ngetutake NOP lan Pola Tes Kesehatan. Sayange mung ora kabeh kesalahan bisa diilangi kanthi miwiti maneh. Ing kasus iki, k8s nawakake 2 cara sing luwih jero kanggo ngenali masalah karo pod: livenessProbe и kesiapanProbe.

LivenessProbe

Sajrone livenessProbe kubelet nindakake 3 jinis pamriksa: ora mung nemtokake manawa pod mlaku, nanging uga siap nampa lan nanggapi panjalukan kanthi cekap:

• Nggawe panjalukan HTTP menyang pod. Tanggepan kasebut kudu ngemot kode respon HTTP ing kisaran saka 200 nganti 399. Mangkono, kode 5xx lan 4xx menehi sinyal yen pod ngalami masalah, sanajan proses kasebut mlaku.
• Kanggo nguji pod nganggo layanan non-HTTP (contone, server mail Postfix), sampeyan kudu nggawe sambungan TCP.
• Nglakokake printah kasepakatan kanggo pod (internal). Priksa dianggep sukses yen kode completion printah 0.

Conto carane iki bisa. Definisi pod sabanjuré ngemot aplikasi NodeJS sing mbuwang kesalahan 500 ing panjalukan HTTP. Kanggo mesthekake yen wadhah kasebut diwiwiti maneh nalika nampa kesalahan kasebut, kita nggunakake parameter livenessProbe:

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

Iki ora beda karo definisi pod liyane, nanging kita nambah obyek .spec.containers.livenessProbe... Parameter httpGet nampa path sing njaluk HTTP GET dikirim (ing conto kita iki /, nanging ing skenario pertempuran bisa uga ana sing kaya /api/v1/status). LivenessProbe liyane nampa parameter initialDelaySeconds, sing menehi instruksi operasi verifikasi kanggo ngenteni sawetara detik sing ditemtokake. Wektu tundha dibutuhake amarga wadhah kasebut butuh wektu kanggo miwiti, lan nalika diwiwiti maneh bakal ora kasedhiya kanggo sawetara wektu.

Kanggo ngetrapake setelan iki menyang kluster, gunakake:

kubectl apply -f pod.yaml

Sawise sawetara detik, sampeyan bisa mriksa isi pod nggunakake printah ing ngisor iki:

kubectl describe pods node500

Ing mburi output, golek iku apa.

Nalika sampeyan bisa ndeleng, livenessProbe miwiti panjalukan HTTP GET, wadhah kasebut ngasilake kesalahan 500 (yaiku apa sing diprogram), lan kubelet miwiti maneh.

Yen sampeyan kepingin weruh carane aplikasi NideJS diprogram, iki app.js lan Dockerfile sing digunakake:

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')
})

file docker

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

Penting kanggo dicathet: livenessProbe mung bakal miwiti maneh wadhah kasebut yen gagal. Yen restart ora mbenerake kesalahan sing ngalangi wadhah saka mlaku, kubelet ora bakal bisa tumindak kanggo mbenerake masalah.

kesiapanProbe

readinessProbe dianggo padha kanggo livenessProbes (GET panjalukan, komunikasi TCP lan eksekusi printah), kajaba kanggo tumindak ngatasi masalah. Wadhah sing dideteksi kegagalan ora diwiwiti maneh, nanging diisolasi saka lalu lintas mlebu. Mbayangno yen salah siji saka wadhah nindakake akeh petungan utawa ana ing beban abot, nyebabake wektu nanggepi mundhak. Ing kasus livenessProbe, mriksa kasedhiyan respon micu (liwat parameter mriksa timeoutSeconds), sawise kubelet miwiti maneh wadhah. Nalika diwiwiti, wadhah kasebut wiwit nindakake tugas intensif sumber daya lan diwiwiti maneh. Iki bisa dadi kritis kanggo aplikasi sing mbutuhake kacepetan respon. Contone, mobil nalika ing dalan nunggu respon saka server, respon wis telat - lan mobil nemu kacilakan.

Ayo nulis definisi redinessProbe sing bakal nyetel wektu respon panjalukan GET ora luwih saka rong detik, lan aplikasi bakal nanggapi panjalukan GET sawise 5 detik. Berkas pod.yaml kudu katon kaya iki:

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

Ayo nyebar pod nganggo kubectl:

kubectl apply -f pod.yaml

Ayo ngenteni sawetara detik banjur deleng kepiye cara kerjane ReadinessProbe:

kubectl describe pods nodedelayed

Ing mburi output sampeyan bisa ndeleng sing sawetara acara padha iki.

Kaya sing sampeyan ngerteni, kubectl ora miwiti maneh pod nalika wektu mriksa ngluwihi 2 detik. Nanging, dheweke mbatalake panjaluk kasebut. Komunikasi sing mlebu dialihake menyang pod liya sing bisa digunakake.

Elinga yen saiki pod wis diundhuh, kubectl njaluk rute maneh: tanggapan kanggo panjaluk GET ora ditundha maneh.

Kanggo mbandhingake, ing ngisor iki ana file app.js sing diowahi:

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
Sadurunge tekane aplikasi awan, log minangka sarana utama kanggo ngawasi lan mriksa kesehatan aplikasi. Nanging, ora ana cara kanggo njupuk tindakan koreksi. Log isih migunani saiki; kudu dikumpulake lan dikirim menyang sistem koleksi log kanggo nganalisa kahanan darurat lan nggawe keputusan. [Kabeh iki bisa ditindakake tanpa aplikasi awan nggunakake monit, umpamane, nanging kanthi k8s dadi luwih gampang :) - cathetan editor. ]

Saiki, koreksi kudu ditindakake meh ing wektu nyata, mula aplikasi ora kudu dadi kothak ireng maneh. Ora, padha kudu nuduhake titik pungkasan sing ngidini sistem ngawasi kanggo takon lan ngumpulake data sing penting babagan kahanan proses supaya bisa langsung nanggapi yen perlu. Iki diarani Performance Test Design Pattern, sing ngetutake High Observability Principle (HOP).

Kubernetes nawakake 2 jinis pemeriksaan kesehatan kanthi standar: readyProbe lan livenessProbe. Loro-lorone nggunakake jinis pamriksa sing padha (panjaluk HTTP GET, komunikasi TCP lan eksekusi perintah). Padha beda-beda ing pancasan apa kanggo nanggepi masalah ing pods. livenessProbe miwiti maneh wadhah kanthi pangarep-arep yen kesalahan ora bakal kedadeyan maneh, lan kesiapanProbe ngisolasi polong saka lalu lintas sing mlebu nganti penyebab masalah dirampungake.

Desain aplikasi sing tepat kudu kalebu loro jinis mriksa lan mesthekake yen padha ngumpulake data cukup, utamané nalika pangecualian dibuwang. Sampeyan uga kudu nuduhake endpoints API sing perlu sing nyedhiyakake sistem pemantauan (Prometheus) kanthi metrik kesehatan sing penting.

Source: www.habr.com