ПроХостер > блог > Администрација > Надоградња Кубернетес кластера без застоја

Надоградња Кубернетес кластера без застоја

Надоградња Кубернетес кластера без застоја

Процес надоградње за ваш Кубернетес кластер

У неком тренутку, када користите Кубернетес кластер, постоји потреба за ажурирањем покренутих чворова. Ово може укључивати ажурирања пакета, ажурирања кернела или примену нових слика виртуелне машине. У Кубернетес терминологији то се зове "Добровољно ометање".

Овај пост је део серије од 4 поста:

  1. Овај пост.
  2. Исправно гашење подова у Кубернетес кластеру
  3. Одложен завршетак под-а када се избрише
  4. Како избећи застоје Кубернетес кластера користећи ПодДисруптионБудгетс

(цца. Очекујте преводе преосталих чланака у серијалу у блиској будућности)

У овом чланку ћемо описати све алате које Кубернетес пружа за постизање нулте застоја за чворове који раде у вашем кластеру.

Дефинисање проблема

У почетку ћемо заузети наиван приступ, идентификовати проблеме и проценити потенцијалне ризике овог приступа и изградити знање за решавање сваког од проблема са којима се сусрећемо током циклуса. Резултат је конфигурација која користи куке животног циклуса, сонде спремности и буџете за прекиде у Поду да би се постигао циљ без застоја.

Да започнемо наше путовање, узмимо конкретан пример. Рецимо да имамо Кубернетес кластер од два чвора, у којем апликација ради са два под-а која се налазе иза Service:

Надоградња Кубернетес кластера без застоја

Почнимо са два под-а са Нгинк-ом и сервисом који раде на наша два Кубернетес чвора кластера.

Желимо да ажурирамо верзију кернела за два радна чвора у нашем кластеру. Како да ово урадимо? Једноставно решење би било да покренете нове чворове са ажурираном конфигурацијом, а затим искључите старе чворове док покрећете нове. Иако ће ово функционисати, биће неколико проблема са овим приступом:

  • Када искључите старе чворове, подови који раде на њима ће такође бити искључени. Шта ако је потребно очистити махуне ради грациозног искључивања? Систем виртуелизације који користите можда неће чекати да се заврши процес чишћења.
  • Шта ако искључите све чворове у исто време? Добићете пристојно време застоја док се махуне померају на нове чворове.

Потребан нам је начин да грациозно пренесемо подове са старих чворова, истовремено осигуравајући да ниједан од наших радних процеса није покренут док уносимо промене на чвор. Или када урадимо потпуну замену кластера, као у примеру (то јест, заменимо слике ВМ), желимо да пренесемо покренуте апликације са старих чворова на нове. У оба случаја, желимо да спречимо заказивање нових подова на старим чворовима, а затим избацимо све покренуте подове из њих. За постизање ових циљева можемо користити команду kubectl drain.

Прерасподела свих подова из чвора

Операција дренаже вам омогућава да прерасподелите све махуне из чвора. Током извршавања одвода, чвор је означен као непланиран (застава NoSchedule). Ово спречава појављивање нових махуна на њему. Затим драин почиње да избаци махуне из чвора, искључује контејнере који тренутно раде на чвору слањем сигнала TERM контејнери у махуни.

Мада kubectl drain ће обавити одличан посао избацивања махуна, постоје још два фактора који могу узроковати неуспех операције одвода:

  • Ваша пријава мора бити у могућности да се заврши грациозно након подношења TERM сигнал. Када су махуне исељене, Кубернетес шаље сигнал TERM контејнере и чека да се зауставе одређено време, након чега их, ако се нису зауставили, принудно укида. У сваком случају, ако ваш контејнер не перципира сигнал исправно, и даље можете погрешно угасити подове ако су тренутно покренути (на пример, трансакција базе података је у току).
  • Изгубили сте све капсуле које садрже вашу апликацију. Можда неће бити доступан када се нови контејнери покрећу на новим чворовима или ако су ваши подови распоређени без контролера, можда се уопште неће поново покренути.

Избегавање застоја

Да би се минимизирало време застоја услед добровољног прекида, као што је операција пражњења на чвору, Кубернетес пружа следеће опције за руковање грешкама:

У остатку серије, користићемо ове Кубернетес функције да бисмо ублажили утицај миграције подова. Да бисмо лакше пратили главну идеју, користићемо наш пример изнад са следећом конфигурацијом ресурса:

---
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, који управља нгинк подовима у кластеру. Поред тога, конфигурација описује ресурс Service, који се може користити за приступ нгинк подовима у кластеру.

Током циклуса, ми ћемо итеративно проширивати ову конфигурацију тако да она на крају укључује све могућности које Кубернетес пружа за смањење времена застоја.

За потпуно имплементирану и тестирану верзију ажурирања Кубернетес кластера за нула застоја на АВС-у и шире, посетите Грунтворк.ио.

Прочитајте и друге чланке на нашем блогу:

Извор: ввв.хабр.цом

Додај коментар