Контейнеры и Kubernetes: от образа до обновления без простоя

Контейнер — управляемое окружение приложения, образ — его исходное содержимое. Среда выполнения создаёт окружение и запускает процесс. Наличие файла образа или идентификатора экземпляра ещё не означает, что приложение работает.

Пространства имён Linux разделяют видимость процессов, сети и подключённых файловых систем. Cgroup отдельно учитывает и ограничивает ресурсы. Если контейнер не видит соседей, это ещё не защищает общую память от исчерпания.

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

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

Манифест OCI связывает конфигурацию и упорядоченные слои. Слой хранит изменения файлов, конфигурация — сведения о платформе и настройки запуска. Проверка одного слоя не заменяет проверку образа целиком.

Индекс может объединять разные манифесты для amd64 и arm64. Общая метка не доказывает наличие нужного варианта. До замены архитектуры серверов проверьте платформу образа и работоспособность приложения на ней.

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

Удаление секрета в верхнем слое скрывает путь, но не очищает нижний. Проверяйте все сохраняемые слои. Если образ уже передали тем, кто не должен знать секрет, одной пересборки мало: раскрывшиеся учётные данные нужно отозвать и заменить.

OCI описывает форматы и запуск; это не оркестратор. Заявление о поддержке OCI не выбирает число копий, узел размещения и правила изоляции за заказчика.

Метка, даже похожая на номер версии, может быть переназначена. Дайджест закрепляет точный объект. В принятом выпуске сохраняют и читаемую метку, и дайджест, а также ожидаемую аппаратную платформу.

Реестр распространяет содержимое, узел может хранить его в кэше. При IfNotPresent старый узел использует сохранённый образ, но новый зависит от реестра. При Always и ссылке с меткой узел обращается к реестру, чтобы определить соответствующий ей дайджест; уже сохранённые слои можно использовать повторно.

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

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

Управляющие компоненты хранят состояние и принимают решения, а службы узлов запускают назначенные Pod. Доступный API и работающая пользовательская операция проверяют разные части системы.

Планировщик выбирает узел, kubelet и среда выполнения запускают контейнеры. Успешное назначение ещё не проверяет получение образа и готовность приложения. Ошибку после назначения нужно искать на соответствующем этапе.

Контейнеры одного Pod размещаются вместе и разделяют сеть. Два контейнера внутри Pod не дают независимых копий сервиса. Для резервирования нужны отдельные Pod и проверка распределения по узлам.

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

Целевое состояние хранит требуемый результат, цикл согласования поддерживает его повторными действиями. Принятая спецификация не означает готовность: ресурсов или подходящего размещения может не хватать.

Deployment управляет ReplicaSet, а ReplicaSet — Pod. При неизменном целевом числе контроллер стремится создать новый Pod взамен удалённого. Для постоянного уменьшения числа экземпляров меняют цель Deployment.

Проверьте владельцев и селекторы. Несогласованные управляющие объекты с пересекающимися селекторами могут одновременно управлять одними и теми же Pod и перебивать решения друг друга. Ручная правка производного объекта не исправляет конфликт целей.

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

Request участвует в размещении, limit ограничивает выполнение, потребление измеряют под нагрузкой. Запрос не является жёстким потолком; лимиты сами по себе не подтверждают, что узел выдержит одновременный пик всех контейнеров.

500m CPU — половина единицы CPU Kubernetes, не 500 МГц. В памяти 1Gi и 1G означают разные числа байтов. При расчёте по контейнерным requests складывайте запросы одновременно работающих контейнеров. Если посчитать только приложение и забыть постоянно работающий прокси или сборщик журналов, требования Pod будут занижены.

Вспомогательный контейнер в initContainers с restartPolicy=Always продолжает работать вместе с приложением: его запрос входит в общую сумму. На каждом шаге подготовки учитывают также уже запущенные вспомогательные контейнеры. Для каждого ресурса берут большее из пика подготовки и суммы длительной работы. Ресурсы уровня Pod и накладные расходы проверяют отдельно.

В Linux запрос CPU также влияет на относительный вес контейнера при конкуренции за процессор. Это не закрепление отдельного ядра. Снижая request ради плотности размещения, учитывайте и распределение процессорного времени под нагрузкой.

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

Для приложений используют Node Allocatable после системных резервов, а не всю установленную память. Проверьте requests в самом объекте, а не только в исходном файле: при заданном limit и отсутствии запроса Kubernetes может подставить его из лимита.

Шесть экземпляров требуют 6 CPU и 12 ГиБ. После отказа останутся 8 CPU и 16 ГиБ Node Allocatable. По три таких Pod помещаются на каждом из двух узлов: 3 CPU и 6 ГиБ. Это проверка запросов при отсутствии иных нагрузок, а не доказательство производительности на пике.

Всегда проверяйте размещение по узлам. Если на двух подходящих узлах осталось по 3 ГиБ для новых запросов, один Pod с запросом 4 ГиБ не поместится ни на одном. Общий свободный объём кластера не устраняет эту нехватку.

Жёсткое правило распределения может запретить использование свободного узла. Если допустимого узла нет, Pod остаётся без назначения. Мягкое правило даёт предпочтение, но допускает иной результат. Проверьте поведение после отказа вместе с метками размещения и физической независимостью узлов.

Потерянный Pod не мигрирует с прежним UID. Для управляемой нагрузки контроллер может создать новый Pod; он не наследует память старого процесса. Для временных данных старого Pod также нельзя предполагать автоматический перенос на другой узел.

