[Начало аудиозаписи (бодрый голос, с нотками цинизма и усталости)]

Протокол вскрытия № 666-IT/2025. Дата: 17 мая 2025 года. Время: 05:30.

- Я, ведущий DevOps-патологоанатом Сисадминов А.А., приступаю к патологоанатомическому исследованию неопознанного распределенного монолита, поступившего из ООО "Светлое Будущее" после фатального падения системы, зафиксированного 16 мая 2025 в 23:58 по московскому времени.

- Присутствуют: я, младший специалист Логинов П.Р., стажер Архитекторова Н.Ю.

- Итак, начнем. Внешний осмотр. Перед нами типичный корпоративный монолит — старожил цифрового мира. Судя по следам от PHP 5.3 в виде комментариев к коду, датированным 2011 годом, ему не меньше 14 лет. Внушительный возраст для любой системы в кровавом Энтерпрайзе, не находите, Логинов?

- Да, это почти живой мамонт!

- Отмечаю критическую анемию документации. В репозитории — одинокий README.md от 2012 года с гордой надписью "TODO: написать документацию".

- Так, что у нас тут… Kubernetes? О, да! Модный, молодежный. Оркестрация уровня «дирижер в запое». Поды висят в CrashLoopBackOff чаще, чем разработчики этого чуда видят кофейный аппарт. Логи… о, мда, логи! «Something went wrong», «Error: null», «PANIC: KERNEL PANIC (not really, just kidding, or am I?)». Креативненько, ничего Логинов, возьмите образцы на анализ.

- Первичный осмотр выявляет множественные очаги копипасты. Особенно вопиющий случай — модуль авторизации. Код проверки прав доступа размножен 47 раз с минимальными правками. Это уже не просто технический долг, это цирк абсурда ролевых моделей!

- Вижу следы восьми разных фреймворков, некоторые из которых не совместимы. Это мне напоминает "инновационный борщ, тёщи, приправленный усушенными котлетками и жаренными пельменями", брр. А вот это что? Закомментированный кусок кода с пометкой «// Игорь, это не трогай, я сам не знаю, как оно работает, но без него все падает!!!11». Игорь, если ты это слышишь, ты был не прав – оно и с ним упало. Из мешанины использованных языков программирования в разных модулях, можно предположить, что разработчики стремились изобрести свой высокоуровневый Brainf**k, совсем чуточку не успели.

- Ага, вот и причина непосредственного отказа. Один из «сервисов» решил, что ему мало 128 Гб оперативной памяти и попытался сожрать еще столько же из свопа. Классический OOM Killer пришел и сделал свою работу. Но это, так сказать, орудие убийства. Причина отказа куда глубже.

[идет продолжительная работа]

- Отказ наступила из-за необратимых изменений кода, навороченных за 13 лет разными разработчиками с их "уникальным видением". Рекомендации родственникам: кремация кодовой базы и старт с нуля. Пациент был нежизнеспособен с момента зачатия идеи в воспаленном мозгу тимлида.

- Ладно, хватит лирики. Пойду оформлять официальный протокол, Логинов, мне нужны результаты анализов. Эти бюрократы из «МинЦифЗдрава» требуют всё по форме.

[Щелчок выключения диктофона]

УТВЕРЖДАЮ

Заместитель начальника Отдела цифровой патологии и реанимации информационных систем

И.И. Кибернетиков

«18» мая 2025 г.

ПРОТОКОЛ № 666-IT/2025 патологоанатомического вскрытия информационной системы

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

Дата и время поступления системы: 17.05.2025, 04:48 (MSK)

Идентификатор «умершего»: Проект «Прорыв-2012», версия - неизвестная.

Возраст (время эксплуатации до фатального сбоя): 14 лет, 3 месяца, 2 дня (в режиме «постоянно падает, но мы поднимаем»).

Дата и время «полного отказа»: 16.05.2025, 23:58 (MSK)

Основной «клинический» диагноз (предварительное заключение службы эксплуатации): «Все сломалось, ничего не работает, пользователи в ярости, не могут закрыть спринт».

Дата и время вскрытия: 17.05.2025, 05:30 (MSK)

Вскрытие производил: Ведущий DevOps-патологоанатом Сисадминов А.А.

Присутствовали: Младший специалист по цифровой некроскопии Логинов П.Р., стажер Архитекторова Н.Ю. (сбежала через 15 минут с криком «О боже! Да я лучше бухгалтерию, буду переводить на метод ФИФО!»).

