98. Словарь Kubernetes и терминов курса

Этот словарь объясняет термины в том смысле, в котором они используются в курсе. В каждой главе первое значимое употребление термина ведёт сюда. Команды, имена полей YAML и буквальные значения оставлены без ссылок, чтобы примеры можно было копировать.

Если определение расходится с поведением конкретного кластера, проверяйте версию API и документацию реализации. Kubernetes — расширяемая платформа: наличие объекта API ещё не гарантирует, что в кластере установлен контроллер, который реализует его поведение.

Быстрый поиск

Используйте поиск браузера (Ctrl+F / Cmd+F) или перейдите к группе:

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

Кластер и его компоненты

Kubernetes

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

Cluster

Кластер Kubernetes — плоскость управления и один или несколько узлов, совместно исполняющих контейнерные нагрузки. Объекты отправляются в API кластера, а контроллеры и узловые агенты постепенно воплощают описанное состояние.

Control plane

Плоскость управления — компоненты, которые принимают API-запросы, хранят состояние, планируют Pods и запускают циклы контроллеров. Это не «главный сервер приложения»: пользовательская нагрузка обычно работает на узлах.

Node

Node, узел — вычислительная машина, зарегистрированная в Kubernetes и способная исполнять Pods. В production это может быть виртуальная или физическая машина; локальные инструменты могут моделировать узел контейнером.

Worker node

Worker node, рабочий узел — узел, предназначенный прежде всего для пользовательских нагрузок. На нём работают kubelet, среда исполнения контейнеров и сетевая плоскость данных.

kind

kind (Kubernetes IN Docker) — инструмент для локальных Kubernetes-кластеров. Он создаёт кластер, где узлы представлены контейнерами Docker, Podman или nerdctl; это удобно для обучения, разработки и CI, но не добавляет реальную вычислительную мощность отдельными машинами.

kind node

kind node — контейнер, который играет роль полноценного узла Kubernetes внутри кластера kind. Не путайте три уровня: контейнер kind node содержит узловые компоненты; kubelet на этом узле запускает Pods; Pods содержат контейнеры приложения.

API server

API server (kube-apiserver) — HTTP-точка входа Kubernetes API. Он проверяет запросы, выполняет аутентификацию, авторизацию и admission, а затем читает или сохраняет объекты; сам контейнеры не запускает.

etcd

etcd — согласованное key-value хранилище данных плоскости управления. В нём хранится состояние объектов Kubernetes, но не пользовательские данные приложения внутри его PVC или внешней базы данных.

Scheduler

Scheduler (kube-scheduler) — компонент плоскости управления, выбирающий подходящий Node для ещё не назначенного Pod. Он учитывает requests, ограничения, affinity, taints, topology и другие правила, но запуск контейнера выполняет kubelet.

Kubelet

kubelet — агент на каждом Node. Он наблюдает назначенные узлу PodSpecs и через CRI приводит контейнеры к требуемому состоянию, запускает probes и сообщает статус обратно в API.

Controller

Контроллер — цикл управления, который наблюдает объекты и действует, чтобы приблизить фактическое состояние к желаемому. Deployment, Job, Node и многие другие ресурсы имеют свои контроллеры.

Reconciliation

Reconciliation, согласование — один проход или непрерывный процесс сравнения желаемого и наблюдаемого состояний с последующим корректирующим действием. Асинхронность согласования объясняет, почему успешный apply ещё не означает готовую нагрузку.

Container runtime

Среда исполнения контейнеров — программа, которая загружает образы и создаёт, запускает и останавливает контейнеры. Kubelet обращается к ней через CRI; типичный пример в Kubernetes — containerd.

CRI

CRI, Container Runtime Interface — интерфейс между kubelet и средой исполнения контейнеров. Он позволяет Kubernetes работать с совместимыми runtime без встраивания их реализации в kubelet.

Клиент, API и объекты

kubectl

kubectl — командный клиент Kubernetes API. Он читает kubeconfig, выбирает контекст и отправляет запросы API server; это не сам кластер и не демон на Node.

kubeconfig

kubeconfig — конфигурационный файл с адресами кластеров, учётными данными и контекстами. Ошибка выбора kubeconfig может направить безопасную на вид команду в другой кластер.

Context

Context, контекст kubectl — именованная комбинация кластера, пользователя и Namespace по умолчанию в kubeconfig. Перед изменяющей или удаляющей командой проверяйте текущий контекст.

Namespace

Namespace — логическая область имён для namespaced-объектов одного кластера. Он помогает разделять команды, имена и политики, но сам по себе не создаёт полной изоляции сети, ресурсов или безопасности.

Resource

