🥇Пет пропуска при внедряване на първото приложение на Kubernetes

Fail от Aris Dreamer

Много хора смятат, че е достатъчно да прехвърлите приложението в Kubernetes (с помощта на Helm или ръчно) - и ще има щастие. Но не всичко е толкова просто.

Отбор Облачни решения на Mail.ru преведе статия от инженера на DevOps Джулиан Гинди. Той разказва с какви клопки се е сблъскала неговата компания по време на процеса на миграция, за да не стъпите на същото гребло.

Първа стъпка: Настройте заявки и ограничения за Pod

Нека започнем, като създадем чиста среда, в която нашите капсули ще работят. Kubernetes е страхотен в планирането на pod и при отказ. Но се оказа, че планировчикът понякога не може да постави под, ако е трудно да прецени колко ресурси са му необходими, за да работи успешно. Това е мястото, където изскачат заявки за ресурси и ограничения. Има много дебати относно най-добрия подход за определяне на заявки и лимити. Понякога изглежда, че това наистина е повече изкуство, отколкото наука. Ето нашия подход.

Под заявки е основната стойност, използвана от планировчика за оптимално поставяне на под.

На Документация на Kubernetes: Стъпката на филтъра дефинира набор от възли, където може да бъде планиран Pod. Например филтърът PodFitsResources проверява дали даден възел има достатъчно ресурси, за да удовлетвори конкретни заявки за ресурси от под.

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

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

Ограничения на под е по-ясна граница за под. Той представлява максималното количество ресурси, които клъстерът ще разпредели към контейнера.

Отново от официална документация: Ако контейнерът има ограничение на паметта от 4 GiB, тогава kubelet (и времето за изпълнение на контейнера) ще го наложат. Времето за изпълнение не позволява на контейнера да използва повече от указаното ограничение на ресурсите. Например, когато процес в контейнер се опита да използва повече от разрешеното количество памет, системното ядро прекратява процеса с грешка „недостиг на памет“ (OOM).

Един контейнер винаги може да използва повече ресурси, отколкото е посочено в заявката за ресурс, но никога не може да използва повече от ограничението. Тази стойност е трудно да се зададе правилно, но е много важна.

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

За съжаление не мога да дам конкретни инструкции какви стойности да зададем, но ние самите се придържаме към следните правила:

Използвайки инструмент за тестване на натоварването, ние симулираме базово ниво на трафик и наблюдаваме използването на ресурсите на pod (памет и процесор).
Задайте заявките на pod на произволно ниска стойност (с ограничение на ресурса от около 5 пъти стойността на заявките) и наблюдавайте. Когато заявките са на твърде ниско ниво, процесът не може да стартира, което често причинява загадъчни грешки при изпълнение на Go.

Отбелязвам, че по-високите ограничения на ресурсите правят планирането по-трудно, тъй като pod се нуждае от целеви възел с достатъчно налични ресурси.

Представете си ситуация, в която имате лек уеб сървър с много високо ограничение на ресурсите, като например 4 GB памет. Този процес вероятно ще трябва да бъде мащабиран хоризонтално и всеки нов pod ще трябва да бъде планиран на възел с най-малко 4 GB налична памет. Ако не съществува такъв възел, клъстерът трябва да въведе нов възел, за да обработи този под, което може да отнеме известно време. Важно е да се постигне минимална разлика между заявките за ресурси и ограниченията, за да се осигури бързо и плавно мащабиране.

Стъпка втора: Настройте тестове за жизненост и готовност

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

Жизненост показва дали контейнерът работи. Ако не успее, kubelet убива контейнера и политиката за рестартиране е активирана за него. Ако контейнерът не е оборудван с Liveness Probe, тогава състоянието по подразбиране ще бъде успех - както е посочено в Документация на Kubernetes.

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

Ако зададете опцията да се изпълнява всяка секунда, това ще добави 1 заявка в секунда, така че имайте предвид, че ще са необходими допълнителни ресурси за обработка на този трафик.

В нашата компания тестовете на Liveness тестват основните компоненти на приложението, дори ако данните (например от отдалечена база данни или кеш) не са напълно налични.

Настроихме „здравословна“ крайна точка в приложенията, която просто връща код за отговор 200. Това е индикатор, че процесът работи и може да обработва заявки (но все още не и трафик).

тест Готовност показва дали контейнерът е готов да обслужва заявки. Ако проверката за готовност е неуспешна, контролерът на крайна точка премахва IP адреса на pod от крайните точки на всички услуги, съответстващи на pod. Това също е посочено в документацията на Kubernetes.

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

