У інтэрнэце шмат даведачнай літаратуры, але часам самымі каштоўнымі становяцца самыя простыя парады. Каманда перавяла , якія аўтар артыкула сабрала пасля года працы з Kubernetes. Парады не адсартаваны па важнасці, але думаем, што кожны знойдзе нешта карыснае для сябе.
Самая простая каманда ў рабоце з Kubernetes
Для пачатку, мабыць, самае простае і карыснае дзеянне ў рабоце з Kubernetes. Наступная каманда ўключае аўтадапаўненне каманд kubectl у абалонцы bash:
echo "source <(kubectl completion bash)" >> ~/.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% дыскавай прасторы, але пры гэтым іноды могуць скончыцца, што выкліча праблемы ў працы воркераў.
У старых версіях 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, докер-машыне даецца наступная каманда:
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. У гэтым выпадку мы можам звяртацца асобна да асобніка дадатку ў канкрэтным асяроддзі, паказаўшы адпаведны параметр environment. напрыклад, 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