Что такое Kubelet в Kubernetes. Подробный обзор

Что такое Kubelet

Представьте, что ваш кластер — это оркестр. Здесь управляющий компонент Kubernetes — дирижер, который дает команды. А Kubelet — музыкант, играющий на своем инструменте. Его задача — играть вовремя те струны (поды), которые необходимо, а также следить за их состоянием.

Чтобы лучше понять работу Kubelet, вспомним основные понятия Kubernetes.

Worker Node (рабочий узел) — нода, на которой непосредственно запускаются поды с контейнерами. Этот узел обеспечивает работу приложений, управление их ресурсами и взаимодействие с управляющими нодами.

Pod (под) — один или несколько контейнеров, которые собраны в одну сущность и могут быть запущены как одно приложение. Поды — это минимальная единица развертывания в Kubernetes.

Container (контейнер) — изолированный экземпляр приложения или его части, работающий внутри пода. Контейнеры содержат все необходимое для работы приложения: код, зависимости, библиотеки и настройки среды.

API-сервер — центральный интерфейс для взаимодействия с кластером Kubernetes. Он принимает запросы от пользователей и инструментов автоматизации, проверяет их корректность и передает инструкции другим компонентам. API-сервер также обеспечивает доступ к хранилищу конфигурации, где хранятся все данные о текущем состоянии кластера.

И вот теперь мы подошли к одному из важнейших элементов этой сложной системы — Kubelet. Это незаменимый компонент Kubernetes, который можно сравнить с «исполнителем». Он трудится на каждом рабочем узле (Node) и выполняет команды управляющего центра K8s, чтобы приложения в вашем кластере работали так, как задумано. Кроме запуска и остановки, Kubelet отслеживает здоровье контейнеров и подов и сообщает об изменениях управляющему компоненту.

Как работает Kubelet

Регистрация ноды

Для начала работы ноды Kubelet должен совместно с API-сервером зарегистрировать ее в кластере. При успешной регистрации API-сервер сохраняет информацию о новой ноде в etcd, после чего она становится доступной для планирования и выполнения подов.

Получение инструкций от API-сервера

Kubelet работает в терминах PodSpec, который представляет собой объект YAML или JSON, описывающий под. Kubelet получает набор PodSpecs-инструкций от API-сервера Kubernetes и обеспечивает выполнение и работоспособность контейнеров, указанных в этих спецификациях. PodSpec содержит все необходимые данные о том, какие контейнеры должны быть развернуты, сколько ресурсов им выделено и какие параметры настроек следует применить. 

Создание пода и запуск контейнеров

Kubelet создает новый под на основе полученной спецификации. Внутри пода разворачиваются указанные контейнеры. Для этого Kubelet использует среду запуска контейнеров (container runtime), например, containerd или CRI-O.

Мониторинг состояния подов

После запуска контейнеров Kubelet начинает отслеживать их состояние. Он регулярно выполняет проверки доступности и производительности, используя механизмы health-check.

• Liveness Probe — проверяет, жив ли контейнер. Если контейнер завис, Kubelet перезапускает его.
• Readiness Probe — определяет, готов ли контейнер обслуживать запросы. Если нет, Kubelet временно исключает его из списка доступных эндпоинтов.
• Startup Probe — отслеживает, запустился ли контейнер корректно (полезно для долгозапускаемых приложений). В отличие от других проверок, Startup Probe выполняется только раз.

Если контейнер перестает отвечать или работает некорректно, Kubelet принимает меры в соответствии с PodSpec-инструкцией данного пода. Часто они включают перезапуск контейнера, логирование событий и синхронизацию состояния узла с API-сервером.

Управление ресурсами узла

Еще одна важная функция Kubelet — управление ресурсами узла. Он распределяет между контейнерами доступные ресурсы, такие как CPU и память, и следит за тем, чтобы они не превышали выделенных лимитов. В случае нехватки ресурсов Kubelet применяет так называемые eviction policies — правила, которые позволяют вытеснять менее критичные поды, чтобы освободить ресурсы для более приоритетных задач.

Основные параметры конфигурации Kubelet

Настройка Kubelet начинается с создания файла конфигурации в формате YAML или JSON. В нем описывают параметры, которые Kubelet будет использовать для работы на узле. Такая гибкость позволяет адаптировать поведение узлов под требования конкретной задачи.