Resource, ресурс / объект API — запись с apiVersion, kind, metadata, а обычно также spec и status, доступная через Kubernetes API. Deployment, Pod, Service и Secret — разные kinds объектов.

Manifest

Манифест — локальное YAML- или JSON-представление желаемого объекта, передаваемое API. После применения источником текущего состояния становится объект в API, а файл остаётся декларацией и, желательно, версионируемым исходником.

Desired state

Желаемое состояние — то, что пользователь или контроллер описал в spec: например, три реплики Deployment. Наблюдаемое состояние — факты, которые компоненты видят сейчас и обычно отражают в status.

spec and status

spec описывает намерение, status — наблюдаемое состояние объекта. Запись в spec не синхронная команда процессу: контроллер позже попытается согласовать реальность и обновить status.

Label

Label, метка — короткая индексируемая пара ключ/значение на объекте. Метки используются для выборки и связывания объектов, поэтому изменение метки может изменить принадлежность Pod к Service или контроллеру.

Selector

Selector, селектор — условие выбора объектов по labels. Селектор Service определяет его endpoints, а селектор Deployment — Pods, которыми он владеет; ошибка селектора часто даёт корректный объект без рабочего трафика.

Annotation

Annotation, аннотация — неиндексируемые метаданные для инструментов, людей или контроллеров. Аннотация обычно не предназначена для выбора объектов.

OwnerReference

OwnerReference — ссылка зависимого объекта на владельца. Она задаёт граф владения для garbage collection и позволяет проследить цепочку Deployment → ReplicaSet → Pod.

Finalizer

Finalizer — строка в metadata, блокирующая окончательное удаление объекта, пока ответственный контроллер не выполнит очистку и не удалит finalizer. Объект с deletionTimestamp и finalizer уже удаляется, а не «игнорирует delete».

Declarative management

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

Pods и контроллеры нагрузок

Pod

Pod — минимальная развёртываемая и планируемая единица Kubernetes: один или несколько контейнеров с общей сетевой областью, IP и, при необходимости, томами. Pod заменяем; его не следует считать долговечной виртуальной машиной.

PodSpec

PodSpec — желаемая конфигурация Pod: контейнеры, образы, тома, ресурсы, проверки, правила планирования и безопасность. Kubelet воплощает PodSpec на назначенном Node.

Init container

Init container — контейнер, который должен успешно завершиться до запуска обычных контейнеров Pod. Он подходит для конечной подготовки, но не для постоянно работающего фонового процесса.

Sidecar

Sidecar — вспомогательный контейнер рядом с контейнером приложения в одном Pod. Он разделяет судьбу и ресурсы Pod; нативный sidecar задаётся как init container с политикой перезапуска Always.

Ephemeral container

Ephemeral container — диагностический контейнер, добавляемый к уже работающему Pod. Он предназначен для отладки, не задаётся как обычная часть приложения и не заменяет исправление образа или observability.

Deployment

Deployment — контроллер декларативного управления взаимозаменяемыми Pods, обычно stateless-нагрузкой. Он создаёт ReplicaSets и управляет rollout и rollback.

ReplicaSet

ReplicaSet — контроллер, поддерживающий заданное число Pods по селектору. Обычно им косвенно управляет Deployment; ручное редактирование дочернего ReplicaSet может быть перезаписано следующей операцией Deployment.

StatefulSet

StatefulSet — контроллер Pods со стабильными идентичностями, упорядоченными операциями и возможностью закреплять отдельный PVC за каждой репликой. Он не делает приложение автоматически реплицированным или отказоустойчивым.

DaemonSet

DaemonSet — контроллер, обеспечивающий Pod на каждом подходящем Node или выбранном наборе Nodes. Типичные применения — сетевой агент, сборщик логов или узловой мониторинг.

Job

Job — контроллер конечной работы: создаёт Pods и добивается требуемого числа успешных завершений. Для бесконечно работающего HTTP-сервиса обычно нужен Deployment, а не Job.

CronJob

CronJob — расписание, которое создаёт Jobs в заданные моменты. Оно наследует семантику конечной работы Job и требует продуманной политики конкуренции и истории.

Rollout

Rollout — переход контроллера нагрузки от одной ревизии Pod template к другой. Для Deployment это обычно постепенное создание нового ReplicaSet и уменьшение старого согласно maxSurge и maxUnavailable.

Rollback

Rollback — возврат к предыдущей рабочей ревизии конфигурации или образа. Откат Deployment не откатывает автоматически внешнюю схему данных, Secret или несовместимое состояние приложения.

Сеть и доступ к приложению

Service

