Praktik Terbaik untuk Kontainer Kubernetes: Pemeriksaan Kesehatan

TL; DR

• Untuk mencapai tingkat observasi yang tinggi terhadap container dan layanan mikro, log dan metrik primer saja tidak cukup.
• Untuk pemulihan yang lebih cepat dan peningkatan ketahanan, aplikasi harus menerapkan Prinsip Observabilitas Tinggi (HOP).
• Pada tingkat penerapan, NOP memerlukan: pencatatan log yang tepat, pemantauan ketat, pemeriksaan kewarasan, dan penelusuran kinerja/transisi.
• Gunakan cek sebagai elemen NOR pemeriksaan kesiapan и penyelidikan keaktifan Kubernet.

Apa itu Templat Pemeriksaan Kesehatan?

Saat merancang aplikasi yang sangat penting dan memiliki ketersediaan tinggi, sangat penting untuk memikirkan aspek seperti toleransi kesalahan. Suatu aplikasi dianggap toleran terhadap kesalahan jika aplikasi tersebut pulih dengan cepat dari kegagalan. Aplikasi cloud pada umumnya menggunakan arsitektur layanan mikro - di mana setiap komponen ditempatkan dalam wadah terpisah. Dan untuk memastikan bahwa aplikasi di k8s memiliki ketersediaan tinggi saat Anda mendesain cluster, Anda perlu mengikuti pola tertentu. Diantaranya adalah Template Cek Kesehatan. Ini mendefinisikan bagaimana aplikasi berkomunikasi dengan k8s bahwa aplikasi tersebut sehat. Ini bukan hanya informasi tentang apakah pod sedang berjalan, tetapi juga tentang bagaimana pod tersebut menerima dan merespons permintaan. Semakin banyak pengetahuan Kubernetes tentang kesehatan pod, semakin cerdas keputusan yang diambil mengenai perutean lalu lintas dan penyeimbangan beban. Dengan demikian, Prinsip Observabilitas Tinggi memungkinkan aplikasi merespons permintaan secara tepat waktu.

Prinsip Observabilitas Tinggi (HOP)

Prinsip observabilitas tinggi adalah salah satunya prinsip-prinsip untuk merancang aplikasi kemas. Dalam arsitektur layanan mikro, layanan tidak peduli bagaimana permintaannya diproses (dan memang demikian), namun yang penting adalah bagaimana layanan menerima respons dari layanan penerima. Misalnya, untuk mengautentikasi pengguna, satu wadah mengirimkan permintaan HTTP ke wadah lain, mengharapkan respons dalam format tertentu - itu saja. PythonJS juga dapat memproses permintaan tersebut, dan Python Flask dapat merespons. Wadah itu seperti kotak hitam yang isinya tersembunyi satu sama lain. Namun, prinsip NOP mengharuskan setiap layanan untuk mengekspos beberapa titik akhir API yang menunjukkan seberapa sehat layanan tersebut, serta status kesiapan dan toleransi kesalahannya. Kubernetes meminta indikator-indikator ini untuk memikirkan langkah selanjutnya dalam perutean dan penyeimbangan beban.

Aplikasi cloud yang dirancang dengan baik mencatat peristiwa utamanya menggunakan aliran I/O standar STDERR dan STDOUT. Berikutnya adalah layanan tambahan, misalnya filebeat, logstash atau fluentd, yang mengirimkan log ke sistem pemantauan terpusat (misalnya Prometheus) dan sistem pengumpulan log (rangkaian perangkat lunak ELK). Diagram di bawah menunjukkan cara kerja aplikasi cloud berdasarkan Pola Uji Kesehatan dan Prinsip Observabilitas Tinggi.

Bagaimana cara menerapkan Pola Pemeriksaan Kesehatan di Kubernetes?

