Надградба на Kubernetes кластер без прекини

Процес на надградба за вашиот кластер Kubernetes

Во одреден момент, кога се користи кластерот Kubernetes, има потреба да се ажурираат тековните јазли. Ова може да вклучува ажурирања на пакети, ажурирања на кернелот или распоредување на нови слики од виртуелната машина. Во терминологијата на Кубернет, ова се нарекува „Доброволно нарушување“.

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

1. Овој пост.
2. Правилно исклучување на мешунките во кластерот Kubernetes
3. Одложено завршување на подлогата кога е избришана
4. Како да избегнете прекин на кластерот на Kubernetes користејќи PodDisruptionBudgets

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

Во оваа статија, ќе ги опишеме сите алатки што ги обезбедува Kubernetes за да постигне нула прекини за јазлите што работат во вашиот кластер.

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

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

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

Да почнеме со две подлоги со Nginx и Service кои работат на нашите два кластерни јазли Kubernetes.

Сакаме да ја ажурираме верзијата на јадрото на два работнички јазли во нашиот кластер. Како го правиме ова? Едноставно решение би било да се подигнат нови јазли со ажурираната конфигурација и потоа да се исклучат старите јазли додека се стартуваат новите. Иако ова ќе функционира, ќе има неколку проблеми со овој пристап:

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

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

Прераспределување на сите мешунки од јазол

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

Иако kubectl drain ќе направи одлична работа за иселување на мешунките, има два други фактори кои можат да предизвикаат неуспех на одводната работа:

• Вашата апликација мора да може благодатно да се прекине по поднесувањето TERM сигнал. Кога мешунките се иселуваат, Кубернетес испраќа сигнал TERM контејнери и чека да застанат одредено време, по што, доколку не застанале, насилно ги прекинува. Во секој случај, ако вашиот контејнер не го перцепира сигналот правилно, сè уште можете погрешно да ги изгасите мешунките ако моментално работат (на пример, во тек е трансакција со база на податоци).
• Ги губите сите мешунки што ја содржат вашата апликација. Можеби нема да биде достапно кога се лансираат нови контејнери на нови јазли или ако вашите подлоги се распоредени без контролери, тие може воопшто да не се рестартираат.

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

За да се минимизира времето на застој од доброволно прекинување, како на пример од операција на одвод на јазол, Kubernetes ги обезбедува следниве опции за справување со дефекти:

• Благодатно раскинување
• Куки за животниот циклус
• PodDisruptionBudgets

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

Во текот на циклусот, повторливо ќе ја прошириме оваа конфигурација, така што на крајот ќе ги вклучи сите можности што ги обезбедува Kubernetes за намалување на времето на застој.

За целосно имплементирана и тестирана верзија на ажурирања на кластерот Kubernetes за нула прекини на AWS и пошироко, посетете Gruntwork.io.

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

• Распоредување и бази на податоци со нула прекини
• Kubernetes: зошто е толку важно да се постави системско управување со ресурсите?
• Тектон гасовод - цевководи од Кубернетес
• Градење динамични модули за Nginx
• Вовед во овластувањето Kubernetes на конзулот Hashicorp
• До што доведе миграцијата од ClickHouse без овластување во ClickHouse со овластување?

Извор: www.habr.com