Entah bagaimana dalam komentar mereka mengajukan pertanyaan tentang bagaimana partisipasi dalam Slurm berbeda dari membaca manual di Kubernet. Saya meminta Pavel Selivanov, pembicara Slurm-2 dan MegaSlurm, untuk memberikan contoh kecil tentang apa yang akan ia sampaikan pada Slurms. Saya memberikan lantai padanya.
Saya mengelola kluster Kubernetes. Baru-baru ini, saya perlu memperbarui versi k8s dan, termasuk, me-restart semua mesin di cluster. Saya memulai proses pada pukul 12:00, dan pada akhir hari kerja semuanya sudah siap. Dan untuk pertama kalinya, saya masih mengikuti pembaruan, dan kedua kalinya saya pergi makan siang selama 1,5 jam (jujur, mengambil laptop). Cluster diperbarui sendiri, tanpa partisipasi saya dan tidak terlihat oleh pelanggan, pengembangannya tidak memperhatikan apa pun, penyebaran berlanjut, layanan berfungsi seperti biasa.
Seperti apa rupanya.
Kemungkinan masalah
Saat me-reboot mesin, ada dua skenario buruk.
- Pengembang meluncurkan aplikasi / redis dalam satu contoh. Tidak peduli seberapa hati-hati Anda mengeluarkan mobil, downtime akan terjadi.
- Ada 2 replika aplikasi, dan satu dikerahkan. Dia keluar, hanya ada satu replika, dan kemudian admin datang dan memadamkan replika terakhir. Sekali lagi, sampai replika naik setelah penyebaran, akan ada downtime.
Saya bisa mengoordinasikan reboot dengan pengembangan, kata mereka, hentikan penyebaran, periksa instans, saya akan me-restart mesin, tapi saya suka ide DevOps bahwa komunikasi manusia harus diminimalkan. Lebih baik mengatur otomatisasi satu kali daripada mengoordinasikan tindakan Anda setiap kali.
Kondisi tugas
Saya menggunakan Amazon dengan kenyamanan dan stabilitasnya. Semuanya otomatis, Anda dapat membuat dan memadamkan mesin virtual, memeriksa ketersediaannya, dll.
Cluster Kubernetes dikerahkan, dikelola, dan diperbarui melalui utilitas kops, yang sangat saya sukai.
Ketika memperbarui kops, secara otomatis menguras node (kubectl drain node), menunggu sampai semuanya telah dievakuasi dari node ini, menghapusnya, membuat node baru di Amazon dengan versi yang benar dari komponen Kubernetes, menempelkannya ke cluster, memverifikasi bahwa node telah memasuki cluster dengan baik, dan dengan semua simpul dalam lingkaran sampai versi Kubernet yang diinginkan ada di mana-mana.
Solusi
Di CI, saya menggunakan kube-lint untuk memeriksa semua manifes yang akan diluncurkan di Kubernetes. Helm Template melempar semua yang akan diluncurkan, saya menetapkan linter untuk dibongkar, yang mengevaluasi semuanya sesuai dengan aturan yang diberikan.
Sebagai contoh, salah satu aturan mengatakan bahwa untuk aplikasi apa pun di kluster Kubernetes, jumlah replika harus minimal 2.
Jika tidak ada replika sama sekali (yang default ke 1), ada 0 atau 1 di antaranya, kube-lint melarang penyebaran ke cluster untuk menghindari masalah di masa depan.
Katakanlah penyebaran oleh desain dirancang sehingga hanya ada satu replika. Untuk kasus ini, ada anggaran gangguan pod, di mana max_unavailable dan min_available diatur untuk aplikasi yang berjalan di Kubernetes. Jika Anda ingin selalu memiliki setidaknya 1 replika, setel min_available = 1.
Ada 2 replika, penyebaran dimulai, 1 replika mati, masih ada 1. Pada mesin di mana replika tinggal, admin memulai simpul drain kubectl. Secara teori, Kubernetes harus mulai menghapus replika langsung ini dan memindahkannya ke simpul lain. Tetapi anggaran gangguan pod bekerja. Kubernetes berkata kepada administrator: maaf, replika tinggal di sini, jika kami menghapusnya, kami akan melanggar anggaran gangguan pod. Smart drain node hang sebelum batas waktu berakhir dan mencoba untuk melayang simpul. Jika penyebaran selesai dan kedua replika tersedia, replika pada simpul ini akan ditampilkan.
Di MegaSlerme, saya akan menunjukkan seperangkat aturan lengkap yang memungkinkan saya untuk minum kopi di kafe sementara kluster Kubernet diperbarui dengan restart semua node.
Topik saya tentang Slurm :
- Memperkenalkan Kubernet, Komponen Utama
- Perangkat cluster, komponen utama, toleransi kesalahan, jaringan k8s
- Abstraksi Kubernet Tingkat Lanjut
- Penebangan dan Pemantauan
Topik saya di MegaSlerme :
- Proses Cluster Di Dalam Failover
- Otorisasi klaster menggunakan penyedia eksternal
- Aplikasi aman dan sangat tersedia di cluster
- Menerapkan strategi penyebaran selain RollingUpdate
- Menembak Kesulitan di Kubernetes