Amalan Terbaik untuk Bekas Kubernetes: Pemeriksaan Kesihatan

TL; DR

• Untuk mencapai kebolehmerhatian tinggi bagi bekas dan perkhidmatan mikro, log dan metrik utama tidak mencukupi.
• Untuk pemulihan yang lebih cepat dan peningkatan daya tahan, aplikasi harus menggunakan Prinsip Kebolehcerapan Tinggi (HOP).
• Pada peringkat aplikasi, NOP memerlukan: pengelogan yang betul, pemantauan rapi, semakan kewarasan dan pengesanan prestasi/peralihan.
• Gunakan cek sebagai elemen NOR kesediaanProbe и livenessProbe Kubernetes.

Apakah Templat Pemeriksaan Kesihatan?

Apabila mereka bentuk aplikasi kritikal misi dan sangat tersedia, adalah sangat penting untuk memikirkan aspek seperti toleransi kesalahan. Aplikasi dianggap tahan terhadap kesalahan jika ia pulih dengan cepat daripada kegagalan. Aplikasi awan biasa menggunakan seni bina perkhidmatan mikro - di mana setiap komponen diletakkan dalam bekas yang berasingan. Dan untuk memastikan bahawa aplikasi pada k8s sangat tersedia apabila anda mereka bentuk kluster, anda perlu mengikut corak tertentu. Antaranya ialah Templat Pemeriksaan Kesihatan. Ia mentakrifkan cara aplikasi berkomunikasi kepada k8s bahawa ia sihat. Ini bukan sahaja maklumat tentang sama ada pod sedang berjalan, tetapi juga tentang cara ia menerima dan bertindak balas kepada permintaan. Semakin Kubernetes mengetahui tentang kesihatan pod, semakin bijak keputusan yang dibuatnya tentang penghalaan trafik dan pengimbangan beban. Oleh itu, Prinsip Kebolehmerhatian Tinggi membolehkan aplikasi bertindak balas kepada permintaan tepat pada masanya.

Prinsip Kebolehmerhatian Tinggi (HOP)

Prinsip kebolehmerhatian yang tinggi adalah salah satu daripada prinsip untuk mereka bentuk aplikasi kontena. Dalam seni bina microservices, perkhidmatan tidak peduli bagaimana permintaan mereka diproses (dan memang betul), tetapi yang penting ialah cara mereka menerima respons daripada perkhidmatan yang menerima. Contohnya, untuk mengesahkan pengguna, satu bekas menghantar permintaan HTTP kepada yang lain, mengharapkan respons dalam format tertentu - itu sahaja. PythonJS juga boleh memproses permintaan, dan Python Flask boleh bertindak balas. Bekas adalah seperti kotak hitam dengan kandungan tersembunyi antara satu sama lain. Walau bagaimanapun, prinsip NOP memerlukan setiap perkhidmatan untuk mendedahkan berbilang titik akhir API yang menunjukkan tahap kesihatannya, serta status kesediaan dan toleransi kesalahannya. Kubernetes meminta penunjuk ini untuk memikirkan langkah seterusnya untuk penghalaan dan pengimbangan beban.

Aplikasi awan yang direka dengan baik merekodkan peristiwa utamanya menggunakan strim I/O standard STDERR dan STDOUT. Seterusnya datang perkhidmatan tambahan, contohnya filebeat, logstash atau fluentd, menghantar log ke sistem pemantauan berpusat (contohnya Prometheus) dan sistem pengumpulan log (suite perisian ELK). Rajah di bawah menunjukkan cara aplikasi awan berfungsi mengikut Corak Ujian Kesihatan dan Prinsip Kebolehmerhatian Tinggi.

Bagaimana untuk menggunakan Corak Pemeriksaan Kesihatan dalam Kubernetes?

