Объясни разницу между 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