ProHoster > Blog > башкаруу > Kubernetes кластерин иштебей туруп жаңылоо

Kubernetes кластерин иштебей туруп жаңылоо

Kubernetes кластерин иштебей туруп жаңылоо

Kubernetes кластериңизди жаңыртуу процесси

Кээ бир учурда, Kubernetes кластерин колдонууда, иштеп жаткан түйүндөрдү жаңыртуу зарылчылыгы бар. Бул пакет жаңыртууларын, ядро ​​жаңыртууларын же жаңы виртуалдык машинанын сүрөттөрүн жайылтууну камтышы мүмкүн. Kubernetes терминологиясында бул деп аталат "Ыктыярдуу бузуу".

Бул пост 4 посттук сериянын бир бөлүгү:

  1. Бул пост.
  2. Kubernetes кластериндеги поддондорду туура өчүрүү
  3. Подгон жок кылынганда, анын кечигип бүтүшү
  4. PodDisruptionBudgets аркылуу Kubernetes кластеринин иштебей калышынан кантип сактанса болот

(болжол менен жакынкы келечекте сериядагы калган макалалардын котормолорун күтөбүз)

Бул макалада биз сиздин кластериңизде иштеген түйүндөр үчүн нөлдүк токтоп калууга жетишүү үчүн Kubernetes камсыз кылган бардык куралдарды сүрөттөп беребиз.

маселени аныктоо

Биз адегенде жөнөкөй мамиле жасайбыз, көйгөйлөрдү аныктайбыз жана бул ыкманын мүмкүн болуучу тобокелдиктерин баалайбыз жана цикл бою кезиккен ар бир көйгөйлөрдү чечүү үчүн билимдерди түзөбүз. Натыйжа – биздин нөлдүк токтоп калуу максатыбызга жетүү үчүн жашоо циклинин илгичтерин, даярдык текшерүүлөрүн жана Pod үзгүлтүккө учуратуу бюджеттерин колдонгон конфигурация.

Саякатыбызды баштоо үчүн конкреттүү бир мисалды алалы. Келгиле, бизде эки түйүндөн турган Kubernetes кластери бар дейли, анда тиркеме артында жайгашкан эки уяча менен иштеп жатат. Service:

Kubernetes кластерин иштебей туруп жаңылоо

Келгиле, Nginx жана Кызматы бар эки поддондон баштайлы, биздин эки Kubernetes кластердик түйүндөрүбүздө иштейт.

Биз кластерибиздеги эки жумушчу түйүндөрдүн ядро ​​версиясын жаңырткыбыз келет. Муну кантип кылабыз? Жөнөкөй чечим жаңыланган конфигурация менен жаңы түйүндөрдү жүктөө, анан жаңы түйүндөрдү баштоодо эски түйүндөрдү өчүрүү. Бул иштесе да, бул ыкма менен бир нече көйгөйлөр пайда болот:

  • Эски түйүндөрдү өчүргөнүңүздө, аларда иштеген поддондор да өчүрүлөт. Капчыктарды кооз өчүрүү үчүн тазалоо керек болсочы? Сиз колдонуп жаткан виртуалдаштыруу системасы тазалоо процессинин аягына чыгышын күтпөшү мүмкүн.
  • Эгер сиз бир эле учурда бардык түйүндөрдү өчүрсөңүз эмне болот? Поджиктер жаңы түйүндөргө өткөндө, сиз жакшы иштебей каласыз.

Биз түйүнгө өзгөртүүлөрдү киргизип жаткан учурда жумушчу процесстерибиздин бири да иштебей турганын камсыз кылуу менен эски түйүндөрдөн поддондорду кылдаттык менен көчүрүүнүн жолу керек. Же мисалдагыдай кластерди толук алмаштырганыбызда (б.а. VM сүрөттөрүн алмаштырабыз), иштеп жаткан тиркемелерди эски түйүндөрдөн жаңыларына өткөргүбүз келет. Эки учурда тең, биз эски түйүндөрдө жаңы подкасттардын пландаштырылышына жол бербөөнү, андан кийин алардан бардык иштеп жаткан поддондорду чыгарып салгыбыз келет. Бул максаттарга жетүү үчүн биз буйрук колдоно аласыз kubectl drain.

Түйүндөн бардык подкасттарды кайра бөлүштүрүү

Дренаж операциясы бир түйүндөгү бардык уячаларды кайра бөлүштүрүүгө мүмкүндүк берет. Дренажды аткаруу учурунда түйүн пландаштырылбаган деп белгиленет (желек NoSchedule). Бул анын үстүндө жаңы кабыктардын пайда болушуна жол бербейт. Андан кийин дренаж түйүндөн кабыктарды чыгара баштайт, сигнал жөнөтүү менен учурда түйүндө иштеп жаткан контейнерлерди өчүрөт. TERM идиштеги контейнерлер.

да kubectl drain кабыктарды чыгарууда чоң жумуш аткарат, дренаждын иштебей калышына дагы эки фактор себеп болот:

  • Колдонмоңуз берилгенден кийин акырындык менен токтотулушу керек TERM сигнал. Капчыктар чыгарылганда, Кубернетес сигнал жөнөтөт TERM контейнерлерди жана алардын белгиленген убакыттын ичинде токтошу үчүн күтөт, андан кийин, эгерде алар токтобосо, аларды мажбурлап токтотот. Кандай болгон күндө да, эгерде сиздин контейнериңиз сигналды туура кабыл албаса, сиз дагы эле, эгерде алар учурда иштеп жатса (мисалы, маалымат базасы транзакциясы аткарылып жатат) туура эмес өчүрө аласыз.
  • Колдонмоңузду камтыган бардык подкасттарды жоготосуз. Жаңы түйүндөрдө жаңы контейнерлер ишке киргизилгенде, ал жеткиликсиз болушу мүмкүн, же сиздин подъездиңиз контроллерсуз жайгаштырылса, алар такыр өчүрүлбөй калышы мүмкүн.

токтоп калуудан качуу

Түйүндөгү дренаждык операция сыяктуу ыктыярдуу үзгүлтүккө учураган токтоп калууларды азайтуу үчүн, Kubernetes төмөнкү каталарды чечүү жолдорун сунуштайт:

Сериянын калган бөлүгүндө биз көчүп бара жаткан капчыктардын таасирин азайтуу үчүн бул Kubernetes функцияларын колдонобуз. Негизги идеяны аткарууну жеңилдетүү үчүн, биз жогорудагы мисалыбызды төмөнкү ресурс конфигурациясы менен колдонобуз:

---
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, ал кластердеги nginx поддондорун башкарат. Мындан тышкары, конфигурация ресурсту сүрөттөйт Service, аны кластердеги nginx подкектерине жетүү үчүн колдонсо болот.

Цикл бою биз бул конфигурацияны кайра-кайра кеңейтебиз, акыры ал Kubernetes токтоп калуу убактысын кыскартуу үчүн берген бардык мүмкүнчүлүктөрдү камтыйт.

AWS жана андан тышкаркы жерлерде нөл үзгүлтүккө учуратуу үчүн Kubernetes кластердик жаңыртууларынын толук ишке ашырылган жана сыналган версиясын көрүү үчүн, баш багыңыз Gruntwork.io.

Биздин блогдогу башка макалаларды да окуңуз:

Source: www.habr.com

Комментарий кошуу