НАРУЖНЫЙ ОСМОТР СИСТЕМЫ: «Кожные пользовательские интерфейсы» недоступны, ответ сервера HTTP 503 (Service Unavailable) на всех эндпоинтах. «Трупные ошибки в логах» обильные, хаотично распределены по всем компонентам системы. «Трупное зависание процессов» наблюдается в 6 из 8 основных модулей. Сопроводительная документация-анамнез разработки фрагментарна, содержит ненормативную лексику и наскальные рисунки, не относящиеся к делу. Архитектурная схема представлена в виде эскиза на длинном бумажном чеке из КБ, вызывает сомнения.

ВНУТРЕННЕЕ ИССЛЕДОВАНИЕ СЕРВИСОВ И ПОЛОСТЕЙ СИСТЕМЫ:

1. «Центральная нервная система Оркестратор Kubernetes»: Версия 1.25.х (устаревшая). Множественные Pod'ы в состоянии CrashLoopBackOff и ImagePullBackOff. Обнаружены некорректно сконфигурированные readiness и liveness пробы, приводящие к преждевременному «умерщвлению» работоспособных экземпляров. Конфигурационные файлы содержат критические данные в открытом виде.

2. «Сердечно-сетевая система межсервисного взаимодействие»: Топология сети избыточно сложная, напоминает «Гордиев узел». Задержки при взаимодействии между «микросервисами» достигают нескольких десятков секунд. Обнаружены следы использования самописного протокола поверх HTTP/1.1 для передачи бинарных данных, что приводило к их регулярной закупорке каналов связи. «Микросервисы» по факту являются монолитными приложениями, упакованными в Docker-контейнеры, с высоким уровнем связанности (tight coupling).

3. «Дыхательная API Gateway система»: API Gateway перегружен из-за отсутствия кэширования и неоптимальных запросов от фронтенда. Модуль «AuthService» демонстрирует признаки «гипертрофии» (размер Docker-образа 3 Гб) и «кислородного голодания» (регулярные OOM Killed). Обнаружены многочисленные хардкод-адреса зависимых сервисов.

4. «Пищеварительная база данных»: Основная СУБД PostgreSQL – горизонтально шардированная. Структура БД ненормализована, наименования таблиц и полей не соответствуют общепринятым стандартам (например, tbl_prod_final_v2_important). Индексы на часто запрашиваемых полях отсутствуют. Обнаружены следы «несварения» данных (неконсистентность) между репликами. Обнаружена метастаза в виде документно-ориентированной MongoDB из одной коллекции, c полу структурированными данными.

5. «Опорно-двигательная кодовая база»: Код написан на смеси Python, Go и Node.js (в рамках одного «микросервиса»), в наличии остаточные следы PHP. Присутствуют многочисленные «велосипеды» (самописные решения для стандартных задач). Уровень покрытия тестами – предположительно, менее 5%. Обнаружены закомментированные участки кода с пометками «не трогать, магия» и «костыль, убрать перед релизом».

ПАТОЛОГОАНАТОМИЧЕСКИЙ ДИАГНОЗ:

• Основное «заболевание»: Острая декомпенсированная архитектурная недостаточность, развившаяся на фоне тотального игнорирования принципов проектирования распределенных систем и DevOps-практик. Тип: «Распределенный Монолит с полиорганной дисфункцией микросервисов».

• Осложнения: Синдром каскадного отказа модулей. Терминальная стадия технического долга. Критическая зависимость от «магического кода Игоря», о чем свидетельствуют множественные коммиты. Фатальные уязвимости безопасности.

• Сопутствующие «заболевания»: Хроническое отсутствие автоматизированного тестирования. Дефицит компетентной документации. Синдром «Неприятия чужой разработки» (NIH) в тяжелой форме.

ЗАКЛЮЧЕНИЕ О ПРИЧИНЕ «ОТКАЗА» СИСТЕМЫ: «Отказ» информационной системы «Прорыв-2012» наступила в результате совокупности критических архитектурных просчетов, некомпетентной реализации, отсутствия контроля качества и пренебрежения базовыми принципами разработки и эксплуатации ПО. Непосредственной причиной остановки функционирования явился отказ модуля «AuthService» вследствие исчерпания выделенных ресурсов памяти (OOM Killer), что вызвало цепную реакцию отказа зависимых компонентов. Система стала нежизнеспособна в долгосрочной (и, как оказалось, краткосрочной) перспективе.

РЕКОМЕНДАЦИИ:

1. Признать проект «Прорыв-2012» полностью несостоятельным.

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

3. Останки системы (репозитории, артефакты сборки, конфигурации) архивировать с пометкой «Крайне токсично. Не реанимировать!».

4. Команде разработки в полном составе пройти курсы повышения квалификации по темам: «Основы архитектуры ПО», «DevOps для чайников», «Тестирование – это не больно».

5. При планировании аналогичных проектов в будущем закладывать бюджет на привлечение внешних ИТ-архитекторов и независимых стейколдеров.

Ведущий DevOps-патологоанатом

