Что такое виртуализация?
В момент появления понятия виртуализации, оно представляло собой метод логического разделения мейнфреймов для одновременной работы нескольких приложений. Однако с развитием технологий появилась возможность одновременной работы нескольких операционных систем на одном сервере x86, что значительно изменило смысл виртуализации.
В результате виртуализация позволяет запускать две различные операционные системы на одном устройстве. Первая операционная система может использоваться для административных целей, в то время как остальные гостевые операционные системы загружаются как обычно, включая инициализацию и загрузку ядра. Этот метод также обеспечивает повышенный уровень безопасности, так как гостевая операционная система не имеет полного доступа к управляющей (host) операционной системе, что помогает избежать возможных уязвимостей в безопасности.
Есть три типа виртуализации:
✍🏻 Паравиртуализация
✍🏻 Эмуляция
✍🏻 Контейнерная виртуализация
Библиотека собеса по DevOps
В результате виртуализация позволяет запускать две различные операционные системы на одном устройстве. Первая операционная система может использоваться для административных целей, в то время как остальные гостевые операционные системы загружаются как обычно, включая инициализацию и загрузку ядра. Этот метод также обеспечивает повышенный уровень безопасности, так как гостевая операционная система не имеет полного доступа к управляющей (host) операционной системе, что помогает избежать возможных уязвимостей в безопасности.
Есть три типа виртуализации:
✍🏻 Паравиртуализация
✍🏻 Эмуляция
✍🏻 Контейнерная виртуализация
Библиотека собеса по DevOps
Объясни разницу между layer-кэшем сборки и BuildKit-кэшем через RUN --mount=type=cache/--mount=type=secret, как они инвалидируются и как делиться кэшем между машинами.
Layer-кэш — это слои образа: ключ — инструкция и входы шага (для COPY/ADD — хэш содержимого, для RUN — команда + предыдущие слои); изменение любого раннего шага сбрасывает все ниже, кэш хранится в локальном image store и по сути переносится только вместе с образом. даёт временный RW-каталог для шага, содержимое не попадает в слой и уменьшает размер образа; кэш живёт отдельно от образа и идентифицируется id/target, подходит для пакетных менеджеров/сборок. подаёт секрет как файл только на время шага, он не записывается в слой и не «утекает» в историю; сам факт секрета не ломает кэш шага. Для обмена кэшем: в Buildx — (local|registry), а для наследования кэша слоёв через реестр — пушить образ (или использовать ).
Библиотека собеса по DevOps
--mount=type=cache--mount=type=secret--cache-to/--cache-from inline-cache/BUILDKIT_INLINE_CACHE=1Библиотека собеса по DevOps
❤3
Что такое архитектура «Shared-Nothing»?
Это архитектура, в которой данные извлекаются из одного, не общего источника, обычно подключенного исключительно к одному узлу, в отличие от архитектур, в которых запрос может попасть на один из многих узлов, а данные будут извлечены из одного общего места (хранилища, памяти).
Библиотека собеса по DevOps
Библиотека собеса по DevOps
Расскажите подробнее о kube-scheduler.
Kube-scheduler распределяет и управляет рабочей нагрузкой на рабочих узлах. Он использует различные политики для выбора наиболее подходящего узла для pod на основе таких факторов, как требования к ресурсам, емкость узла и соответствие/несоответствие pod. Компонент kube-scheduler также отвечает за привязку выбранного узла к pod и обновление сервера Kubernetes API с обновленной информацией.
Библиотека собеса по DevOps
Библиотека собеса по DevOps
Как Docker ограничивает CPU и почему --cpus может вызвать лаги?
Через cgroups/CFS: --cpus задаёт квоту (cpu.max), при всплесках планировщик «душит» контейнер (throttling) → задержки. Для стабильности — пинning ядёр --cpuset-cpus + разумная квота/period; для мягкого приоритета — --cpu-shares (только вес при конкуренции).
Библиотека собеса по DevOps
Библиотека собеса по DevOps
⏳ Время прокачать алгоритмы с 40-процентной скидкой до конца октября
На собеседовании не просят бездумно написать шаблонное решение. Важно понимать, как работают алгоритмы под капотом.
🔹 В курсе ты научишься:
— искать ошибки с помощью редакционного расстояния;
— работать с балансированными деревьями и графами;
— решать задачи с динамическим программированием;
— и многое другое, что пригодится на собеседованиях.
🤔 Решаешь задачи только в тг каналах? Пройди курс и отправляйся на реальные собеседования!
🔗 Подробнее о курсе
На собеседовании не просят бездумно написать шаблонное решение. Важно понимать, как работают алгоритмы под капотом.
🔹 В курсе ты научишься:
— искать ошибки с помощью редакционного расстояния;
— работать с балансированными деревьями и графами;
— решать задачи с динамическим программированием;
— и многое другое, что пригодится на собеседованиях.
🤔 Решаешь задачи только в тг каналах? Пройди курс и отправляйся на реальные собеседования!
🔗 Подробнее о курсе
Что такое API-шлюз?
API-шлюз подобен привратнику, который контролирует, как различные части взаимодействуют друг с другом и как происходит обмен информацией между ними.
API-шлюз обеспечивает единую точку входа для всех клиентов и может выполнять несколько задач, включая маршрутизацию запросов к соответствующей внутренней службе, балансировку нагрузки, безопасность и аутентификацию, ограничение скорости, кэширование и мониторинг.
Используя API-шлюз, организации могут упростить управление своими API, обеспечить согласованную безопасность и управление, а также улучшить производительность и масштабируемость своих внутренних сервисов. Они также широко используются в архитектурах микросервисов, где есть много небольших независимых служб, к которым необходимо получать доступ разным клиентам.
Библиотека собеса по DevOps
API-шлюз обеспечивает единую точку входа для всех клиентов и может выполнять несколько задач, включая маршрутизацию запросов к соответствующей внутренней службе, балансировку нагрузки, безопасность и аутентификацию, ограничение скорости, кэширование и мониторинг.
Используя API-шлюз, организации могут упростить управление своими API, обеспечить согласованную безопасность и управление, а также улучшить производительность и масштабируемость своих внутренних сервисов. Они также широко используются в архитектурах микросервисов, где есть много небольших независимых служб, к которым необходимо получать доступ разным клиентам.
Библиотека собеса по DevOps
Объясните, что такое распределенные вычисления (или распределенные системы).
По словам Мартина Клеппманна:
«Множество процессов, работающих на многих машинах... только передача сообщений через ненадежную сеть с переменными задержками, и система может страдать от частичных сбоев, ненадежных часов и остановок процессов».
Другое определение: «Системы, которые физически разделены, но логически связаны».
Библиотека собеса по DevOps
«Множество процессов, работающих на многих машинах... только передача сообщений через ненадежную сеть с переменными задержками, и система может страдать от частичных сбоев, ненадежных часов и остановок процессов».
Другое определение: «Системы, которые физически разделены, но логически связаны».
Библиотека собеса по DevOps
Как выполняются обновления и откаты в Kubernetes?
Развёртывания Kubernetes поддерживают непрерывные обновления, что позволяет избежать простоев. Вы можете выполнить непрерывные обновления, отредактировав развёртывание или явно указав новую версию его образа, используя:
Затем вы можете проверить статус развертывания:
Если вы хотите вернуться к предыдущей версии, вы можете выполнить:
Библиотека собеса по DevOps
Развёртывания Kubernetes поддерживают непрерывные обновления, что позволяет избежать простоев. Вы можете выполнить непрерывные обновления, отредактировав развёртывание или явно указав новую версию его образа, используя:
kubectl set image deployment/my-deployment nginx=nginx:1.21
Затем вы можете проверить статус развертывания:
kubectl rollout status deployment my-deployment
Если вы хотите вернуться к предыдущей версии, вы можете выполнить:
kubectl rollout undo deployment my-deployment
Библиотека собеса по DevOps
Как спроектировать Docker-образ для продакшна так, чтобы он был маленький, быстро собирался, воспроизводился и был безопасным?
Multi-stage build: отдельно builder и runtime; в финал копируйте только артефакты.
База: минимальные образы (distroless/scratch) уменьшают поверхность атаки; Alpine лёгкий, но musl ≠ glibc — учитывайте совместимость.
Кэш и слои: сначала копируйте lock-файлы зависимостей, устанавливайте deps, затем код — так сохраните кэш; используйте .dockerignore.
BuildKit: включайте BUILDKIT; --mount=type=cache для кэша зависимостей, --mount=type=secret для секретов (не оставляйте их в слоях).
COPY vs ADD: по умолчанию COPY; ADD только для авто-распаковки tar/редких кейсов.
ENTRYPOINT/CMD: используйте exec-форму; ENTRYPOINT — бинарь, CMD — дефолтные аргументы.
Безопасность: USER — непривилегированный; read-only FS, drop capabilities, никакого --privileged; пакеты и компиляторы не тащите в финальный слой.
Воспроизводимость: пингуйте версии и базовые образы по digest, избегайте latest; фиксируйте часовой пояс/локаль если важно.
Runtime-гигиена: HEALTHCHECK, лимиты ресурсов, логи в stdout/stderr, состояние — только во внешних томах.
Снабжение артефактами: публикуйте SBOM/подписи (provenance, cosign) и прогоняйте image-сканы на уязвимости.
Мультиархитектура: buildx/manifest list для --platform (amd64/arm64) без двойной поддержки образов.
Библиотека собеса по DevOps
База: минимальные образы (distroless/scratch) уменьшают поверхность атаки; Alpine лёгкий, но musl ≠ glibc — учитывайте совместимость.
Кэш и слои: сначала копируйте lock-файлы зависимостей, устанавливайте deps, затем код — так сохраните кэш; используйте .dockerignore.
BuildKit: включайте BUILDKIT; --mount=type=cache для кэша зависимостей, --mount=type=secret для секретов (не оставляйте их в слоях).
COPY vs ADD: по умолчанию COPY; ADD только для авто-распаковки tar/редких кейсов.
ENTRYPOINT/CMD: используйте exec-форму; ENTRYPOINT — бинарь, CMD — дефолтные аргументы.
Безопасность: USER — непривилегированный; read-only FS, drop capabilities, никакого --privileged; пакеты и компиляторы не тащите в финальный слой.
Воспроизводимость: пингуйте версии и базовые образы по digest, избегайте latest; фиксируйте часовой пояс/локаль если важно.
Runtime-гигиена: HEALTHCHECK, лимиты ресурсов, логи в stdout/stderr, состояние — только во внешних томах.
Снабжение артефактами: публикуйте SBOM/подписи (provenance, cosign) и прогоняйте image-сканы на уязвимости.
Мультиархитектура: buildx/manifest list для --platform (amd64/arm64) без двойной поддержки образов.
Библиотека собеса по DevOps