В интернет има много справочна литература, но понякога най-ценните съвети са най-простите. Екипът преведе , които авторът на статията е събрал след година работа с 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% от дисковото пространство, но в същото време инодите могат да свършат, което да предизвика проблеми в работата на работниците.
В старите версии на 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-machine се дава следната команда:
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) показва дали контейнерът е работоспособен или трябва да бъде рестартиран.
Съответстващите конфигурации просто се добавят в 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