___________________ Сисадминов А.А.

М.П. (Отдела Цифровой Патологии)

Меня зовут Александр, я CTO компании AppFox. Мы более 10 лет занимаемся заказной разработкой и также имеем собственные продукты.

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

Что такое Kubernetes простыми словами?

Разберем на примере интернет-магазина с тремя серверами:

1. Сервер №1 – основной (принимает заказы).

2. Сервер №2 – база данных (хранит товары и пользователей).

3. Сервер №3 – бекенд для API (обрабатывает платежи).

Проблема:

• В Чёрную пятницу приходит в 10 раз больше покупателей. В результате, сервера №1 и №3 падают от нагрузки, магазин "висит".

• Сервер №2 (база данных) ломается, а все заказы теряются.

• Чтобы добавить новые сервера, админ вручную копирует настройки, что занимает часы.

Решение при помощи Kubernetes.

Те же 3 сервера, но теперь они управляются Kubernetes.

1. Автомасштабирование

   • При наплыве покупателей Kubernetes автоматически запускает дополнительные копии серверов №1 и №3.

   • Когда нагрузка падает – лишние сервера отключаются.
     

2. Отказоустойчивость

   • Если сервер №2 (база данных) упал, Kubernetes сразу переключает нагрузку на его резервную копию.

   • Покупатели даже не замечают проблемы.
     

3. Гибкие обновления

   • Вы хотите обновить API (сервер №3).

   • Kubernetes делает это без downtime:

     • Запускает новые версии API, переключает трафик на них и останавливает старые.
       

4. Экономия денег

   • Ночью, когда магазин почти не используют, Kubernetes отключает часть серверов.

   • Утром – снова включает.

Что это даёт бизнесу?

• Магазин не "падает" в пиковые нагрузки (Чёрная пятница, распродажи).

• Нет потери заказов – если что-то сломалось, система сама всё починит.

• Быстрые обновления – можно выпускать новые фичи без остановки магазина.

• Экономия на серверах – не нужно держать "лишние" мощности.

Kubernetes: мощный инструмент, но не серебряная пуля

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

Термин k8s является синонимом Kubernetes и означает 8 букв между первой и последней буквой. Да, программисты любят сокращения :)

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

Когда Kubernetes оправдан:

• Микросервисная архитектура с большим количеством сервисов.

• Необходимость автоматического масштабирования под нагрузку.

• Высокие требования к отказоустойчивости.

• Гибкость деплоя (Canary, Blue-Green, A/B-тестирование).

Когда Kubernetes — избыточное решение:

• Монолитное приложение с низкой нагрузкой.

• Маленькие проекты без потребности в масштабировании.

• Стартапы с ограниченным бюджетом.

• Проект для демо или MVP, в которых планируется масштабирования только после получения инвестиций

• Команда не готова к сложности k8s (обучение и поддержка требуют ресурсов).

В компании AppFox мы используем Kubernetes при построения кластеров для мультиплеерных игр и проектов со сложной микросервисной архитектурой. В частности, мы его использовали при разработке решений для СберБанка и Банка ВТБ.

Основные понятия Kubernetes

• Pod — минимальная единица развертывания (может содержать один или несколько контейнеров).

• Deployment — декларативное описание желаемого состояния приложения.

• Service — абстракция для доступа к подам (ClusterIP, NodePort, LoadBalancer).

• Ingress — управление внешним трафиком (роутинг, SSL).

• ConfigMap & Secret — хранение конфигураций и чувствительных данных.

• PersistentVolume (PV) & PersistentVolumeClaim (PVC) — работа с постоянным хранилищем.

• Helm — менеджер пакетов для k8s (чарты).

Вопросы по Kubernetes на собеседовании

Теперь самое интересное — какие вопросы задают кандидатам в зависимости от их уровня.

Для backend-разработчика

Что такое контейнер и зачем нужен Docker?

• Контейнер - это изолированное окружение для запуска приложений со всеми зависимостями.

• Docker - платформа для создания и управления контейнерами.

Разница между Docker и Kubernetes

• Docker создает контейнеры

• Kubernetes управляет множеством контейнеров на разных серверах.

Как работает kubectl get pods? Что выведет эта команда?

Команда показывает список подов (pods) - минимальных единиц развертывания в k8s. Вывод включает имя пода, статус, количество рестартов и возраст.

Что такое Deployment и зачем он нужен?

Это объект k8s для декларативного управления подами. Позволяет:

• Разворачивать приложения

• Обновлять их (rolling update)

• Возвращаться к предыдущим версиям (rollback)

• Масштабировать количество реплик

Как приложение в k8s получает конфигурацию (ConfigMap, Secrets)?

• ConfigMap хранит конфигурации (например, настройки приложения)