Има много дебати в общността дали да се осъществява директен достъп до базата данни. Имайки предвид режийните разходи (проверките са чести, но могат да бъдат контролирани), решихме, че за някои приложения готовността за обслужване на трафик се отчита само след проверка дали записите се връщат от базата данни. Добре проектираните изпитания за готовност гарантират по-високи нива на наличност и елиминират прекъсванията по време на внедряването.

Ако решите да направите заявка в базата данни, за да тествате готовността на вашето приложение, уверете се, че е възможно най-евтино. Нека вземем тази заявка:

SELECT small_item FROM table LIMIT 1

Ето пример за това как конфигурираме тези две стойности в Kubernetes:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

Можете да добавите някои допълнителни опции за конфигурация:

initialDelaySeconds - колко секунди ще минат между изстрелването на контейнера и началото на изстрелването на сондите.
periodSeconds — интервал на изчакване между пробите.
timeoutSeconds — броя секунди, след които капсулата се счита за аварийна. Нормален таймаут.
failureThreshold е броят на неуспешните тестове, преди да бъде изпратен сигнал за рестартиране към групата.
successThreshold е броят на успешните опити преди подът да премине в състояние на готовност (след повреда, когато подът се стартира или възстанови).

Стъпка трета: Задаване на мрежовите правила по подразбиране на Pod

Kubernetes има "плоска" мрежова топография, по подразбиране всички модули комуникират директно един с друг. В някои случаи това не е желателно.

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

Например, следното е проста политика, която отказва целия входящ трафик за определено пространство от имена:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

Визуализация на тази конфигурация:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Повече подробности тук.

Четвърта стъпка: Персонализирано поведение с кукички и инициализиращи контейнери

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

Особени трудности възникнаха с Nginx. Забелязахме, че при последователно разполагане на тези Pods, активните връзки бяха прекъснати, преди да завършат успешно.

След задълбочено проучване в интернет се оказа, че Kubernetes не изчаква Nginx връзките да се изчерпят, преди да изключи pod. С помощта на куката за предварително спиране внедрихме следната функционалност и напълно се отървахме от времето на престой:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

Но nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

Друга изключително полезна парадигма е използването на init контейнери за справяне със стартирането на конкретни приложения. Това е особено полезно, ако имате ресурсоемък процес на миграция на база данни, който трябва да се стартира преди стартирането на приложението. Можете също така да зададете по-високо ограничение на ресурсите за този процес, без да задавате такова ограничение за основното приложение.

Друга често срещана схема е достъп до тайни в init контейнера, който предоставя тези идентификационни данни на главния модул, което предотвратява неоторизиран достъп до тайни от самия основен модул на приложението.

Както обикновено, цитат от документацията: init контейнерите безопасно изпълняват потребителски код или помощни програми, които иначе биха компрометирали сигурността на изображението на контейнера на приложението. Като държите ненужните инструменти отделно, вие ограничавате повърхността за атака на изображението на контейнера на приложението.

Стъпка пета: Конфигурация на ядрото

И накрая, нека поговорим за една по-модерна техника.

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

Kubernetes обаче ви позволява да стартирате привилегирован контейнер, който променя само параметрите на ядрото за конкретен pod. Ето какво използвахме, за да променим максималния брой отворени връзки:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

Това е по-модерна техника, която често не е необходима. Но ако вашето приложение се бори да се справи с голямо натоварване, можете да опитате да промените някои от тези настройки. Повече информация за този процес и задаване на различни стойности - както винаги в официалната документация.

В заключение

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

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

Бъдете реалисти относно очаквания трафик и се опитайте да го надхвърлите, за да видите кои компоненти се повреждат първи. С този итеративен подход само няколко от изброените препоръки може да са достатъчни за постигане на успех. Или може да е необходимо по-задълбочено персонализиране.

Винаги си задавайте следните въпроси:

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

Kubernetes предоставя невероятна платформа, която ви позволява да използвате най-добрите практики за внедряване на хиляди услуги в клъстер. Всички приложения обаче са различни. Понякога изпълнението изисква малко повече работа.

За щастие, Kubernetes предоставя необходимите настройки за постигане на всички технически цели. Чрез използване на комбинация от заявки за ресурси и ограничения, сонди за Liveness и Readiness, init контейнери, мрежови политики и персонализирана настройка на ядрото, можете да постигнете висока производителност заедно с толерантност към грешки и бърза мащабируемост.

Какво друго да прочетете:

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

Пет пропуска при внедряване на първото приложение на Kubernetes