Има многу референтна литература на Интернет, но понекогаш наједноставниот совет е највреден. Тим преведено , што авторот на статијата го собра по една година работа со Кубернетес. Советите не се подредени по важност, но мислиме дека секој ќе најде нешто корисно за себе.
Наједноставната команда за работа со Kubernetes
За почеток, можеби наједноставната и најкорисната акција во работата со Кубернет. Следната команда овозможува комплетирање на командата kubectl во баш школка:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Автоматско пополнување 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. Сега секој контејнер распореден во овој именски простор ќе има ограничување од 512 Mi, освен ако дополнително не е поставено друго индивидуално ограничување за овој контејнер.
Собирање ѓубре во постарите верзии на Kubernetes
Kubelet стандардно започнува со собирање ѓубре кога var/lib/docker зафаќа 90% од достапниот простор на дискот. Ова е одлично, сепак, до Kubernetes 1.7 немаше стандардно ограничување на бројот на користени иноди, кои одговараат на бројот на датотеки во датотечниот систем.
Потенцијално вашиот сад 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 start
Извршувањето на оваа команда резултира со вистински Kubernetes кластер кој работи на вашиот компјутер.
Трикот е како да се изгради апликацијата и да се изврши локално на тој кластер. Освен ако не е конкретно наведено, сликата на Docker ќе биде изградена на вашиот компјутер, а не на кластерот.
За да го принуди Docker да ја турне сликата до локалниот кластер Kubernetes, на Docker машината и е дадена следнава команда:
eval $(minikube docker-env)
Сега можеме да изградиме апликации на локален Kubernetes кластер.
Не давајте пристап на kubectl на сите
Ова изгледа очигледно, но ако повеќе тимови го користат истиот кластер за нивните апликации (за што е создаден Kubernetes), не треба само да им давате на сите kubectl. Подобро е да се одделат командите, назначувајќи на секоја од нив свој именски простор и ограничувајќи го пристапот користејќи RBAC политики.
Може да се збуните со доделување права за пристап, читање, креирање, бришење и други операции за секоја подлога. Но, главната работа е да се ограничи пристапот до тајните, дозволувајќи им само на администраторите. На овој начин ќе направиме разлика помеѓу оние кои можат да го администрираат кластерот и оние кои едноставно можат да се распоредат во него.
Управувајте со буџетите на Pod
Како да се обезбеди без прекини за апликација во кластерот Kubernetes? PodDisruptionBudget и повторно PodDisruptionBudget.
Кластерите периодично се ажурираат и јазлите се празни. Ништо не стои, тоа е реалноста. Секое распоредување со повеќе од еден пример треба да вклучува PDB (PodDisruptionBudget). Создаден е во едноставна yaml датотека што се применува на кластерот. Областа на покриеност на одредена 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, тогаш ова ППБ ќе важи само за првото.
Параметар 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.
Kubernetes е развиен во Go, сите екстензии се напишани во Go, а клиентската библиотека за клиент-го е исто така официјално поддржана.
Може да се користи за различни и интересни работи. На пример, да го проширите системот Kubernetes по ваш вкус. Значи, можете да ги користите вашите сопствени програми за собирање податоци, распоредување апликации или едноставно чистење на контејнерите.
Учењето на програмскиот јазик Go и совладувањето на клиент-го е можеби најважниот совет што можете да им го дадете на новите корисници на Кубернетес.
Што друго да се прочита:
- .
- ?
- .
Извор: www.habr.com