Service — стабильная сетевая точка доступа к логическому набору backend Pods. Обычно Service выбирает Pods по labels, а актуальные адреса публикуются через EndpointSlices.

ClusterIP

ClusterIP — тип Service и его виртуальный IP, доступный внутри кластерной сети. Это не IP конкретного Pod и обычно не маршрут из внешнего интернета.

NodePort

NodePort — тип Service, открывающий одинаковый порт на Nodes и направляющий трафик к Service. Он полезен как строительный блок и в лаборатории, но редко даёт полноценный внешний балансировщик сам по себе.

LoadBalancer

LoadBalancer — тип Service, запрашивающий внешний балансировщик у реализации окружения. В локальном kind результат не появляется без дополнительного контроллера или специальной конфигурации.

EndpointSlice

EndpointSlice — объект с группой сетевых endpoints для Service. Он показывает, какие адреса и порты реально готовы принимать трафик, и потому важен для диагностики селекторов и readiness.

DNS and CoreDNS

DNS кластера даёт Service и Pod предсказуемые имена. CoreDNS — типичная реализация DNS-сервиса Kubernetes; успешный DNS-ответ ещё не доказывает наличие готового backend endpoint.

Ingress

Ingress — namespaced-объект правил HTTP/HTTPS-маршрутизации к Services. Сам объект ничего не маршрутизирует: в кластере нужен совместимый Ingress controller.

Ingress controller

Ingress controller — установленный компонент, который наблюдает Ingress и настраивает реальный proxy или load balancer. Его API-объекты и возможности зависят от реализации.

Gateway API

Gateway API — семейство Kubernetes API для ролей и маршрутизации трафика, например Gateway и HTTPRoute. Наличие CRDs не гарантирует работающий dataplane: требуется реализация controller.

CNI

CNI, Container Network Interface — спецификация и плагины, через которые runtime настраивает сеть контейнеров. В Kubernetes CNI-реализация обычно создаёт сеть Pod, а часто также реализует NetworkPolicy.

NetworkPolicy

NetworkPolicy — декларативное ограничение допустимого входящего и исходящего трафика Pods. Без реализации CNI, поддерживающей policy enforcement, валидный объект NetworkPolicy может не изменить трафик.

Конфигурация и хранилище

ConfigMap

ConfigMap — объект для неконфиденциальной конфигурации в виде пар ключ/значение или файлов. Обновление ConfigMap не всегда автоматически перезапускает Pods и не гарантирует, что приложение перечитает значение.

Secret

Secret — объект для небольших конфиденциальных данных. Значение data в YAML кодируется base64, а не шифруется этим кодированием; нужны RBAC, шифрование at rest, ограничение выдачи и безопасный процесс ротации.

Volume

Volume, том — каталог, доступный контейнерам Pod и имеющий жизненный цикл, зависящий от типа тома. Volume не обязательно постоянный: emptyDir исчезает вместе с Pod.

PV

PV, PersistentVolume — кластерный объект, представляющий подготовленное или динамически выделенное постоянное хранилище и его политику жизненного цикла.

PVC

PVC, PersistentVolumeClaim — namespaced-запрос рабочей нагрузки на хранилище с нужным размером и режимами доступа. Pod монтирует claim, а не выбирает конкретный диск напрямую.

StorageClass

StorageClass — класс хранилища и параметры provisioner. Он позволяет динамически создать PV для PVC и определяет детали, зависящие от инфраструктуры.

CSI

CSI, Container Storage Interface — стандартный интерфейс между оркестратором и драйвером хранилища. CSI-драйвер может реализовать provision, attach, mount, snapshot и другие операции, но набор возможностей зависит от драйвера.

Здоровье, ресурсы и планирование

Probe

Probe, проверка — периодическая проверка контейнера, выполняемая kubelet. Readiness, liveness и startup отвечают на разные вопросы и не должны быть одной и той же проверкой по привычке.

Readiness

Readiness probe отвечает: можно ли сейчас направлять трафик в контейнер. Неуспех убирает endpoint из готовых backend Service, но не обязан перезапускать контейнер.

Liveness

Liveness probe отвечает: нужно ли перезапустить зависший контейнер. Проверка внешней зависимости как liveness может создать каскадные перезапуски при общем отказе.

Startup

Startup probe даёт медленно запускающемуся приложению отдельное окно старта. Пока она не успешна, liveness и readiness не выполняются.

requests and limits

Requests — ресурсы, используемые scheduler для размещения и гарантий; limits — верхние ограничения, применяемые во время исполнения. CPU limit обычно приводит к throttling, а превышение memory limit может привести к OOM kill.

QoS

