Для запуска docker-контейнеров, как правило, либо используется непосредственно только docker, либо же docker-compose или оркестраторы, когда количество контейнеров начинает расти. В данной заметке я опишу ещё один нетривиальный, на мой взгляд, запуск контейнеров.
В Kubernetes есть такой компонент, как kubelet – он располагается на каждой рабочей ноде кластера k8s и отвечает за запуск подов, которые описываются с помощью манифестов. И есть у kubelet такая возможность запускать статические поды, т.е. поды, которые не находятся в кластере k8s, но необходимы для функционирования этого кластера. К таким относятся etcd, api-server и прочие компоненты k8s.
Но что, если вместо такого предназначения, запустить с помощью kubelet свои контейнеры в качестве подов? Да, так можно сделать и даже описано в документации. Для этого необходимо установить на сервере сам kubelet, сформировать его конфигурационный файл в формате YAML и указать директорию для манифестов статических подов. Например, это /etc/kubelet/manifests. После этого достаточно описать свой под в файле по пути /etc/kubelet/manifests/web.yaml и kubelet непременно попытается его запустить:
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
Пример выше с запуском Nginx взят из документации. Если удалить манифест, то kubelet это обнаружит и убьет контейнер.
Возникнет логичный вопрос: зачем нужно запускать контейнеры таким образом, когда есть куда более простой docker-compose или более сложный, но функциональный k8s? Да, я согласен, что данная возможность кажется избыточной и неприменимой. Но это лишь на первый взгляд, т.к. есть некоторые особенности в данном способе запуска контейнеров:
- Все контейнеры описаны в едином декларативном формате манифеста, как и все остальные манифесты при наличии k8s – таким образом, можно запустить приложения, которые по каким-то причинам не могут находиться в кластере k8s, но при этом среда исполнения будет максимально схожа с k8s.
- Возможность “пощупать” один из компонентов kubernetes перед полноценным переходом.
- Kubelet позволяет использовать init-контейнеры и liveness probes – как по мне, это одно из преимуществ данного способа.
- Никуда не делись возможности по установке лимитов CPU и RAM, и настройки CNI.
Таким образом, данный способ является некой альтернативой имеющимся классическим решениям (dc, k8s & etc), хотя и весьма и специфической. В продакшене я бы такое, конечно, не стал запускать, но просто знать, что такая возможность имеется – всегда полезно для расширения кругозора.
P.S. Полный конфиг kubelet со всеми параметрами и их описанием доступен по ссылке ниже из документации
Используемые источники