• Secrets - чувствительные данные (пароли, токены). Они монтируются в поды как файлы или переменные окружения.

Что такое Pod, Deployment и Service?

• Pod — это минимальная единица в Kubernetes

• Deployment управляет жизненным циклом Pod'ов

• Service предоставляет сетевой доступ.

Как подать переменные окружения в Pod?

Через env, envFrom, ConfigMap, Secret.

Что произойдет, если Pod упал?

Kubernetes сам его перезапустит — важно понимать работу контроллеров.

Для Junior DevOps

Как создать под с помощью kubectl?

Как посмотреть логи пода?

Как работает Service? Какие типы сервисов знаете?

Абстракция для доступа к набору подов. Типы:

• ClusterIP (внутренний IP)

• NodePort (порт на каждой ноде)

• LoadBalancer (внешний балансировщик)

• ExternalName (CNAME-запись)

Как обновить приложение в k8s (стратегии деплоя)?

• RollingUpdate (постепенная замена подов)

• Recreate (удаление всех старых перед созданием новых)

Что делает kubelet и kube-proxy?

• kubelet - агент на нодах, запускает и контролирует контейнеры

• kube-proxy - обеспечивает сетевую связность между сервисами

Как создать кластер Kubernetes?

Как подключить volume к Pod'у?

Volume (том) в Kubernetes позволяет сохранять данные между перезапусками Pod'ов. Есть несколько типов томов, но для постоянного хранения данных используются PersistentVolume (PV) и PersistentVolumeClaim (PVC).

• PersistentVolume — это ресурс в кластере, представляющий физическое хранилище (например, диск в облаке или NFS-шару). PV создаётся администратором кластера и существует независимо от Pod'ов.

• PersistentVolumeClaim — запрос Pod'а на выделение PV. PVC связывается с подходящим PV (или динамически создаёт его, если настроен StorageClass). PVC монтируется в Pod как volume. Если не хочется создавать PV вручную, можно использовать StorageClass для автоматического создания томов.

Чем отличается Horizontal Pod Autoscaler от Vertical Pod Autoscaler?

• HPA масштабирует количество Pod'ов на основе метрик нагрузки (увеличивает или уменьшает число реплик (replicas) Deployment'а в зависимости от, например, CPU или памяти, т.е., нагрузка выросла — добавили ещё Pod'ов).

• VPA изменяет ресурсы (CPU, память) у контейнеров внутри Pod'а

Для Middle DevOps

Как настроить Ingress для доступа к сервису?

Как сделать Horizontal Pod Autoscaler (HPA)?

Как управлять ресурсами (requests/limits)?

Как настроить PersistentVolume для stateful-приложения?

Как диагностировать проблему с CrashLoopBackOff?

1. Посмотреть логи пода

2. Проверить readiness/liveness пробы

3. Убедиться, что контейнеру хватает ресурсов

4. Проверить монтирование томов

5. Изучить события кластера:kubectl describe pod <pod-name>kubectl get events

Для Senior DevOps

Как настроить NetworkPolicy для изоляции подов?

Как работает etcd и что делать при его проблемах?

Распределенное key-value хранилище - "мозг" Kubernetes. Проблемы и решения:

• Недостаток места: регулярная дефрагментация

• Высокая задержка: оптимизация сети

• Потеря кворума: восстановление из бэкапа

Как настроить мониторинг (Prometheus + Grafana)?

1. Установка Prometheus Operator

2. Настройка ServiceMonitor для сбора метрик

3. Создание Grafana дашбордов

4. Настройка алертов через Alertmanager

Как организовать multi-cluster управление?

Варианты:

• Kubefed (Federation v2)

• Cluster API

• Коммерческие решения (GKE Anthos, EKS Anywhere)
  Основные задачи: синхронизация ресурсов, единая аутентификация, централизованное логирование.

Как оптимизировать costs в облачном k8s (автоскейлинг нод)?

• Использование spot-инстансов

• Автомасштабирование нод (Cluster Autoscaler)

• Вертикальное масштабирование подов (VPA)

• Планирование подов на дешевые ноды (node affinity/taints)

• Использование serverless-решений (AWS Fargate, GCP Cloud Run)

Заключение: Kubernetes — мощный инструмент, но не панацея

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

Главный совет:

• Если у вас микросервисы, высокая нагрузка или требовательная инфраструктура — Kubernetes может стать вашим решением.

• Если проект небольшой или монолитный — начните с простых решений (Docker Compose, managed-сервисов) и масштабируйтесь постепенно.

Попробуйте Kubernetes в действии:

• Разверните локальный кластер через minikube или kind.

• Поэкспериментируйте с Helm-чартами и автоскейлингом.

• Изучите managed-решения (GKE/EKS/AKS), чтобы оценить их преимущества.