Di luar kotak, k8s memantau status pod menggunakan salah satu pengawal (Penyerahan, ReplicaSets, Set Daemon, StatefulSets dsb., dsb.). Setelah mendapati bahawa pod telah jatuh atas sebab tertentu, pengawal cuba untuk memulakan semula atau mengalihkannya ke nod lain. Walau bagaimanapun, pod mungkin melaporkan bahawa ia sedang aktif dan berjalan, tetapi pod itu sendiri tidak berfungsi. Mari beri contoh: aplikasi anda menggunakan Apache sebagai pelayan web, anda memasang komponen pada beberapa pod kluster. Memandangkan perpustakaan telah dikonfigurasikan secara salah, semua permintaan kepada aplikasi bertindak balas dengan kod 500 (ralat pelayan dalaman). Apabila menyemak penghantaran, menyemak status pod memberikan hasil yang berjaya, tetapi pelanggan berfikir secara berbeza. Kami akan menerangkan keadaan yang tidak diingini ini seperti berikut:

Dalam contoh kami, k8s melakukannya pemeriksaan kefungsian. Dalam jenis pengesahan ini, kubelet sentiasa menyemak keadaan proses dalam bekas. Sebaik sahaja dia memahami bahawa proses itu telah berhenti, dia akan memulakannya semula. Jika ralat boleh diselesaikan dengan hanya memulakan semula aplikasi, dan program ini direka untuk menutup sebarang ralat, maka pemeriksaan kesihatan proses adalah semua yang anda perlukan untuk mengikuti NOP dan Corak Ujian Kesihatan. Satu-satunya kasihan ialah tidak semua ralat dihapuskan dengan memulakan semula. Dalam kes ini, k8s menawarkan 2 cara yang lebih mendalam untuk mengenal pasti masalah dengan pod: livenessProbe и kesediaanProbe.

LivenessProbe

Semasa livenessProbe kubelet melakukan 3 jenis semakan: bukan sahaja menentukan sama ada pod sedang berjalan, tetapi juga sama ada pod sedia untuk menerima dan memberi respons yang secukupnya kepada permintaan:

• Sediakan permintaan HTTP ke pod. Respons mesti mengandungi kod respons HTTP dalam julat dari 200 hingga 399. Oleh itu, kod 5xx dan 4xx memberi isyarat bahawa pod mengalami masalah, walaupun proses sedang berjalan.
• Untuk menguji pod dengan perkhidmatan bukan HTTP (contohnya, pelayan mel Postfix), anda perlu mewujudkan sambungan TCP.
• Laksanakan arahan sewenang-wenangnya untuk pod (secara dalaman). Semakan dianggap berjaya jika kod penyelesaian arahan ialah 0.

Contoh cara ini berfungsi. Definisi pod seterusnya mengandungi aplikasi NodeJS yang melemparkan ralat 500 pada permintaan HTTP. Untuk memastikan bekas dimulakan semula apabila menerima ralat sedemikian, kami menggunakan 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

Ini tidak berbeza daripada mana-mana definisi pod lain, tetapi kami menambah objek .spec.containers.livenessProbe. Parameter httpGet menerima laluan ke mana permintaan HTTP GET dihantar (dalam contoh kami ini ialah /, tetapi dalam senario pertempuran mungkin ada sesuatu seperti /api/v1/status). Satu lagi livenessProbe menerima parameter initialDelaySeconds, yang mengarahkan operasi pengesahan untuk menunggu beberapa saat tertentu. Kelewatan diperlukan kerana bekas memerlukan masa untuk dimulakan dan apabila dimulakan semula ia akan tidak tersedia untuk beberapa lama.

Untuk menggunakan tetapan ini pada kelompok, gunakan:

kubectl apply -f pod.yaml

Selepas beberapa saat, anda boleh menyemak kandungan pod menggunakan arahan berikut:

kubectl describe pods node500

Pada akhir output, cari itulah yang.

Seperti yang anda boleh lihat, livenessProbe memulakan permintaan HTTP GET, bekas tersebut menghasilkan ralat 500 (iaitu yang telah diprogramkan untuk dilakukan), dan kubelet memulakannya semula.

Jika anda tertanya-tanya bagaimana aplikasi NideJS diprogramkan, berikut ialah app.js dan Dockerfile yang digunakan:

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

Perkara ini penting untuk diperhatikan: livenessProbe hanya akan memulakan semula bekas jika ia gagal. Jika mulakan semula tidak membetulkan ralat yang menghalang bekas daripada berjalan, kubelet tidak akan dapat mengambil tindakan untuk membetulkan masalah.

