Prakték Pangalusna pikeun Wadah Kubernetes: Cék Kaséhatan

TL; DR

• Pikeun ngahontal observability luhur peti jeung microservices, log jeung metrics primér teu cukup.
• Pikeun pamulihan anu langkung gancang sareng ningkatkeun daya tahan, aplikasi kedah nerapkeun Prinsip Pengamatan Tinggi (HOP).
• Dina tingkat aplikasi, NOP merlukeun: logging ditangtoskeun, ngawaskeun nutup, cék sanity, sarta kinerja / tracing tracing.
• Paké cék salaku unsur NOR kesiapanProbe и livenessProbe Kubernetes.

Naon téh Citakan Cék Kaséhatan?

Nalika ngarancang aplikasi anu kritis sareng sayogi pisan, penting pisan pikeun mikirkeun aspék sapertos kasabaran kasalahan. Hiji aplikasi dianggap toleran lepat lamun cageur gancang tina gagal. Hiji aplikasi awan has ngagunakeun arsitéktur microservices - dimana unggal komponén disimpen dina wadahna misah. Sarta guna mastikeun yén aplikasi on k8s sadia pisan mun anjeun mendesain klaster a, anjeun kudu nuturkeun pola nu tangtu. Di antarana nyaéta Citakan Cék Kaséhatan. Ieu ngahartikeun kumaha aplikasi communicates k8s yén éta téh cageur. Ieu mah sakadar informasi ngeunaan naha pod dijalankeun, tapi ogé ngeunaan kumaha eta narima jeung ngabales requests. Beuki Kubernetes terang ngeunaan kasehatan pod, kaputusan anu langkung pinter ngeunaan routing lalu lintas sareng kasaimbangan beban. Ku kituna, Prinsip Observability Luhur ngamungkinkeun aplikasi pikeun ngabales pamundut dina waktosna.

Prinsip Observability Tinggi (HOP)

Prinsip observasi luhur mangrupa salah sahiji prinsip pikeun ngarancang aplikasi containerized. Dina arsitéktur microservices, jasa henteu paduli kumaha pamundutna diolah (sareng leres-leres), tapi anu penting nyaéta kumaha aranjeunna nampi réspon tina jasa anu nampi. Salaku conto, pikeun ngabuktoskeun kaaslianana pangguna, hiji wadah ngirim pamundut HTTP ka anu sanés, ngarepkeun réspon dina format anu tangtu - éta waé. PythonJS ogé tiasa ngolah pamundut, sareng Python Flask tiasa ngabales. Wadah ibarat kotak hideung anu eusina disumputkeun. Nanging, prinsip NOP meryogikeun unggal jasa pikeun ngungkabkeun sababaraha titik tungtung API anu nunjukkeun kumaha séhat éta, ogé status kesiapan sareng kasabaran kasalahan. Kubernetes nyuhunkeun indikator-indikator ieu pikeun mikirkeun léngkah-léngkah salajengna pikeun rute sareng kasaimbangan beban.

Aplikasi awan anu dirarancang saé log acara utama na nganggo aliran I/O standar STDERR sareng STDOUT. Salajengna asalna layanan tambahan, contona filebeat, logstash atanapi fluentd, nganteurkeun log ka sistem ngawaskeun terpusat (contona Prometheus) jeung sistem kumpulan log (software suite ELK). Diagram di handap nembongkeun kumaha aplikasi awan jalan nurutkeun Pola Test Kaséhatan jeung Prinsip Observability Luhur.

Kumaha cara nerapkeun Pola Cék Kaséhatan di Kubernetes?

Out of the box, k8s ngawas status pods ngagunakeun salah sahiji controller (Pangiriman, ReplicaSets, DaemonSets, StatefulSets jsb., jsb.). Saatos mendakan yén pod parantos murag kusabab sababaraha alesan, pangontrol nyobian ngabalikan deui atanapi ngalihkeun ka titik anu sanés. Sanajan kitu, pod a bisa ngalaporkeun yén éta nepi na ngajalankeun, tapi éta sorangan teu fungsi. Hayu urang masihan conto: aplikasi anjeun nganggo Apache salaku pangladén wéb, anjeun parantos dipasang komponén dina sababaraha pod tina kluster. Kusabab perpustakaan ieu ngonpigurasi leres, sadaya requests ka aplikasi nu ngabales kode 500 (kasalahan server internal). Nalika mariksa pangiriman, mariksa status pods masihan hasil anu suksés, tapi para nasabah mikir béda. Kami bakal ngajelaskeun kaayaan anu teu dipikahoyong ieu sapertos kieu:

