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

Короткий ответ Переменные окружения, переданные из ConfigMap, читаются процессом только один раз при старте контейнера и не обновляются без перезапуска; файлы, смонтированные как volume из ConfigMap, обновляются на диске автоматически (с задержкой синхронизации kubelet), но приложение должно само отслеживать изменение файла, чтобы подхватить новую конфигурацию без перезапуска. Как это работает подробнее при использовании envFrom/env.valueFrom.configMapKeyRef значения подставляются в переменные окружения процесса на старте контейнера операционной системой — после этого никакая синхронизация с Kubernetes API не происходит. При монтировании ConfigMap как volume kubelet периодически (обычно за время, близкое к TTL кэша kubelet, порядка минуты) обновляет содержимое файлов в уже запущенном контейнере, но само приложение должно реализовать механизм отслеживания изменений файла (например, через inotify или периодический опрос). Пример кода Что использовать на практике Практика. для конфигурации, которая должна менять

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

Короткий ответ Нужно последовательно проверить: совпадают ли selector Service и labels подов, есть ли endpoints у сервиса (kubectl get endpoints), проходят ли поды readiness probe, совпадает ли targetPort с реальным портом, на котором слушает приложение внутри контейнера, и не блокирует ли трафик NetworkPolicy. Как это работает подробнее Service — это абстракция поверх реального списка endpoint, который формируется автоматически только при точном совпадении меток и успешном readiness; даже один неверный символ в значении метки или в имени порта полностью разрывает эту цепочку без явной ошибки в логах приложения — проблема проявляется только на уровне сетевого взаимодействия. Пример кода Что использовать на практике Практика. первый диагностический шаг — kubectl get endpoints <service>: пустой список сразу сужает проблему до selector/labels/readiness, тогда как непустой список переключает фокус на targetPort, сетевые политики или на само приложение (слушает ли оно действительно указанный порт и интерфейс, напр

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

Короткий ответ RollingUpdate (стратегия по умолчанию) постепенно заменяет старые Pod новыми без полного простоя, регулируя скорость через maxSurge (на сколько реплик сверх нормы можно временно превысить) и maxUnavailable (сколько реплик может быть временно недоступно); Recreate сначала полностью останавливает все старые Pod и только потом запускает новые, что гарантированно создаёт простой. Как это работает подробнее при RollingUpdate с maxSurge: 1, maxUnavailable: 0 Deployment сначала поднимает один дополнительный под новой версии, дожидается его readiness, и только потом гасит один под старой версии, повторяя цикл — это минимизирует риск простоя ценой временного превышения числа реплик. При maxUnavailable: 1, maxSurge: 0 вместо этого сначала гасится один старый под, и лишь после его удаления поднимается новый — это экономит ресурсы, но временно снижает мощность обслуживания. Пример кода Что использовать на практике Практика. Recreate оправдан, когда одновременная работа старой и новой версии недопустима — н

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

Короткий ответ Deployment поддерживает заданное число реплик, размещаемых планировщиком по любым подходящим узлам, а DaemonSet гарантирует ровно один экземпляр Pod на каждом (или на выбранном подмножестве) узле кластера — число реплик определяется числом узлов, а не задаётся вручную. Как это работает подробнее DaemonSet автоматически добавляет Pod при появлении нового узла и удаляет при выводе узла из кластера, минуя обычный процесс планирования по ресурсам в привычном смысле — по умолчанию он игнорирует часть ограничений, чтобы гарантированно разместиться на каждом узле (с учётом taints/tolerations). Пример кода Что использовать на практике Практика. DaemonSet используют для инфраструктурных агентов, которые должны работать на каждом узле: сборщики логов (Fluentd/Fluent Bit), экспортеры метрик (node-exporter), сетевые плагины (CNI), агенты безопасности. Обычное приложение с бизнес-логикой почти никогда не разворачивают через DaemonSet. Подводные камни Риски. использовать DaemonSet для масштабирования обычног

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

Короткий ответ Job запускает Pod для выполнения разовой задачи до её успешного завершения (а не бесконечно, как Deployment), а CronJob создаёт Job по расписанию в формате cron, то есть это механизм повторяющихся по времени задач. Как это работает подробнее Job следит за тем, чтобы заданное число Pod успешно завершилось (completions), и при сбое может пересоздать Pod согласно backoffLimit; после успешного завершения Pod не перезапускается. CronJob на основе расписания создаёт новый объект Job в нужный момент времени, делегируя ему фактическое выполнение. Пример кода Что использовать на практике Практика. Job используют для разовых задач — миграции базы данных, пакетная обработка данных, обучение модели; CronJob — для регулярных задач, например ночного бэкапа или ротации отчётов. Важно учитывать политику concurrencyPolicy (Allow/Forbid/Replace) на случай, если предыдущий запуск ещё не завершился к моменту следующего. Подводные камни Риски. использовать Deployment для разовой задачи вместо Job — Deployment будет

Читать полностьюbatch-workloads

Короткий ответ imagePullPolicy управляет тем, когда kubelet скачивает образ контейнера: Always — каждый раз перед запуском проверяет реестр и скачивает образ заново; IfNotPresent — использует локально закэшированный образ, если он уже есть на узле; Never — запрещает скачивание, используя только локальный образ. Как это работает подробнее по умолчанию Kubernetes выбирает Always, если тег образа — latest или не указан, и IfNotPresent для любого другого явного тега. Это поведение по умолчанию можно переопределить явно в манифесте. Пример кода Что использовать на практике Практика. IfNotPresent ускоряет запуск и снижает нагрузку на реестр образов, но требует, чтобы тег образа был уникальным и неизменяемым (immutable) — то есть при каждом новом релизе должен использоваться новый тег, а не повторное использование старого с другим содержимым. Never применяют в основном в локальной разработке (minikube/kind), где образ собран прямо на узле. Подводные камни Риски. использовать тег latest в продакшене — это заставляет

Читать полностьюcontainer-images

Короткий ответ При удалении Pod Kubernetes параллельно отправляет контейнеру сигнал SIGTERM и начинает исключать под из endpoints Service; у приложения есть время до истечения terminationGracePeriodSeconds (по умолчанию 30 секунд), чтобы корректно завершить текущие запросы и закрыть соединения, после чего, если процесс ещё жив, отправляется SIGKILL. Как это работает подробнее удаление из списка endpoints Service и отправка SIGTERM контейнеру происходят практически одновременно, но не атомарно — из-за распределённой природы системы (kube-proxy на разных узлах, разная задержка синхронизации) часть входящих соединений может прийти на под уже после получения им SIGTERM, но до того, как все узлы обновили свои правила маршрутизации. Поэтому приложению недостаточно просто мгновенно завершиться по SIGTERM — ему нужно продолжать обрабатывать уже начатые запросы (и желательно ещё немного новых) в течение короткого окна. Пример кода Что использовать на практике Практика. типичная правильная стратегия — по получении SIGT

Читать полностьюgraceful-shutdown

Короткий ответ cordon помечает узел как непланируемый (Unschedulable), не трогая уже работающие на нём поды, тогда как drain дополнительно корректно выселяет (evict) существующие поды через Eviction API, уважая PodDisruptionBudget, graceful shutdown и terminationGracePeriod, в отличие от аварийного удаления узла, при котором поды просто теряются и пересоздаются только после истечения таймаута обнаружения недоступности узла. Как это работает подробнее cordon — это декларативное изменение spec.unschedulable: true у объекта Node, после которого планировщик просто не рассматривает этот узел для новых Pod, но ничего не делает с текущими. drain сначала выполняет cordon, а затем вызывает Eviction API для каждого пода на узле (кроме управляемых DaemonSet и ряда системных), ожидая, что каждый под корректно завершится и будет пересоздан контроллером (Deployment/StatefulSet) на другом узле, при этом соблюдая ограничения PodDisruptionBudget. Пример кода Что использовать на практике Практика. перед плановым обслуживанием

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

Короткий ответ kubeconfig — это файл с данными для подключения к одному или нескольким кластерам (адрес API сервера, учётные данные, сертификаты), а контекст внутри него — именованная комбинация "кластер + пользователь + namespace по умолчанию"; переключение контекста определяет, к какому кластеру и под каким пользователем будут выполняться команды kubectl. Как это работает подробнее по умолчанию kubectl читает файл ~/.kube/config (или путь из переменной KUBECONFIG), который может содержать несколько записей clusters, users и contexts; активный контекст (current-context) определяет, какая комбинация используется при выполнении команд без явного указания --context. Пример кода Что использовать на практике Практика. при работе с несколькими кластерами (например, dev и prod) критично перед выполнением потенциально опасной команды проверять текущий контекст (kubectl config current-context), чтобы случайно не применить изменения не в том окружении. Для автоматизации (CI/CD) обычно используют отдельный ServiceAccou

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