QoS class (Guaranteed, Burstable, BestEffort) выводится Kubernetes из requests и limits контейнеров Pod. Она влияет на приоритет вытеснения при дефиците ресурсов Node, но не является показателем качества приложения.

Affinity

Affinity / anti-affinity — правила предпочтительного или обязательного совместного либо раздельного размещения Pods относительно Nodes и других Pods. Жёсткие правила повышают предсказуемость, но могут оставить Pod в Pending.

Taint and toleration

Taint помечает Node как нежелательный для Pods; toleration разрешает Pod переносить конкретный taint. Toleration не выбирает Node — она лишь снимает один запрет планирования или вытеснения.

Eviction

Eviction, вытеснение — корректируемое прекращение Pod по решению scheduler, kubelet, администратора или API eviction. В отличие от обычного delete, API eviction учитывает PodDisruptionBudget, когда это применимо.

Drain

Drain — административная подготовка Node к обслуживанию: cordon запрещает новые назначения, затем подходящие Pods вытесняются. DaemonSet Pods и локальные данные требуют отдельных решений.

HPA

HPA, HorizontalPodAutoscaler — контроллер, меняющий число реплик workload по метрикам. Ему нужен источник метрик, а для вычисления процента использования CPU или памяти — корректные requests; HPA не увеличивает ёмкость Nodes сам по себе.

VPA

VPA, Vertical Pod Autoscaler — отдельный компонент, который рекомендует или меняет requests/limits контейнеров. Он не является встроенным активным контроллером в каждом кластере и может потребовать пересоздания Pods.

PDB

PDB, PodDisruptionBudget — политика, ограничивающая добровольные нарушения доступности группы Pods. Она не предотвращает отказ Node, падение процесса или все виды удаления и не создаёт дополнительные реплики.

Безопасность

ServiceAccount

ServiceAccount — namespaced-идентичность для процессов в Pods и автоматизации. Это не пользователь-человек; разрешения выдаются ей через RBAC.

RBAC

RBAC, Role-Based Access Control — авторизация действий над ресурсами по Roles, ClusterRoles и их bindings. Правило отвечает «кто может выполнить verb над каким resource», а не шифрует данные и не ограничивает сетевой трафик.

SecurityContext

SecurityContext — параметры безопасности Pod или контейнера: UID/GID, capabilities, seccomp, privilege escalation, read-only root filesystem и другие. Допустимость параметров проверяет admission, а применяет runtime и ядро Node.

PSS

PSS, Pod Security Standards — три профиля требований к Pod (Privileged, Baseline, Restricted). Встроенный Pod Security Admission может применять их к Namespace в режимах enforce, audit и warn.

Admission

Admission control — этап после аутентификации и авторизации, но до сохранения объекта. Встроенные плагины, policies и webhooks могут отклонить запрос или изменить объект.

Наблюдаемость и эксплуатация

Event

Event — ограниченная по времени запись Kubernetes о наблюдаемом событии: планировании, pull образа, неуспешной проверке и т. п. Events полезны как улики, но не являются долговечным audit log.

Log

Log, журнал — поток сообщений процесса или компонента. kubectl logs показывает контейнерные логи, но полнота, хранение и поиск требуют отдельной системы сбора.

Metric

Metric, метрика — числовое измерение во времени. Метрика объясняет тенденцию и позволяет строить alerts, но для причин обычно сопоставляется с Events, logs, traces и состоянием объектов.

SLI and SLO

SLI — измеримый индикатор работы сервиса, например доля успешных запросов. SLO — целевой уровень SLI за окно времени. SLO описывает пользовательский результат, а не просто состояние Ready у Pod.

Kustomize

Kustomize — декларативное преобразование Kubernetes manifests через bases, resources, patches и overlays без шаблонного языка. Результат нужно рендерить и проверять до применения.

Helm

Helm — менеджер пакетов Kubernetes. Chart состоит из шаблонов и значений, а release хранит историю установки; успешно отрендеренный chart ещё нужно проверить на совместимость с API и политиками кластера.

GitOps

GitOps — операционная модель, в которой версионируемое желаемое состояние хранится в Git, а автоматический контроллер согласует кластер с репозиторием. Это не просто запуск kubectl apply из CI: важны pull-модель, drift detection, аудит и безопасное управление секретами.

Первичные источники

• Официальный глоссарий Kubernetes
• Компоненты Kubernetes
• Pods и ресурсы рабочих нагрузок
• Services, балансировка и сеть
• Persistent Volumes
• Конфигурация
• Безопасность
• Планирование Pods
• kind: Quick Start и устройство узлов

Вернитесь к карте курса или продолжите с источниками и версионными оговорками.