Dina conto urang, k8s teu cék fungsionalitas. Dina jenis verifikasi ieu, kubelet terus mariksa kaayaan prosés dina wadahna. Sakali anjeunna ngartos yén prosésna lirén, anjeunna bakal ngamimitian deui. Upami kasalahanna tiasa direngsekeun ku ngan saukur ngabalikan deui aplikasi, sareng programna dirancang pikeun mareuman kasalahan naon waé, maka pamariksaan kaséhatan prosés mangrupikeun anu anjeun kedah nuturkeun NOP sareng Pola Tés Kaséhatan. Hiji-hijina karunya nyaéta henteu sadayana kasalahan dileungitkeun ku ngamimitian deui. Dina hal ieu, k8s nawiskeun 2 cara anu langkung jero pikeun ngaidentipikasi masalah sareng pod: livenessProbe и kesiapanProbe.

LivenessProbe

Salila livenessProbe kubelet ngalaksanakeun 3 jinis pamariksaan: henteu ngan ukur nangtukeun naha pod dijalankeun, tapi ogé naha éta siap nampi sareng ngabales pamenta anu cekap:

• Nyetél pamundut HTTP pikeun pod. Responna kedah ngandung kode réspon HTTP dina rentang ti 200 dugi ka 399. Ku kituna, kode 5xx sareng 4xx sinyal yén pod gaduh masalah, sanaos prosésna jalan.
• Pikeun nguji pod sareng jasa non-HTTP (contona, pangladén surat Postfix), anjeun kedah ngadamel sambungan TCP.
• Ngaéksekusi paréntah sawenang pikeun pod a (internal). Pamariksaan dianggap suksés upami kode parantosan paréntah nyaéta 0.

Hiji conto kumaha ieu jalan. Definisi pod salajengna ngandung aplikasi NodeJS anu ngalungkeun kasalahan 500 dina pamundut HTTP. Pikeun mastikeun yén wadahna di-restart nalika nampi kasalahan sapertos kitu, kami nganggo 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

Ieu teu béda ti sagala harti pod séjén, tapi urang nambahkeun hiji obyék .spec.containers.livenessProbe. Parameter httpGet nampi jalur anu dikirimkeun pamundut HTTP GET (dina conto urang ieu /, Tapi dina skenario tempur meureun aya hal kawas /api/v1/status). livenessProbe sejen narima parameter a initialDelaySeconds, anu maréntahkeun operasi verifikasi pikeun ngantosan sajumlah detik anu ditangtukeun. Tundana diperyogikeun sabab wadahna peryogi waktos kanggo ngamimitian, sareng nalika di-restart deui moal sayogi pikeun sababaraha waktos.

Pikeun nerapkeun setelan ieu ka klaster, paké:

kubectl apply -f pod.yaml

Saatos sababaraha detik, anjeun tiasa pariksa eusi pod nganggo paréntah di handap ieu:

kubectl describe pods node500

Dina ahir kaluaran, manggihan éta naon.

Sakumaha anjeun tiasa tingali, livenessProbe ngagagas pamundut HTTP GET, wadahna ngahasilkeun kasalahan 500 (anu diprogram pikeun ngalakukeunana), sareng kubelet ngamimitian deui.

Upami anjeun heran kumaha aplikasi NideJS diprogram, ieu app.js sareng Dockerfile anu dianggo:

aplikasi.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" ]

Penting pikeun dicatet ieu: livenessProbe ngan bakal ngamimitian deui wadahna upami gagal. Upami balikan deui henteu ngabenerkeun kasalahan anu nyegah wadahna jalan, kubelet moal tiasa nyandak tindakan pikeun ngabenerkeun masalah.

kesiapanProbe