Pending бывает и до назначения узла, и после него. Сначала проверьте, назначен ли узел, затем события и состояния контейнеров. Наращивание CPU не исправит ошибку получения образа у уже назначенного Pod.

Обычный ClusterIP Service даёт стабильный адрес, но не создаёт Pod. Имя DNS и адрес могут существовать при нуле готовых экземпляров. Проверка разрешения имени не заменяет проверку адресов приложения за службой.

Селектор выбирает Pod по меткам. Сопоставьте его с нужным приложением: ошибка может дать пустой набор или выбрать чужие экземпляры. Затем проверьте port и targetPort: при 80 и 8080 приложение должно слушать на стороне назначения порт 8080.

У одного Service может быть несколько EndpointSlice, например для разных семейств IP или наборов портов. Проверяйте все срезы службы: один объект может показывать только часть адресов, а число срезов не равно числу экземпляров приложения.

Когда readiness достигнет порога неудач, адрес может остаться в EndpointSlice со значением ready=false. Наличие адреса ещё не означает, что Service выбирает его для обычного трафика. Если включён publishNotReadyAddresses, служба допускает и неготовые адреса: это отдельная настройка доступа.

Running описывает состояние Pod и контейнеров, а не успешность операции пользователя. Даже готовность проверяет только выбранные условия. Завершите приёмку контрольной операцией приложения, а не чтением одного состояния Kubernetes.

При clusterIP=None виртуального адреса ClusterIP нет. Для такой службы используйте модель отдельных адресов приложения: ожидание общего виртуального адреса даст неверный диагноз.

Readiness меняет готовность к трафику и сама не перезапускает контейнер. После восстановления она может вернуть его в готовность без нового процесса. Проверка необязательной общей зависимости рискует одновременно убрать из трафика все копии.

Liveness после порога неудач заставляет kubelet завершить контейнер; следующий запуск зависит от политики перезапуска. Применяйте её там, где новый процесс способен устранить неисправность. Недоступная общая база данных от такого действия не восстановится.

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

Startup блокирует readiness и liveness до первого успеха. При failureThreshold=30 и periodSeconds=10 расчётный бюджет — около 300 секунд, а не точный таймер завершения. Успех через 20 секунд снимает блокировку остальных проб, не дожидаясь остатка этого бюджета.

Успех startup завершает начальную проверку, а после перезапуска контейнера она выполняется заново. Дальнейшую готовность и работоспособность проверяют readiness и liveness, если они настроены. Отсутствующую проверку приложения Kubernetes не придумывает; Running или успех liveness не подтверждает нужную пользовательскую операцию.

Параметр maxSurge допускает дополнительные копии, maxUnavailable — сокращение числа доступных копий. Проценты округляют соответственно вверх и вниз. Для трёх копий и обоих значений 25% получится одна дополнительная и ноль недоступных. Новая копия должна поместиться до сокращения доступного числа старых; иначе обновление может остановиться.

Расчёт «три плюс одна» не является потолком фактического расхода ресурсов. Завершающиеся Pod могут ещё потреблять CPU и память после начала замены. Проверьте время завершения процессов и запас на этот переход.

Нельзя одновременно задать maxSurge=0 и maxUnavailable=0. Для замены нужна либо временная дополнительная копия, либо разрешённое сокращение доступного числа. Выбор сверяют с вместимостью узлов и требуемой мощностью приложения.

Readiness и minReadySeconds определяют разные условия. При положительном minReadySeconds новый Pod должен оставаться готовым без сбоев контейнеров заданное время, чтобы считаться доступным. Один быстрый успех пробы не доказывает выполнение этого периода.

Старые и новые копии могут работать одновременно. Проверьте совместимость обращений к общим данным, завершение текущих запросов и достаточность готовой мощности. Успешный RollingUpdate сам по себе не доказывает отсутствие простоя.

Истечение progressDeadlineSeconds отмечает недостаточный ход обновления и само не запускает откат. В плане выпуска заранее определяют ответственного и действие по этому сигналу; ожидание не возвращает старую версию автоматически.

История хранится в ReplicaSet. Параметр revisionHistoryLimit задаёт число старых ReplicaSet, а не дни хранения. Проверьте наличие нужной ревизии и образов: частые выпуски могут вытеснить историю, а дайджест не удерживает содержимое в реестре.

Откат Deployment возвращает шаблон Pod. Он не восстанавливает внешнюю базу и отдельно изменённую конфигурацию. До выпуска проверьте, сможет ли старое приложение работать с данными после новой версии и какой порядок восстановления принят.

ConfigMap в переменных окружения не обновляет уже работающий процесс автоматически. Предусмотрите замену Pod и проверку значений. При передаче через том обновление может прийти с задержкой; подключение через subPath таких обновлений не получает.

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

Поставка образа: зафиксируйте платформенный вариант, дайджест и проверенное происхождение. Испытайте получение принятого и откатного выпусков на узле без кэша. Работа старого узла не подтверждает восстановимость через реестр.

Ресурсы и отказ: рассчитайте requests по подходящим узлам и после потери одного из них. Затем измерьте приложение под нагрузкой. Размещение по запросам не доказывает время ответа, а общий запас кластера не гарантирует место для конкретного Pod.

Доступность: проверьте выбранные адреса, готовность, поведение проб и результат операции клиента. При отказе узла подтвердите создание нового Pod и отдельно — доступность данных. Один статус Running не закрывает эти проверки.

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