📁 Kubernetes и оркестрация

Короткий ответ Role и RoleBinding ограничены одним namespace и дают права только на ресурсы внутри него; ClusterRole определяет права, применимые на уровне всего кластера (включая кластерные ресурсы вроде Node), но может быть связан как ClusterRoleBinding (права во всём кластере), так и RoleBinding (права только в конкретном namespace, хотя сам набор прав переиспользуемый). Как это работает подробнее RBAC в Kubernetes состоит из двух частей — определение прав (Role/ClusterRole, набор правил "что можно делать с какими ресурсами") и привязка этих прав к субъекту (RoleBinding/ClusterRoleBinding, "кому выданы эти права и где"). ClusterRole часто используют для переиспользуемых наборов прав (например, "read-only доступ к Pod и Service"), которые затем привязываются к разным namespace через отдельные RoleBinding, чтобы не дублировать одинаковые правила. Пример кода Что использовать на практике Практика. для прав, которые должны действовать везде одинаково и затрагивают кластерные ресурсы (Node, PersistentVolume, са

Читать полностьюauthorization

Короткий ответ ConfigMap хранит некритичные конфигурационные данные (переменные окружения, файлы настроек) отдельно от образа контейнера и может быть подключён к Pod как переменные окружения или как смонтированный том с файлами. Как это работает подробнее ConfigMap — это объект Kubernetes с набором пар ключ-значение или целых файлов; он хранится в etcd в открытом виде (без шифрования по умолчанию) и не предназначен для секретов. При монтировании как volume каждый ключ становится отдельным файлом в указанной директории. Пример кода Что использовать на практике Практика. ConfigMap позволяет использовать один и тот же образ контейнера в разных окружениях (dev/staging/prod), подставляя разную конфигурацию снаружи образа, что соответствует принципу "один артефакт — много окружений". Для горячей перезагрузки конфигурации приложение должно само отслеживать изменения файла, Kubernetes не перезапускает Pod автоматически. Подводные камни Риски. хранить пароли и токены в ConfigMap вместо Secret — Secret тоже не шифрует

Читать полностьюconfigmap

Короткий ответ Ingress работает на уровне HTTP/HTTPS (L7) и позволяет одним внешним точкой входа маршрутизировать трафик к разным сервисам по доменному имени или пути URL, а также централизованно управлять TLS, тогда как Service type: LoadBalancer создаёт отдельный балансировщик на каждый сервис и работает на уровне TCP/UDP (L4). Как это работает подробнее Ingress — это набор правил маршрутизации (host/path → Service), который читает Ingress-контроллер (например, NGINX Ingress Controller, Traefik), работающий как отдельный под или набор подов с собственным Service типа LoadBalancer или NodePort. Сам объект Ingress без установленного контроллера ничего не делает. Пример кода Что использовать на практике Практика. вместо десяти сервисов с типом LoadBalancer (и, соответственно, десяти облачных балансировщиков) можно развернуть один Ingress-контроллер с одним внешним IP и описать правила маршрутизации по доменам/путям для всех сервисов — это снижает расходы и упрощает управление TLS-сертификатами в одном месте. П

Читать полностьюingress

Короткий ответ Service даёт стабильный сетевой адрес (имя и/или виртуальный IP) и балансировку нагрузки для группы Pod, чьи IP-адреса меняются при каждом пересоздании — без Service клиентам пришлось бы вручную отслеживать актуальные IP подов. Как это работает подробнее Service выбирает Pod по selector с метками и формирует список endpoint'ов (объект Endpoints/EndpointSlice), на который kube-proxy настраивает правила перенаправления трафика (iptables или IPVS) на уровне узла; DNS внутри кластера (CoreDNS) резолвит имя Service в его ClusterIP. Пример кода Что использовать на практике Практика. приложения обращаются к другим сервисам по доменному имени вида service-name.namespace.svc.cluster.local, а не по IP конкретного Pod; при масштабировании или пересоздании Pod список endpoint'ов обновляется автоматически, и клиенту не нужно ничего менять. Подводные камни Риски. обращаться к Pod напрямую по IP в коде приложения; забывать, что Service балансирует только между Pod, у которых есть хотя бы один прошедший readin

Читать полностьюkubernetes

Короткий ответ Диагностику ведут по шагам: смотрят kubectl describe pod на код завершения и причину (Last State, Reason), затем логи предыдущего запуска (kubectl logs --previous), и только после этого делают вывод — упало ли приложение само (ошибка кода/конфигурации) или его убил Kubernetes (например, по failed liveness probe или OOM). Как это работает подробнее CrashLoopBackOff — это состояние, в котором kubelet увеличивает интервал между попытками перезапуска контейнера экспоненциально после повторных сбоев. Причина сбоя всегда одна из: ненулевой exit code процесса приложения, провал liveness probe (Kubernetes сам убивает контейнер), либо OOMKilled (убийство ядром из-за превышения лимита памяти). Пример кода Что использовать на практике Практика. exit code 1 обычно означает необработанное исключение или ошибку конфигурации на старте — приложение не смогло подключиться к зависимости (БД, очередь) или получило некорректные переменные окружения; exit code 137 указывает на SIGKILL, что характерно для OOMKilled

Читать полностьюcrashloopbackoff

Короткий ответ HPA периодически опрашивает метрики (по умолчанию — средний процент использования CPU/памяти относительно requests, либо кастомные метрики через Metrics API) и изменяет число реплик Deployment/StatefulSet, чтобы приблизить фактическое значение метрики к целевому; ограничение в том, что HPA требует корректно заданных requests и не реагирует мгновенно — есть задержка на сбор метрик и период стабилизации. Как это работает подробнее формула масштабирования примерно такая — желаемые реплики = текущие реплики × (текущее значение метрики / целевое значение), с округлением и ограничениями minReplicas/maxReplicas. Для метрики CPU используется не абсолютное потребление, а процент от requests.cpu, поэтому без заданных requests автоскейлинг по CPU вообще не будет работать корректно. Пример кода Что использовать на практике Практика. для плавного масштабирования без "дребезга" (постоянных колебаний числа реплик) настраивают behavior.scaleDown.stabilizationWindowSeconds, чтобы не схлопывать реплики сразу пос

Читать полностьюautoscaling

Короткий ответ Liveness probe проверяет, что процесс в контейнере жив и работоспособен — при провале Kubernetes перезапускает контейнер; readiness probe проверяет, готов ли контейнер принимать трафик — при провале под временно убирается из endpoints Service, но не перезапускается. Как это работает подробнее обе проверки выполняются kubelet на узле по расписанию (HTTP-запрос, TCP-соединение или команда внутри контейнера) и имеют независимые пороги успеха/неудачи. Liveness влияет на решение "перезапустить контейнер", readiness — на решение "включать ли под в балансировку трафика Service". Пример кода Что использовать на практике Практика. readiness особенно важна при старте приложения, которому нужно время на прогрев кэша или подключение к базе — без неё трафик пойдёт на под раньше, чем он реально готов отвечать. Liveness нужна для восстановления после зависаний (deadlock), когда процесс жив, но не отвечает. Подводные камни Риски. использовать одну и ту же проверку для liveness и readiness без понимания разницы

Читать полностьюhealth-checks

Короткий ответ Base64 — это обратимая кодировка без ключа, а не шифрование; реальная защита Secret в Kubernetes складывается из нескольких независимых слоёв: шифрования etcd at rest (encryption provider), строгого RBAC на чтение Secret, и, при более высоких требованиях, внешних систем управления секретами (Vault, облачный Secret Manager) с синхронизацией в кластер. Как это работает подробнее по умолчанию Kubernetes хранит Secret в etcd в виде base64 без какого-либо шифрования на диске — доступ к файлам etcd или снапшоту бэкапа даёт прямой доступ к значениям секретов. Encryption at rest (настраивается через EncryptionConfiguration на API сервере) шифрует значения Secret перед записью в etcd, но не защищает от легитимного доступа через Kubernetes API — для этого нужен именно RBAC. Пример кода Что использовать на практике Практика. минимальный защищённый контур включает: включённое шифрование etcd at rest, RBAC-правила, ограничивающие get/list на Secret только необходимым сервисным аккаунтам и людям, и отключени

Читать полностьюconfiguration

Короткий ответ Deployment — это декларативный контроллер, который через ReplicaSet поддерживает заданное число реплик Pod, пересоздаёт их при сбоях и управляет обновлениями версии приложения; одиночный Pod такого самовосстановления не имеет. Как это работает подробнее Deployment описывает желаемое состояние (образ, число реплик, стратегию обновления), а контроллер в control plane постоянно сверяет фактическое состояние с желаемым и создаёт/удаляет Pod через ReplicaSet, чтобы их совпасть. Пример кода Что использовать на практике Практика. Deployment используют для stateless-приложений, которым не важны порядок запуска и устойчивые идентификаторы. Обновление образа через kubectl set image или изменение манифеста запускает rolling update по заданной стратегии, а при проблеме можно откатиться командой kubectl rollout undo. Подводные камни Риски. создавать "голый" Pod в проде и удивляться, что после падения узла он не восстанавливается; редактировать Pod, созданный Deployment'ом, напрямую — изменения будут перезап

Читать полностьюdeployment