В интернет има много справочна литература, но понякога най-простият съвет е най-ценният. Екип преведено , които авторът на статията събра след една година работа с Kubernetes. Съветите не са сортирани по важност, но смятаме, че всеки ще намери нещо полезно за себе си.
Най-простата команда за работа с Kubernetes
Като начало, може би най-простото и полезно действие при работа с Kubernetes. Следващата команда позволява завършване на команда kubectl в bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
AutoComplete kubectl ще бъде записан във файла .bashrc и ще се активира автоматично при всяко стартиране на обвивката. Това ускорява въвеждането на дълги команди и параметри като all-namespaces. Прочетете повече в .
Ограничения на паметта и процесора по подразбиране в пространство от имена
Ако приложението е написано неправилно, например, отваря нова връзка към базата данни всяка секунда, но никога не я затваря, тогава клъстерът има изтичане на памет. И ако приложението няма ограничение на паметта, зададено по време на внедряването, това може да доведе до повреда на възела.
За да предотврати това, 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% от дисковото пространство, но може да изчерпи inodes, което ще причини проблеми на работниците.
В по-стари версии на kubelet от 1.4 до 1.6 ще трябва да добавите този флаг:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
В 1.7 и по-нови версии този флаг е зададен по подразбиране. Предишните версии обаче не наблюдават ограничението на inode.
Minikube... малък, но мощен местен Kubernetes
Minikube е най-лесният начин за стартиране на локален клъстер на Kubernetes. Стартира се с проста команда:
minikube start
Изпълнението на тази команда води до истински Kubernetes клъстер, работещ на вашия компютър.
Номерът е как да създадете приложението и да го стартирате локално на този клъстер. Освен ако не е специално указано, Docker изображението ще бъде изградено на вашия компютър, а не на клъстера.
За да принуди Docker да изпрати изображението към локалния клъстер на Kubernetes, на докер машината се дава следната команда:
eval $(minikube docker-env)
Сега можем да създаваме приложения на локален клъстер на Kubernetes.
Не давайте kubectl достъп на всички
Това изглежда очевидно, но ако множество екипи използват един и същ клъстер за своите приложения (за което е създаден Kubernetes), не трябва просто да давате на всички kubectl. По-добре е да разделите командите, като на всяка от тях присвоите собствено пространство от имена и ограничите достъпа с помощта на RBAC политики.
Можете да се объркате, като зададете права за достъп, четене, създаване, изтриване и други операции за всяка група. Но основното е да ограничите достъпа до тайни, като го разрешите само на администратори. По този начин ще правим разлика между тези, които могат да администрират клъстера, и тези, които могат просто да го разположат.
Управлявайте бюджетите на Pod
Как да се осигури липса на престой за приложение в клъстер на Kubernetes? PodDisruptionBudget и отново PodDisruptionBudget.
Клъстерите периодично се актуализират и възлите се изпразват. Нищо не стои неподвижно, това е реалността. Всяко внедряване с повече от един екземпляр трябва да включва PDB (PodDisruptionBudget). Създава се в прост yaml файл, който се прилага към клъстера. Зоната на покритие на конкретен 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, с изключение на две.
Това ви позволява да контролирате колко копия на приложението трябва да се изпълняват във всеки един момент.
Мониторинг на здравето на приложението
Такова наблюдение е възможно по два начина: чрез използване на тестове за готовност или тестове за живост.
Първата сонда (готовност) определя готовността на контейнера да приема трафик.
Второто (оживеност) показва дали контейнерът е здрав или трябва да се рестартира.
Съответните конфигурации просто се добавят към yaml за внедряване. Там можете да посочите изчакване, времена на забавяне и брой повторни опити. Вижте повече подробности за тях .
Етикетите са навсякъде
Етикетите са една от основните концепции в Kubernetes. Те позволяват на обектите свободно да комуникират помежду си, както и да създават заявки въз основа на етикети. В Kubernetes можете дори да отидете на клиента и да гледате събития за конкретни тагове.
Можете да правите почти всичко с етикети, но добър пример би бил създаването на множество среди за изпълнение на програми в един и същи клъстер.
Да приемем, че използвате същия клъстер за dev и qa. Това означава, че можете да имате приложение app-a, работещи едновременно и в двете среди qa и dev. В този случай можем отделно да получим достъп до екземпляра на приложението в конкретна среда, като посочим подходящия параметър environment, Например app: app-a и environment: dev за една среда и app: app-a и environment: qa за второто.
Това ви позволява да имате достъп до двата екземпляра на приложението, например, за да провеждате тестване едновременно.
Сложете нещата в ред
Kubernetes е много мощна система, но всяка система може в крайна сметка да затъне с твърде много процеси. Kubelet изпълнява всички процеси и проверки, които сте посочили, както и своите собствени.
Разбира се, една осиротяла услуга няма да забави системата, а Kubernetes е създаден за мащабиране. Но ако вместо една услуга се появи милион, кубелетът започва да се задушава.
Ако по някаква причина изтриете внедряване (контейнер, изображение, каквото и да е), просто не забравяйте да направите пълно почистване.
Запознайте се с Go
Запазихме основния съвет за накрая. Научете езика за програмиране Go.
Kubernetes е разработен в Go, всички разширения са написани в Go, а клиентската библиотека client-go също се поддържа официално.
Може да се използва за различни и интересни неща. Например, за да разширите системата Kubernetes по ваш вкус. Така че можете да използвате свои собствени програми за събиране на данни, внедряване на приложения или просто почистване на контейнери.
Изучаването на езика за програмиране Go и овладяването на client-go е може би най-важният съвет, който можете да дадете на новите потребители на Kubernetes.
Какво друго да чета:
- .
- ?
- .
Източник: www.habr.com