readinessProbe jalan sarupa livenessProbes (GET requests, TCP komunikasi jeung paréntah palaksanaan), iwal lampah ngungkulan. Wadah dimana gagalna dideteksi henteu di-restart, tapi diisolasi tina lalu lintas anu asup. Bayangkeun yén salah sahiji wadahna ngalakukeun seueur itungan atanapi aya dina beban beurat, nyababkeun waktos réspon ningkat. Dina kasus livenessProbe, cék kasadiaan réspon dipicu (via parameter cék timeoutSeconds), saatos éta kubelet ngamimitian deui wadahna. Nalika dimimitian, wadahna mimiti ngalaksanakeun tugas-intensif sumberdaya sareng di-restart deui. Ieu tiasa kritis pikeun aplikasi anu peryogi kagancangan réspon. Contona, mobil bari di jalan keur ngantosan respon ti server, respon ditunda - sarta mobil meunang kana kacilakaan.

Hayu urang nyerat definisi redinessProbe anu bakal nyetél waktos réspon pamundut GET henteu langkung ti dua detik, sareng aplikasi bakal ngabales pamundut GET saatos 5 detik. Berkas pod.yaml kedah siga kieu:

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

Hayu urang nyebarkeun pod sareng kubectl:

kubectl apply -f pod.yaml

Hayu urang antosan sababaraha detik teras tingali kumaha kesiapan Probe damel:

kubectl describe pods nodedelayed

Dina ahir kaluaran anjeun tiasa ningali yén sababaraha acara anu sami Anu ieu.

Sakumaha anjeun tiasa tingali, kubectl henteu ngamimitian deui pod nalika waktos cek langkung ti 2 detik. Gantina, anjeunna ngabolaykeun pamundut. Komunikasi anu asup dialihkeun ka polong anu sanés.

Catet yén ayeuna yén pod dipareuman, rute kubectl naroskeun deui: réspon kana pamundut GET henteu ditunda deui.

Pikeun babandingan, di handap ieu file app.js nu dirobah:

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
Sateuacan munculna aplikasi awan, log mangrupikeun cara utama pikeun ngawaskeun sareng mariksa kaséhatan aplikasi. Tapi, teu aya cara pikeun ngalakukeun tindakan koréksi. Log masih aya mangpaatna ayeuna; aranjeunna kedah dikumpulkeun sareng dikirim ka sistem pangumpulan log pikeun nganalisa kaayaan darurat sareng nyandak kaputusan. [Sadaya ieu tiasa dilakukeun tanpa aplikasi awan nganggo monit, contona, tapi kalayan k8s janten langkung gampang :) - catetan editor. ]

Kiwari, koréksi kedah dilakukeun ampir sacara real waktos, janten aplikasi henteu kedah janten kotak hideung. Henteu, aranjeunna kedah nunjukkeun titik tungtung anu ngamungkinkeun sistem ngawaskeun pikeun naroskeun sareng ngumpulkeun data anu berharga ngeunaan kaayaan prosés supados aranjeunna tiasa langsung ngabales upami diperyogikeun. Ieu disebut Performance Test Design Pattern, nu nuturkeun High Observability Principle (HOP).

Kubernetes nawiskeun 2 jinis pamariksaan kaséhatan sacara standar: readinessProbe sareng livenessProbe. Duanana ngagunakeun jenis cék anu sami (pamenta HTTP GET, komunikasi TCP sareng palaksanaan paréntah). Aranjeunna béda dina kaputusan naon anu aranjeunna lakukeun pikeun ngaréspon masalah dina pods. livenessProbe restarts wadahna dina harepan nu kasalahan moal lumangsung deui, sarta readinessProbe isolates pod ti lalulintas datang nepi ka ngabalukarkeun masalah ieu direngsekeun.

Desain aplikasi anu leres kedah kalebet duanana jinis pamariksaan sareng mastikeun yén aranjeunna ngumpulkeun data anu cukup, khususna nalika aya pengecualian. Éta ogé kedah nunjukkeun titik-titik API anu diperyogikeun anu nyayogikeun sistem ngawaskeun (Prometheus) kalayan métrik kaséhatan anu penting.

sumber: www.habr.com