Адрес и порт

Параметры address и port указывают, по какому IP-адресу и порту Kubelet будет принимать запросы.

Политики вытеснения — Eviction policies

Эти параметры помогают избежать сбоев при нехватке ресурсов. Например, можно задать минимальные пороги для свободной памяти (memory.available) или места на дисках (nodefs.available), при достижении которых Kubelet начнет завершать работу менее приоритетных подов.

Управление ресурсами — Resource management

Для эффективного использования ресурсов можно настроить лимиты по CPU и памяти для контейнеров. Это позволяет предотвратить перегрузку узлов, соблюдая заданные ограничения.

Расширенные настройки

Кроме базовых, можно настроить более сложные параметры работы Kubelet.

• hairpinMode определяет сетевую конфигурацию контейнеров. Например, promiscuous-bridge включает использование мостов для передачи пакетов между контейнерами;
• serializeImagePulls сообщает способ обработки запросов на загрузку образов. Если он установлен в false, Kubelet попытается загрузить все образы сразу. Это может ускорить загрузку небольшого количества крупных образов, но приведет к увеличению нагрузки на сеть. В ином случае (true) загрузка будет идти последовательно, замедляя процесс;
• maxPods задает максимально допустимое количество подов на узле. Например, если значение по умолчанию (110) слишком велико, его можно уменьшить для ограничения нагрузки;
• podPidsLimit ограничивает количество процессов (PID) внутри пода, предотвращая избыточное потребление системных ресурсов;
• cpuManagerPolicy позволяет управлять процессором, включая строгую привязку ресурсов для выполнения критичных задач;
• kubeAPIQPS и kubeAPIBurst регулируют скорость запросов к API Kubernetes, чтобы избежать перегрузки управляющих компонентов.

Пример конфигурации

    apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "10.10.10.10"
port: 10250
serializeImagePulls: false
maxPods: 80
cpuManagerPolicy: "static"
podPidsLimit: 100
evictionHard:
  memory.available: "200Mi"
  nodefs.available: "10%"
kubeAPIQPS: 20

Описание настроек приведенной конфигурации:

• узел Kubelet работает на IP 10.10.10.10 и стандартном порту 10250;
• контейнеры загружаются параллельно (serializeImagePulls: false);
• количество подов ограничено до 80 (maxPods: 80), а каждый из них может использовать не более 100 процессов (podPidsLimit: 100);
• cpuManagerPolicy:static закрепляет ядра CPU за контейнерами для повышения производительности;
• при остатке свободной оперативной памяти менее 200 МБ (memory.available: «200Mi») или остатке свободного дискового пространства менее 10% (nodefs.available: «10%») Kubelet начнет завершать менее приоритетные поды;
• ограничение количества запросов к API-серверу в секунду — 20 (kubeAPIQPS: 20).

Конфигурация через kubeadm

Конфигурацию можно применить с помощью флага —config утилиты kubeadm, передав путь к заранее подготовленному файлу конфигурации. Например:

    kubeadm init --config=/tmp/kubeadm-config.yaml

Мониторинг Kubelet

Мониторинг Kubelet — важная задача для стабильной работы кластера Kubernetes. Если Kubelet не будет работать, узел перестанет управлять подами. Тогда новые контейнеры не станут запускаться, а старые — восстанавливаться при сбоях. Чтобы избежать таких ситуаций, необходимо следить за ключевыми параметрами Kubelet, которые помогут оценить его состояние и выявить проблемы на ранней стадии.

• Работающий процесс Kubelet. Убедитесь, что процесс Kubelet активен на узле. Это можно проверить через systemctl status kubelet.
• Использование ресурсов. Необходимо следить за использованием CPU, памяти и дискового пространства. Низкие значения могут привести к вытеснению подов.
• Метрики производительности и состояния, которые доступны через API Kubelet (/metrics), например:

kubelet_running_pods — количество запущенных подов.

kubelet_runtime_operations_total — число операций с контейнерами. Аномалии, например резкий рост, могут сигнализировать о проблемах.

kubelet_evictions — количество вытесненных подов. Повышенные значения указывают на нехватку ресурсов.

Для анализа данных часто используются два популярных инструмента: Prometheus и Grafana.

Prometheus

Prometheus — это система сбора метрик. Она подключается к API Kubelet и автоматически собирает необходимые данные, например, загрузку ресурсов или частоту операций с контейнерами.

