В интернет пространството има много справочни материали, но понякога най-ценни са най-простите съвети. Екипът преведе , които авторът на статията е събрал след година работа с Kubernetes. Съветите не са подредени по важност, но мислим, че всеки ще намери нещо полезно за себе си.
Най-простата команда в работата с Kubernetes
За начало, вероятно най-простото и полезно действие в работата с Kubernetes. Следващата команда включва автоматично допълнение на командите kubectl в bash обвивката:
echo "source > ~/ .bashrc
Автоматичното допълнение kubectl ще бъде записано в файла .bashrc и ще се активира автоматично всеки път при стартиране на обвивката. Това ускорява набиране на дълги команди и параметри, като например all-namespaces. Повече информация в .
Ограничения по подразбиране за памет и CPU в пространствата на имена
Ако приложение е написано неправилно, например, всяка секунда отваря ново съединение с базата данни, но никога не го затваря, то в клъстера случва изтичане на памет. И ако за приложението при деплой не е зададено ограничение на паметта, това може да доведе до срив на нода.
За да предотврати това, Kubernetes позволява задаването на ограничения по подразбиране за всяко пространство на име. Те се записват в yaml файл за конкретно пространство на име. Ето пример за такъв файл:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Създайте такъв yaml и приложете към всяко пространство на име. Например, към пространството на име limit-example. Сега за всеки контейнер, разположен в това пространство на име, ще важи лимит от 512Mi, освен ако за този контейнер не е зададен друг индивидуален лимит.
Премахване на боклука в старите версии на Kubernetes
Kubelet по подразбиране започва премахване на боклука, когато var/lib/docker заета 90% от наличното дисково пространство. Това е прекрасно, обаче, до версия Kubernetes 1.7 нямаше ограничение по подразбиране на количеството използвани индексни дескриптори inode (инодов), които отговарят на броя файлове във файловата система.
Потенциално вашият контейнер var/lib/docker може да използва само 50% от дисковото пространство, но в същото време inode-ите могат да свършат, което ще предизвика проблеми в работата на работниците.
В старите версии kubelet от 1.4 до 1.6, ще трябва да добавите такъв флаг:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
В версии 1.7 и более свежих версиях этот флаг установлен по умолчанию. Однако предыдущие версии не следят за лимитом инодов.
Minikube… малък, но мощен локален Kubernetes
Minikube е най-простият начин да стартирате локален кластер Kubernetes. Той се стартира с простата команда:
minikube start
В резултат на изпълнението на тази команда на компютъра ви работи истински кластер Kubernetes.
Трикът е как да се компилира приложението и да се стартира локално в този клъстер. Ако не се дадат специални указания, Docker-образът ще се компилира на вашия компютър, а не в клъстера.
За да накарате Docker да изпрати образа в локалния кластер Kubernetes, на Docker машината се дава следната команда:
eval $(minikube docker-env)
Сега можем да компилираме приложения в локалния кластер Kubernetes.
Не раздавайте достъп до kubectl на всички
Това изглежда очевидно, но ако няколко екипа използват един и същ клъстер за своите приложения (за което е създаден Kubernetes), не трябва просто да давате достъп на всички. kubectlПо-добре е да разделите екипите, като на всеки от тях се предостави свое пространство от имена и се ограничи достъпа с RBAC политики.
Можете да се замислите, като напишете права за достъп за всеки под – за четене, създаване, изтриване и други операции. Но най-важното е да ограничите достъпа до тайните, позволявайки го само на администратори. Така ще различим тези, които могат да администрират клъстера, от тези, които просто могат да се разгръщат в него.
Управлявайте бюджетите на подовете
Как да се гарантира, че приложението в клъстера Kubernetes няма да има прекъсвания? PodDisruptionBudget и отново PodDisruptionBudget.
Клъстерите периодично се обновяват, а възлите се опустошават. Нищо не стои на място, такава е реалността. Всеки деплой с повече от един инстанс задължително трябва да включва PDB (PodDisruptionBudget). Той се създава в прост файл yaml, който се прилага към клъстера. Обхватът на конкретния PDB се определя от селекторите на етикети.
Бележка: Бюджетът PDB се отчита само при обратимото нарушаване на бюджета (). В ситуации като хардуерни повреди PDB няма да сработи.
Пример за PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Двата основни параметъра са matchLabels и minAvailable. Параметърът първи посочва за кои приложения важи бюджетът. Например, ако имам деплои с етикети app: app-a и app: app-b, то този PDB ще се прилага само за първия.
Параметър minAvailable се взема предвид при изчистването на възела. Например, в нашия пример по време на изчистването се освобождават всички инстанции app: app-a, с изключение на две.
Това позволява да се контролира колко екземпляра на приложението трябва да бъдат стартирани във всеки момент.
Мониторинг на здравословното състояние на приложението
Този мониторинг е възможен по два начина: чрез проби Readiness или Liveness.
Първата проба (readiness) определя готовността на контейнера да приема трафик.
Втората (liveness) показва дали контейнерът е в изправност или трябва да бъде рестартиран.
Съответните конфигурации просто се добавят в yaml за разгръщане. Там могат да бъдат посочени таймаути, времеви закъснения и брой повторни проби. По-подробно за тях можете да видите .
Етикети навсякъде
Етикети — едно от основополагащите понятия в Kubernetes. Те позволяват обектите свободно да се свързват помежду си, а също така да се създават заявки на базата на етикети. В Kubernetes дори можете да отидете при клиента и да наблюдавате събитията по конкретни етикети.
С помощта на етикети можете да направите почти всичко, но добър пример е създаването на няколко среди за изпълнение на програми в един клъстер.
Да предположим, че използвате един и същи клъстер за dev и qa. Това означава, че може да имате приложение app-a, работещо едновременно в двете среди qa и dev. В този случай можем да се обърнем отделно към екземпляра на приложението в конкретната среди, посочвайки съответния параметър среда. Например, app: app-a и environment: dev за едната среда, а app: app-a и environment: qa за втората.
Това позволява да се обръщате към двата екземпляра на приложението, например, да провеждате тестове едновременно.
Подредете нещата
Kubernetes — много мощна система, но всяка система в крайна сметка може да се задръсти от голям брой процеси. Kubelet стартира всички процеси и проверки, които сте посочили, както и своите собствени.
Разбира се, една оставена услуга не ще забави системата, а Kubernetes първоначално е проектиран за мащабиране. Но ако вместо една услуга се появят милион, kubelet започва да се задушава.
Ако по някаква причина изтриете разгръщането (контейнер, образ, каквото и да е), просто се уверете, че е напълно почистено.
Запознайте се с Go
Най-важният съвет оставяме за накрая. Научете езика за програмиране Go.
Kubernetes е написан на Go, всички разширения са написани на Go, а клиентската библиотека client-go е официално поддържана.
Може да се използва за различни и интересни неща. Например, за разширяване на системата Kubernetes според вашите нужди. Така можете да използвате собствени програми за събиране на данни, разгръщане на приложения или просто почистване на контейнери.
Да научите езика за програмиране Go и да усвоите client-go е вероятно най-важният съвет, който можете да дадете на начинаещите потребители на Kubernetes.
Какво още да прочетете:
- .
- ?
- .
Източник: habr.com
