Nganyarke Kluster Kubernetes Tanpa Downtime

Proses upgrade kanggo kluster Kubernetes sampeyan

Ing sawetara titik, nalika nggunakake kluster Kubernetes, ana perlu kanggo nganyari simpul mlaku. Iki bisa uga kalebu nganyari paket, nganyari kernel, utawa panyebaran gambar mesin virtual anyar. Ing terminologi Kubernetes iki diarani "Gangguan Sukarela".

Kiriman iki minangka bagéan saka seri 4-posting:

1. Iki kirim.
2. Pateni polong sing bener ing kluster Kubernetes
3. Telat rampung pod nalika dibusak
4. Cara Ngindhari Downtime Kluster Kubernetes Nggunakake PodDisruptionBudgets

(kira-kira. Nyana terjemahan artikel sing isih ana ing seri kasebut ing mangsa ngarep)

Ing artikel iki, kita bakal njlèntrèhaké kabeh alat sing Kubernetes nyedhiyakake kanggo entuk nol downtime kanggo simpul sing mlaku ing kluster sampeyan.

Nemtokake masalah

Kita bakal njupuk pendekatan naif ing wiwitan, ngenali masalah lan netepake risiko potensial saka pendekatan iki, lan mbangun kawruh kanggo ngatasi saben masalah sing kita temokake ing saindhenging siklus. Asil kasebut minangka konfigurasi sing nggunakake pancingan siklus urip, panyelidikan kesiapan, lan anggaran gangguan Pod kanggo nggayuh tujuan nol downtime.

Kanggo miwiti lelungan, ayo njupuk conto konkrit. Contone, kita duwe klompok Kubernetes saka rong simpul, ing ngendi aplikasi mlaku kanthi rong pod sing ana ing mburi. Service:

Ayo miwiti karo rong pod karo Nginx lan Layanan sing mlaku ing rong simpul kluster Kubernetes.

Kita pengin nganyari versi kernel saka rong node pekerja ing kluster kita. Kepiye carane nindakake iki? Solusi sing gampang yaiku boot simpul anyar kanthi konfigurasi sing dianyari banjur mateni simpul lawas nalika miwiti sing anyar. Nalika iki bakal bisa digunakake, bakal ana sawetara masalah karo pendekatan iki:

• Yen sampeyan mateni simpul lawas, polong sing mlaku ing kono uga bakal dipateni. Kepiye yen polong kudu diresiki kanggo mateni kanthi apik? Sistem virtualisasi sing sampeyan gunakake bisa uga ora ngenteni proses pembersihan rampung.
• Apa yen sampeyan mateni kabeh simpul ing wektu sing padha? Sampeyan bakal entuk downtime sing cukup nalika pods pindhah menyang simpul anyar.

Kita butuh cara kanggo migrasi pods saka simpul lawas kanthi apik lan mesthekake yen ora ana proses buruh sing mlaku nalika kita nggawe owah-owahan ing simpul kasebut. Utawa nalika kita nindakake panggantos lengkap kluster, kaya ing conto (yaiku, kita ngganti gambar VM), kita pengin nransfer aplikasi sing mlaku saka kelenjar lawas menyang anyar. Ing kasus loro kasebut, kita pengin nyegah polong anyar supaya ora dijadwalake ing simpul lawas, banjur ngusir kabeh polong sing mlaku. Kanggo nggayuh tujuan kasebut, kita bisa nggunakake perintah kasebut kubectl drain.

Distribusi maneh kabeh polong saka simpul

Operasi saluran ngidini sampeyan nyebarake kabeh polong saka simpul. Sajrone eksekusi saluran, simpul ditandhani minangka ora bisa dijadwal (flag NoSchedule). Iki ngalangi polong anyar saka katon ing. Banjur saluran wiwit ngusir polong saka simpul, mateni wadhah sing saiki mlaku ing simpul kanthi ngirim sinyal TERM wadhah ing pod.

Senajan kubectl drain bakal nindakake tugas sing apik kanggo ngusir polong, ana rong faktor liyane sing bisa nyebabake operasi saluran gagal:

• Aplikasi sampeyan kudu bisa mungkasi kanthi apik nalika diajukake TERM sinyal. Nalika pods digusur, Kubernetes ngirim sinyal TERM kontaner lan ngenteni wong-wong mau mandheg sajrone wektu sing ditemtokake, sawise iku, yen ora mandheg, mandheg kanthi paksa. Ing kasus apa wae, yen wadhah sampeyan ora ngerteni sinyal kasebut kanthi bener, sampeyan isih bisa mateni pod kanthi ora bener yen lagi mlaku (contone, transaksi database lagi ditindakake).
• Sampeyan bakal kelangan kabeh pods sing ngemot aplikasi sampeyan. Bisa uga ora kasedhiya nalika kontaner anyar diluncurake ing simpul anyar, utawa yen pod sampeyan dipasang tanpa pengontrol, bisa uga ora diwiwiti maneh.

Nyingkiri downtime

Kanggo nyilikake downtime saka gangguan sukarela, kayata saka operasi saluran ing simpul, Kubernetes nyedhiyakake opsi nangani kegagalan ing ngisor iki:

• Pengakhiran anggun
• Pancing siklus urip
• PodDisruptionBudgets

Ing seri liyane, kita bakal nggunakake fitur Kubernetes iki kanggo nyuda pengaruh migrasi pods. Kanggo luwih gampang ngetutake gagasan utama, kita bakal nggunakake conto ing ndhuwur kanthi konfigurasi sumber daya ing ngisor iki:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Konfigurasi iki minangka conto minimal Deployment, sing ngatur pods nginx ing kluster. Kajaba iku, konfigurasi nggambarake sumber daya Service, sing bisa digunakake kanggo ngakses pod nginx ing kluster.

Saindhenging siklus, kita bakal nggedhekake konfigurasi iki supaya pungkasane nyakup kabeh kapabilitas sing diwenehake Kubernetes kanggo nyuda downtime.

Kanggo versi nganyari kluster Kubernetes sing wis dileksanakake lan dites kanthi wektu nol ing AWS lan liyane, bukak Gruntwork.io.

Uga maca artikel liyane ing blog kita:

• Zero Downtime Deployment lan Database
• Kubernetes: kenapa penting banget kanggo nyetel manajemen sumber daya sistem?
• Tekton Pipeline - Kubernetes-native pipelines
• Mbangun modul dinamis kanggo Nginx
• Pambuka kanggo Wewenang Kubernetes Konsul Hashicorp
• Apa migrasi saka ClickHouse tanpa wewenang kanggo ClickHouse kanthi wewenang?

Source: www.habr.com