kesediaanProbe

readinessProbe berfungsi sama seperti livenessProbes (permintaan GET, komunikasi TCP dan pelaksanaan perintah), kecuali untuk tindakan penyelesaian masalah. Bekas di mana kegagalan dikesan tidak dimulakan semula, tetapi diasingkan daripada trafik masuk. Bayangkan bahawa salah satu bekas sedang melakukan banyak pengiraan atau berada di bawah beban berat, menyebabkan masa tindak balas meningkat. Dalam kes livenessProbe, semakan ketersediaan respons dicetuskan (melalui parameter semakan timeoutSeconds), selepas itu kubelet memulakan semula bekas. Apabila dimulakan, bekas mula melaksanakan tugas intensif sumber dan dimulakan semula. Ini boleh menjadi kritikal untuk aplikasi yang memerlukan kelajuan tindak balas. Sebagai contoh, kereta semasa di jalan raya sedang menunggu maklum balas daripada pelayan, respons tertangguh - dan kereta itu mengalami kemalangan.

Mari tulis definisi redinessProbe yang akan menetapkan masa tindak balas permintaan GET kepada tidak lebih daripada dua saat, dan aplikasi akan membalas permintaan GET selepas 5 saat. Fail pod.yaml sepatutnya kelihatan seperti ini:

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

Mari kita gunakan pod dengan kubectl:

kubectl apply -f pod.yaml

Mari tunggu beberapa saat dan kemudian lihat bagaimana readyProbe berfungsi:

kubectl describe pods nodedelayed

Pada akhir output anda dapat melihat bahawa beberapa peristiwa adalah serupa yang ini.

Seperti yang anda lihat, kubectl tidak memulakan semula pod apabila masa semakan melebihi 2 saat. Sebaliknya, dia membatalkan permintaan itu. Komunikasi masuk dialihkan ke pod lain yang berfungsi.

Ambil perhatian bahawa sekarang bahawa pod telah dimuat turun, laluan kubectl memintanya semula: respons kepada permintaan GET tidak lagi ditangguhkan.

Sebagai perbandingan, di bawah ialah fail app.js yang diubah suai:

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
Sebelum kemunculan aplikasi awan, log adalah cara utama untuk memantau dan menyemak kesihatan aplikasi. Bagaimanapun, tiada cara untuk mengambil sebarang tindakan pembetulan. Log masih berguna hari ini; ia perlu dikumpul dan dihantar ke sistem pengumpulan log untuk menganalisis situasi kecemasan dan membuat keputusan. [Semua ini boleh dilakukan tanpa aplikasi awan menggunakan monit, sebagai contoh, tetapi dengan k8s ia menjadi lebih mudah :) - nota editor. ]

Hari ini, pembetulan perlu dibuat hampir dalam masa nyata, jadi aplikasi tidak lagi perlu menjadi kotak hitam. Tidak, mereka harus menunjukkan titik akhir yang membolehkan sistem pemantauan membuat pertanyaan dan mengumpul data berharga tentang keadaan proses supaya mereka boleh bertindak balas serta-merta jika perlu. Ini dipanggil Corak Reka Bentuk Ujian Prestasi, yang mengikut Prinsip Kebolehmerhatian Tinggi (HOP).

Kubernetes menawarkan 2 jenis pemeriksaan kesihatan secara lalai: readyProbe dan livenessProbe. Kedua-duanya menggunakan jenis semakan yang sama (permintaan HTTP GET, komunikasi TCP dan pelaksanaan perintah). Mereka berbeza dalam keputusan yang mereka buat sebagai tindak balas kepada masalah dalam pod. livenessProbe memulakan semula bekas dengan harapan ralat tidak akan berlaku lagi, dan readyProbe mengasingkan pod daripada trafik masuk sehingga punca masalah diselesaikan.

Reka bentuk aplikasi yang betul harus merangkumi kedua-dua jenis semakan dan memastikan ia mengumpul data yang mencukupi, terutamanya apabila pengecualian dilemparkan. Ia juga harus menunjukkan titik akhir API yang diperlukan yang menyediakan sistem pemantauan (Prometheus) dengan metrik kesihatan yang penting.

Sumber: www.habr.com