Di luar kotak, k8s memantau status pod menggunakan salah satu pengontrol (penyebaran, ReplikaSet, DaemonSet, Set Stateful dll., dll.). Setelah mengetahui bahwa pod terjatuh karena suatu alasan, pengontrol mencoba memulai ulang atau memindahkannya ke node lain. Namun, sebuah pod mungkin melaporkan bahwa ia aktif dan berjalan, namun pod itu sendiri tidak berfungsi. Mari kita beri contoh: aplikasi Anda menggunakan Apache sebagai server web, Anda menginstal komponen di beberapa pod cluster. Karena perpustakaan tidak dikonfigurasi dengan benar, semua permintaan ke aplikasi merespons dengan kode 500 (kesalahan server internal). Saat memeriksa pengiriman, memeriksa status pod memberikan hasil yang sukses, namun pelanggan berpikir berbeda. Kami akan menggambarkan situasi yang tidak diinginkan ini sebagai berikut:

Dalam contoh kita, k8s melakukannya pemeriksaan fungsionalitas. Pada jenis verifikasi ini, kubelet terus-menerus memeriksa status proses di dalam container. Begitu dia memahami bahwa prosesnya telah berhenti, dia akan memulainya kembali. Jika kesalahan dapat diatasi hanya dengan memulai ulang aplikasi, dan program dirancang untuk mematikan kesalahan apa pun, maka Anda hanya memerlukan pemeriksaan kesehatan proses untuk mengikuti NOP dan Pola Tes Kesehatan. Satu-satunya hal yang disayangkan adalah tidak semua kesalahan dihilangkan dengan memulai ulang. Dalam hal ini, k8s menawarkan 2 cara yang lebih mendalam untuk mengidentifikasi masalah pada pod: penyelidikan keaktifan и pemeriksaan kesiapan.

Pemeriksaan Kehidupan

Selama penyelidikan keaktifan kubelet melakukan 3 jenis pemeriksaan: tidak hanya menentukan apakah pod sedang berjalan, namun juga apakah pod siap menerima dan merespons permintaan secara memadai:

• Siapkan permintaan HTTP ke pod. Responsnya harus berisi kode respons HTTP dalam kisaran 200 hingga 399. Jadi, kode 5xx dan 4xx menandakan bahwa pod mengalami masalah, meskipun prosesnya sedang berjalan.
• Untuk menguji pod dengan layanan non-HTTP (misalnya, server email Postfix), Anda perlu membuat koneksi TCP.
• Jalankan perintah arbitrer untuk sebuah pod (secara internal). Pengecekan dianggap berhasil jika kode penyelesaian perintah adalah 0.

Contoh cara kerjanya. Definisi pod berikutnya berisi aplikasi NodeJS yang memunculkan kesalahan 500 pada permintaan HTTP. Untuk memastikan bahwa container dimulai ulang ketika menerima kesalahan seperti itu, 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 berbeda dengan definisi pod lainnya, tetapi kami menambahkan sebuah objek .spec.containers.livenessProbe. Parameter httpGet menerima jalur ke mana permintaan HTTP GET dikirim (dalam contoh kita ini adalah /, tapi dalam skenario pertempuran mungkin ada sesuatu seperti itu /api/v1/status). LivenessProbe lain menerima parameter initialDelaySeconds, yang memerintahkan operasi verifikasi untuk menunggu beberapa detik tertentu. Penundaan diperlukan karena penampung memerlukan waktu untuk memulai, dan ketika dimulai ulang, penampung tidak akan tersedia untuk beberapa waktu.

Untuk menerapkan pengaturan ini ke klaster, gunakan:

kubectl apply -f pod.yaml

Setelah beberapa detik, Anda dapat memeriksa isi pod menggunakan perintah berikut:

kubectl describe pods node500

Di akhir output, temukan s apa.

Seperti yang bisa kamu lihat, livenessProbe memulai permintaan HTTP GET, container menghasilkan error 500 (yang memang sudah diprogram), dan kubelet memulai ulang container tersebut.

Jika Anda bertanya-tanya bagaimana aplikasi NideJS diprogram, berikut app.js dan Dockerfile yang digunakan:

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 untuk diperhatikan: livenessProbe hanya akan memulai ulang container jika gagal. Jika restart tidak memperbaiki kesalahan yang menghalangi container untuk berjalan, kubelet tidak akan dapat mengambil tindakan untuk memperbaiki masalah tersebut.