Prometheus позволяет гибко настраивать оповещения. Например, при достижении лимита оперативной памяти в 200 МБ на почту администратора отправляется соответствующее сообщение.

Grafana

Grafana — это платформа для визуализации и анализа данных. Она позволяет создавать удобные дашборды или графики, с помощью которых легко заметить отклонения.

С помощью описанных инструментов администраторы могут в реальном времени следить за состоянием Kubelet, настраивать уведомления о сбоях и принимать меры до того, как проблемы повлияют на работу приложений.

Логирование Kubelet

Логирование Kubelet — это важный инструмент для отслеживания и диагностики работы узлов в Kubernetes. Логи помогают выявлять причины сбоев, анализировать поведение системы и следить за выполнением задач на нодах.

Kubelet записывает два основных типа логов:

• потоки стандартного вывода фиксируют общие события и информацию о работе узлов, таких как успешный запуск пода или выполнение команды;
• потоки вывода ошибок содержат данные о сбоях, например, ошибки запуска контейнера или нехватку ресурсов на ноде.

Еще один способ работы с логами Kubelet — использование Kubelet API. Через этот интерфейс можно получить доступ к журналам удаленно, не заходя на конкретную ноду. Например, чтобы вернуть данные о логах Kubelet для указанного узла, можно использовать команду:

    kubectl get --raw "/api/v1/nodes/<node-name>/proxy/logs/?query=kubelet" 

Kubelet или Kubectl: в чем разница

На первый взгляд, Kubelet и Kubectl могут показаться похожими, однако это разные компоненты, которые решают разные задачи.

Как вы уже знаете, Kubelet — это агент, который запускается на каждой ноде в кластере. Его задача — обеспечивать выполнение приложений и поддерживать состояние узла в соответствии с инструкциями от управляющих компонентов Kubernetes.

Kubectl — это командная утилита, предназначенная для взаимодействия с Kubernetes. Через нее администраторы и разработчики могут отправлять команды в кластер, чтобы развертывать приложения, изменять конфигурации или отслеживать состояние компонентов. Подробнее про Kubectl рассказали в другой нашей статье.

Основные различия Kubelet и Kubectl:

• роль в системе — Kubelet работает как агент на нодах, а Kubectl является инструментом для отправки команд в кластер;
• область действия — Kubelet отвечает только за работу ноды, где он установлен, а Kubectl охватывает весь кластер;
• взаимодействие — Kubelet выполняет команды, поступающие от API-сервера, а Kubectl отправляет команды в API-сервер.

Например, если контейнер внезапно перестал работать, Kubelet может автоматически его перезапустить. Однако для анализа причины сбоя вам понадобится Kubectl, чтобы получить доступ к логам и состоянию пода.

Kubernetes в Selectel

Kubernetes в облаке

Selectel занимает первое место в рейтинге провайдеров Kubernetes по версии CNews.

Managed Kubernetes от Selectel — это готовое решение для управления контейнерами, которое гарантирует стабильную работу кластера даже в пиковые моменты.

Вы можете создать кластер любой конфигурации через удобный интерфейс управления или с помощью инструментов автоматизации, таких как Terraform. Для адаптации к нагрузкам предусмотрено автоматическое масштабирование: сервис увеличит количество нод при повышении нагрузки и отключит неиспользуемые ресурсы при ее снижении. Это позволяет экономить до 70% бюджета.

Облачные кластеры также соответствуют требованиям 152-ФЗ до УЗ-1. Это означает, что вы можете использовать Kubernetes на проектах, где обрабатываются персональные данные до первого уровня защищенности, а также в проектах с участием государственных компаний.

Kubernetes на выделенных серверах

В Managed Kubernetes on Bare Metal воркер-ноды разворачиваются на базе выделенных серверов. Такое решение подойдет для приложений, которым критична производительность или изолированная инфраструктура. При этом Control Plane с мастер-нодами остается в облаке, что обеспечивает удобное управление кластером.

Заключение

Kubelet — это один из основных компонентов Kubernetes, который отвечает за управление жизненным циклом подов и оптимальное использование ресурсов узлов. Понимание работы Kubelet позволяет не только улучшить надежность кластеров, но и максимально эффективно использовать возможности контейнеризации в современных приложениях.