ProHoster > блог > адміністраванне > Абнаўленне Kubernetes-кластара без прастою

Абнаўленне Kubernetes-кластара без прастою

Абнаўленне Kubernetes-кластара без прастою

Працэс абнаўлення для вашага Kubernetes-кластара

У нейкі момант пры выкарыстанні кластара Kubernetes узнікае запатрабаванне ў абнаўленні працавальных нод. Яно можа ўключаць у сябе абнаўленні пакетаў, абнаўленне ядра ці разгортванне новых выяў віртуальных машын. У тэрміналогіі Kubernetes гэта называецца "Voluntary Disruption".

Гэты пост з'яўляецца часткай цыкла з 4 пастоў:

  1. Гэты пост.
  2. Карэктнае завяршэнне працы pod'аў у Kubernetes-кластары
  3. Адкладзенае завяршэнне pod'а пры ім выдаленні
  4. Як пазбегнуць прастою ў працы Kubernetes-кластара пры дапамозе PodDisruptionBudgets

(заўв. зав. пераклады астатніх артыкулаў цыклу чакайце хуткім часам)

У гэтым артыкуле мы будзем апісваць усе інструменты, якія дае Kubernetes для дасягнення нулявога часу прастою для якія працуюць у вашым кластары нод.

вызначэнне праблемы

Спачатку мы будзем выкарыстоўваць наіўны падыход, вызначаць праблемы і ацэньваць патэнцыйныя рызыкі гэтага падыходу і назапашваць веды для вырашэння кожнай з праблем, з якімі сустрэнемся на працягу ўсяго цыкла. У выніку мы атрымаем канфігурацыю, у якой выкарыстоўваюцца lifecycle hooks, readiness probes і Pod disruption budgets для дасягнення нашага нулявога часу прастою.

Каб пачаць наш шлях, давайце возьмем пэўны прыклад. Дапушчальны, у нас ёсць кластар Kubernetes з двух нод, у якім запушчана дадатак з двума pod'aмі, якія знаходзяцца за Service:

Абнаўленне Kubernetes-кластара без прастою

Пачнём з двух pod'аў з Nginx і Service запушчаных на нашых двух нодах Kubernetes-кластара.

Мы жадаем абнавіць версію ядра двух працоўных нод у нашым кластары. Як мы гэта зробім? Простым рашэннем было б загрузіць новыя ноды з абноўленай канфігурацыяй і затым выключыць старыя ноды, адначасова з запускам новых. Хаця гэта спрацуе, будзе некалькі праблем з такім падыходам:

  • Калі вы выключыце старыя ноды, то запушчаныя на іх pod'ы гэтак жа будуць выключаны. Што калі pod'ы трэба ачысціць для карэктнага адключэння? Сістэма віртуалізацыі, якую вы выкарыстоўваеце, можа не дачакацца заканчэння працэсу ачысткі.
  • Што калі вы адключыце ўсе ноды адначасова? Вы атрымаеце прыстойны просты пакуль pod'ы пераедуць на новыя ноды.

Нам патрэбен спосаб карэктнай міграцыі pod'аў са старых нод і пры гэтым трэба быць упэўненымі, што ніводны з нашых працоўных працэсаў не запушчаны, пакуль мы ўносім змены для ноды. Або калі мы робім поўную замену кластара, як у прыкладзе(гэта значыць заменны выявы VM), мы жадаем перанесці працавальныя прыкладанні са старых нод на новыя. У абодвух выпадках мы жадаем прадухіліць планаванне новых pod'аў на старых нодах, а затым выселіць з іх усе запушчаныя pod'ы. Для дасягнення гэтых мэт мы можам выкарыстоўваць каманду kubectl drain.

Пераразмеркаванне ўсіх pod'аў з ноды

Аперацыя drain дазваляе пераразмеркаваць усе pod'ы з ноды. У працэсе выканання drain нода пазначаецца як unschedulable (сцяг) NoSchedule). Гэта прадухіляе з'яўленне на ёй новых pod'аў. Затым drain пачынае высяляць pod'ы з ноды, завяршае працу кантэйнераў, якія на дадзены момант запушчаны на нодзе адпраўляючы сігнал TERM кантэйнерам у pod'е.

хоць kubectl drain выдатна зладзіцца з высяленнем pod'ов, ёсць яшчэ два фактары, якія могуць стаць чыннікам збою пры выкананні аперацыі drain:

  • Ваша прыкладанне павінна ўмець карэктна завяршацца пры падачы TERM сігналу. Калі pod'ы высяляюцца, Kubernetes адпраўляе сігнал TERM кантэйнерам і чакае іх прыпынку зададзеную колькасць часу, пасля чаго, калі яны не спыніліся, завяршае іх прымусова. У любым выпадку, калі Ваш кантэйнер не ўспрыме сігнал карэктна, вы ўсё яшчэ можаце патушыць pod'ы некарэктна, калі яны ў дадзены пэўны момант працуюць (напрыклад, выконваецца транзакцыя ў БД).
  • Вы губляеце ўсе pod'ы, у якіх змяшчаецца ваша дадатак. Яно можа быць недаступна на момант запуску новых кантэйнераў на новых нодах ці, калі вашы pod'ы разгорнутыя без кантролераў, яны могуць не перазапусціцца ў прынцыпе.

Пазбягаем прастою

Каб мінімізаваць час прастою ад voluntary disruption, як, напрыклад, ад аперацыі drain для ноды, Kubernetes дае наступныя варыянты апрацоўкі збояў:

У астатніх частках цыклу мы будзем выкарыстоўваць дадзеныя функцыі Kubernetes для змякчэння наступстваў пераносу pod'ов. Каб было лягчэй прасачыць асноўную думку, мы будзем выкарыстоўваць наш прыклад вышэй з наступнай рэсурснай канфігурацыяй:

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

Гэтая канфігурацыя з'яўляецца мінімальным прыкладам Deployment, які кіруе pod'амі nginx у кластары. Акрамя таго, канфігурацыя апісвае рэсурс Service, які можна выкарыстоўваць для доступу да pod'ам nginx у кластары.

На працягу ўсяго цыклу мы будзем ітэратыўна пашыраць дадзеную канфігурацыю, каб у фінале яна складалася з усе магчымасці, якія прадстаўляюцца Kubernetes для памяншэння часу прастою.

Каб атрымаць цалкам укаранёную і пратэставаную версію абнаўленняў кластара Kubernetes для нулявога часам прастою на AWS і іншых рэсурсах, наведайце Gruntwork.io.

Таксама чытайце іншыя артыкулы ў нашым блогу:

Крыніца: habr.com

Дадаць каментар