ProHoster > Blog > Ma'muriyat > Kubernetes klasterini uzilishlarsiz yangilash

Kubernetes klasterini uzilishlarsiz yangilash

Kubernetes klasterini uzilishlarsiz yangilash

Kubernetes klasteringiz uchun yangilanish jarayoni

Bir nuqtada, Kubernetes klasteridan foydalanganda, ishlaydigan tugunlarni yangilash kerak bo'ladi. Bunga paket yangilanishlari, yadro yangilanishlari yoki yangi virtual mashina tasvirlarini joylashtirish kiradi. Kubernetes terminologiyasida bu deyiladi "Ixtiyoriy buzilish".

Bu post 4 postlik turkumning bir qismidir:

  1. Bu post.
  2. Kubernetes klasteridagi podlarni to'g'ri o'chirish
  3. Pod o'chirilganda uni kechiktirish
  4. PodDisruptionBudgets-dan foydalanib, Kubernetes klasterining ishlamay qolishidan qanday qochish kerak

(taxminan. Yaqin kelajakda turkumdagi qolgan maqolalarning tarjimasini kuting)

Ushbu maqolada biz Kubernetes sizning klasteringizda ishlaydigan tugunlar uchun nol ish vaqtiga erishish uchun taqdim etadigan barcha vositalarni tasvirlab beramiz.

Muammoni aniqlang

Biz dastlab sodda yondoshamiz, muammolarni aniqlaymiz va ushbu yondashuvning mumkin bo'lgan xavflarini baholaymiz va tsikl davomida duch keladigan har bir muammolarni hal qilish uchun bilimlarni shakllantiramiz. Natijada, nol ishlamay qolish maqsadiga erishish uchun hayot aylanish ilgaklari, tayyorlik zondlari va Podni buzish byudjetlaridan foydalanadigan konfiguratsiya paydo bo'ldi.

Sayohatimizni boshlash uchun keling, aniq bir misol keltiraylik. Aytaylik, bizda ikkita tugundan iborat Kubernetes klasteri bor, unda ilova orqasida joylashgan ikkita podkast bilan ishlaydi. Service:

Kubernetes klasterini uzilishlarsiz yangilash

Keling, ikkita Kubernetes klaster tugunlarida ishlaydigan Nginx va Service bilan ikkita podkastdan boshlaylik.

Biz klasterimizdagi ikkita ishchi tugunning yadro versiyasini yangilamoqchimiz. Buni qanday qilamiz? Oddiy yechim yangilangan konfiguratsiyaga ega yangi tugunlarni yuklash va keyin yangilarini ishga tushirishda eski tugunlarni o'chirishdir. Bu ishlayotgan bo'lsa-da, bu yondashuv bilan bir nechta muammolar bo'ladi:

  • Qadimgi tugunlarni o'chirsangiz, ularda ishlaydigan podalar ham o'chiriladi. Chiroyli o'chirish uchun podlarni tozalash kerak bo'lsa-chi? Siz foydalanayotgan virtualizatsiya tizimi tozalash jarayoni tugashini kutmasligi mumkin.
  • Agar bir vaqtning o'zida barcha tugunlarni o'chirib qo'ysangiz nima bo'ladi? Podkalar yangi tugunlarga o'tganda, siz munosib ishlamay qolasiz.

Tugunga oβ€˜zgartirishlar kiritayotganimizda ishchi jarayonlarimiz ishlamasligiga ishonch hosil qilib, eski tugunlardan podkastlarni oqilona koβ€˜chirish usuli kerak. Yoki biz misoldagi kabi klasterni to'liq almashtirishni amalga oshirganimizda (ya'ni, biz VM tasvirlarini almashtiramiz), biz ishlaydigan ilovalarni eski tugunlardan yangilariga o'tkazmoqchimiz. Ikkala holatda ham biz eski tugunlarda yangi podslarni rejalashtirishni oldini olishni va keyin barcha ishlaydigan podlarni ulardan chiqarib tashlashni xohlaymiz. Ushbu maqsadlarga erishish uchun biz buyruqni ishlatishimiz mumkin kubectl drain.

Tugundan barcha podlarni qayta taqsimlash

Drenaj operatsiyasi tugundagi barcha podlarni qayta taqsimlash imkonini beradi. Drenajni bajarish paytida tugun rejalashtirilmagan deb belgilanadi (bayroq NoSchedule). Bu uning ustida yangi podalar paydo bo'lishining oldini oladi. Shundan so'ng, drenaj tugundan podkalarni chiqara boshlaydi, signal yuborish orqali tugun ustida ishlayotgan konteynerlarni o'chiradi. TERM idishdagi idishlar.

Garchi kubectl drain podkastlarni quvib chiqarishda juda yaxshi ishni bajaradi, drenaj ishini muvaffaqiyatsizlikka olib kelishi mumkin bo'lgan yana ikkita omil mavjud:

  • Sizning arizangiz topshirilgandan so'ng yaxshi tarzda tugatilishi kerak TERM signal. Qopqoqlar chiqarib yuborilganda, Kubernetes signal yuboradi TERM konteynerlar va ularning belgilangan vaqt davomida to'xtashini kutadi, shundan so'ng ular to'xtamagan bo'lsa, ularni majburan tugatadi. Har qanday holatda, konteyneringiz signalni to'g'ri qabul qilmasa, siz hali ham podslarni noto'g'ri o'chirib qo'yishingiz mumkin, agar ular hozirda ishlayotgan bo'lsa (masalan, ma'lumotlar bazasi tranzaksiyasi amalga oshirilmoqda).
  • Siz ilovangizni o'z ichiga olgan barcha podlarni yo'qotasiz. Yangi tugunlarda yangi konteynerlar ishga tushirilganda u mavjud bo'lmasligi mumkin yoki podslaringiz kontrollerlarsiz o'rnatilgan bo'lsa, ular umuman qayta ishga tushmasligi mumkin.

To'xtab qolishning oldini olish

Tugundagi drenaj operatsiyasi kabi ixtiyoriy uzilishlar natijasida ishlamay qolish vaqtini minimallashtirish uchun Kubernetes quyidagi nosozliklarni bartaraf etish variantlarini taqdim etadi:

Seriyaning qolgan qismida biz migratsiya podkastlarining ta'sirini yumshatish uchun ushbu Kubernetes xususiyatlaridan foydalanamiz. Asosiy g'oyaga amal qilishni osonlashtirish uchun biz yuqoridagi misolimizdan quyidagi manba konfiguratsiyasi bilan foydalanamiz:

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

Ushbu konfiguratsiya minimal misoldir Deployment, bu klasterdagi nginx podslarini boshqaradi. Bundan tashqari, konfiguratsiya resursni tavsiflaydi Service, bu klasterdagi nginx podslariga kirish uchun ishlatilishi mumkin.

Butun tsikl davomida biz ushbu konfiguratsiyani takroriy kengaytiramiz, shunda u oxir-oqibat Kubernetes ishlamay qolish vaqtini qisqartirish uchun taqdim etadigan barcha imkoniyatlarni o'z ichiga oladi.

AWS va undan tashqarida nol ishlamay qolish uchun Kubernetes klaster yangilanishlarining toΚ»liq tatbiq etilgan va sinovdan oΚ»tgan versiyasi uchun tashrif buyuring. Gruntwork.io.

Shuningdek, bizning blogimizdagi boshqa maqolalarni o'qing:

Manba: www.habr.com

a Izoh qo'shish