pemeriksaan kesiapan

kesiapanProbe bekerja mirip dengan livenessProbes (permintaan GET, komunikasi TCP, dan eksekusi perintah), kecuali untuk tindakan pemecahan masalah. Kontainer tempat kegagalan terdeteksi tidak dimulai ulang, namun diisolasi dari lalu lintas masuk. Bayangkan salah satu kontainer sedang melakukan banyak perhitungan atau berada di bawah beban berat, sehingga menyebabkan waktu respons meningkat. Dalam kasus livenessProbe, pemeriksaan ketersediaan respons dipicu (melalui parameter pemeriksaan timeoutSeconds), setelah itu kubelet memulai ulang container. Saat dimulai, kontainer mulai melakukan tugas intensif sumber daya dan dimulai ulang lagi. Ini penting untuk aplikasi yang memerlukan kecepatan respons. Misalnya, sebuah mobil saat berada di jalan sedang menunggu respon dari server, responnya tertunda - dan mobil tersebut mengalami kecelakaan.

Mari kita tulis definisi redinessProbe yang akan menyetel waktu respons permintaan GET tidak lebih dari dua detik, dan aplikasi akan merespons permintaan GET setelah 5 detik. File pod.yaml akan terlihat 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 terapkan pod dengan kubectl:

kubectl apply -f pod.yaml

Mari kita tunggu beberapa detik lalu lihat cara kerja PreparedProbe:

kubectl describe pods nodedelayed

Di akhir keluaran Anda dapat melihat bahwa beberapa kejadian serupa yang ini.

Seperti yang bisa kamu lihat, kubectl tidak memulai ulang pod ketika waktu pemeriksaan melebihi 2 detik. Sebaliknya, dia membatalkan permintaan tersebut. Komunikasi masuk dialihkan ke pod lain yang berfungsi.

Perhatikan bahwa sekarang setelah pod diturunkan, kubectl merutekan permintaan ke pod itu lagi: respons terhadap permintaan GET tidak lagi tertunda.

Sebagai perbandingan, di bawah ini adalah file app.js yang dimodifikasi:

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 munculnya aplikasi cloud, log adalah sarana utama untuk memantau dan memeriksa kesehatan aplikasi. Namun, tidak ada tindakan perbaikan yang diambil. Log masih berguna saat ini; log perlu dikumpulkan dan dikirim ke sistem pengumpulan log untuk menganalisis situasi darurat dan mengambil keputusan. [Semua ini dapat dilakukan tanpa aplikasi cloud, misalnya menggunakan monit, tetapi dengan k8s semuanya menjadi lebih mudah :) – catatan editor. ]

Saat ini, koreksi harus dilakukan hampir secara real time, sehingga aplikasi tidak lagi harus berupa kotak hitam. Tidak, mereka harus menunjukkan titik akhir yang memungkinkan sistem pemantauan menanyakan dan mengumpulkan data berharga tentang status proses sehingga mereka dapat merespons secara instan jika diperlukan. Ini disebut Pola Desain Tes Kinerja, yang mengikuti Prinsip Observabilitas Tinggi (HOP).

Kubernetes menawarkan 2 jenis pemeriksaan kesehatan secara default: readyProbe dan livenessProbe. Keduanya menggunakan jenis pemeriksaan yang sama (permintaan HTTP GET, komunikasi TCP, dan eksekusi perintah). Mereka berbeda dalam mengambil keputusan dalam menanggapi masalah yang ada di pod. livenessProbe memulai ulang container dengan harapan kesalahan tidak akan terjadi lagi, dan readyProbe mengisolasi pod dari lalu lintas masuk hingga penyebab masalahnya teratasi.

Desain aplikasi yang tepat harus mencakup kedua jenis pemeriksaan dan memastikan bahwa keduanya mengumpulkan cukup data, terutama ketika ada pengecualian. Ini juga harus menunjukkan titik akhir API yang diperlukan yang menyediakan metrik kesehatan penting bagi sistem pemantauan (Prometheus).

Sumber: www.habr.com