Надграждане на Kubernetes клъстер без престой

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

В даден момент, когато използвате клъстер Kubernetes, има нужда от актуализиране на работещи възли. Това може да включва актуализации на пакети, актуализации на ядрото или внедряване на нови изображения на виртуална машина. В терминологията на Kubernetes това се нарича „Доброволно прекъсване“.

Тази публикация е част от поредица от 4 публикации:

1. Тази публикация.
2. Правилно изключване на подове в клъстер на Kubernetes
3. Забавено прекратяване на група, когато тя бъде изтрита
4. Как да избегнете прекъсване на клъстера на Kubernetes с помощта на PodDisruptionBudgets

(приблизително. Очаквайте преводи на останалите статии от поредицата в близко бъдеще)

В тази статия ще опишем всички инструменти, които Kubernetes предоставя за постигане на нулев престой за възлите, работещи във вашия клъстер.

Определение на проблема

Първоначално ще възприемем наивен подход, ще идентифицираме проблемите и ще оценим потенциалните рискове от този подход и ще изградим знания за решаване на всеки от проблемите, които срещаме през целия цикъл. Резултатът е конфигурация, която използва куки за жизнения цикъл, сонди за готовност и бюджети за прекъсване на Pod, за да постигне нашата цел за нулев престой.

За да започнем нашето пътуване, нека вземем конкретен пример. Да кажем, че имаме клъстер на Kubernetes от два възела, в който се изпълнява приложение с две подове, разположени зад Service:

Нека започнем с две подове с Nginx и услуга, работещи на нашите два клъстерни възела Kubernetes.

Искаме да актуализираме версията на ядрото на два работни възела в нашия клъстер. Как да направим това? Едно просто решение би било да стартирате нови възли с актуализираната конфигурация и след това да изключите старите възли, докато стартирате новите. Въпреки че това ще работи, ще има няколко проблема с този подход:

• Когато изключите старите възли, подовете, работещи на тях, също ще бъдат изключени. Какво става, ако модулите трябва да бъдат изчистени за грациозно изключване? Системата за виртуализация, която използвате, може да не изчака процеса на почистване да завърши.
• Ами ако изключите всички възли едновременно? Ще получите приличен престой, докато модулите се преместят към нови възли.

Имаме нужда от начин за елегантно мигриране на подове от стари възли, като същевременно гарантираме, че нито един от нашите работни процеси не се изпълнява, докато правим промени в възела. Или когато правим пълна подмяна на клъстера, както в примера (т.е. заменяме VM изображения), искаме да прехвърлим работещи приложения от стари възли към нови. И в двата случая искаме да предотвратим планирането на нови подове на стари възли и след това да изгоним всички работещи подове от тях. За постигане на тези цели можем да използваме командата kubectl drain.

Преразпределяне на всички подове от възел

Операцията за източване ви позволява да преразпределите всички подове от възел. По време на изпълнение на източване възелът е маркиран като непланируем (флаг NoSchedule). Това предотвратява появата на нови шушулки върху него. След това drain започва да извежда подове от възела, изключва контейнерите, които в момента работят на възела, като изпраща сигнал TERM контейнери в шушулка.

Въпреки че kubectl drain ще свърши чудесна работа при изваждането на шушулките, има два други фактора, които могат да доведат до неуспех на операцията по източване:

• Вашето приложение трябва да може да се прекрати елегантно при подаване TERM сигнал. Когато капсулите са изгонени, Kubernetes изпраща сигнал TERM контейнери и ги изчаква да спрат за определено време, след което, ако не са спрели, ги прекратява принудително. Във всеки случай, ако вашият контейнер не възприема сигнала правилно, все пак можете да изключите подовете неправилно, ако те работят в момента (например, транзакция на база данни е в ход).
• Губите всички пакети, които съдържат вашето приложение. Може да не е наличен, когато се стартират нови контейнери на нови възли или ако вашите подове са разгърнати без контролери, те може изобщо да не се рестартират.

Избягване на престой

За да минимизира времето за престой от доброволно прекъсване, като например от операция за източване на възел, Kubernetes предоставя следните опции за обработка на откази:

• Грациозно прекратяване
• Куки за жизнения цикъл
• PodDisruptionBudgets

В останалата част от поредицата ще използваме тези функции на 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, който управлява nginx pods в клъстера. Освен това конфигурацията описва ресурса Service, който може да се използва за достъп до nginx pods в клъстер.

По време на цикъла ние ще разширяваме итеративно тази конфигурация, така че в крайна сметка да включва всички възможности, които Kubernetes предоставя за намаляване на времето за престой.

За напълно внедрена и тествана версия на актуализациите на клъстери на Kubernetes за нулев престой на AWS и извън него, посетете Gruntwork.io.

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

• Нулев престой при внедряване и бази данни
• Kubernetes: защо е толкова важно да настроите управление на системните ресурси?
• Tekton Pipeline - собствени тръбопроводи на Kubernetes
• Изграждане на динамични модули за Nginx
• Въведение в разрешението за Kubernetes на Hashicorp Consul
• До какво доведе миграцията от ClickHouse без авторизация към ClickHouse с авторизация?

Източник: www.habr.com