Standalone kubelet: запуск docker-контейнеров в режиме static pods

Для запуска 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 со всеми параметрами и их описанием доступен по ссылке ниже из документации

Используемые источники