Есливы работаете с Kubernetes, вы, вероятно, слышали объявление об устаревании dockershi в прошлом году (как часть выпуска Kubernetes v1.20). В то время был создан Dockershim Deprecation FAQ , где можно гораздо лучше понять план по его удалению из кодовой базы k8s, что, вероятно, произойдет в начале цикла разработки релиза 1.24 (вероятно, в процессе в данный момент) .
Но подождите, можем ли мы по-прежнему использовать Docker в Kubernetes 1.20?
Да, единственное, что изменилось в версии 1.20, — это один журнал предупреждений, который печатается при запуске kubelet, если в качестве среды выполнения используется Docker.
Просто предоставив вам краткое объяснение мотивации удаления dockershi из kubelet, в Kubernetes интерфейс CRI используется для общения со средой выполнения контейнера. Дизайн CRI заключается в том, чтобы иметь возможность запускать реализацию CRI как отдельный двоичный файл. Однако в настоящее время CRI docker (он же dockershim) является частью кода kubelet, работает как часть kubelet и тесно связан с жизненным циклом kubelet. Другими словами, kubelet имеет зависимость от конкретной среды выполнения контейнера, что не идеально. Это приводит к бремени обслуживания для разработчиков в узле подписи и администраторов кластера, когда критические проблемы (например, runc CVE) возникают во время выполнения контейнера.
Короче говоря, некоторые преимущества жизненного цикла kubelet мотивируют удаление dockerhim. Тем не менее, у нас также есть некоторые недостатки этого удаления, и один из недостатков является основной причиной, по которой я пишу эту статью:
- Пользователи должны изменить свои существующие рабочие процессы, чтобы адаптироваться к этим новым изменениям.
Почему Канико?
Канико решает две проблемы с помощью метода сборки Docker-in-Docker :
- Для работы Docker-in-Docker требуется привилегированный режим , что является серьезной проблемой безопасности.
- Docker-in-Docker обычно снижает производительность и может быть довольно медленным.
Прежде чем продолжить, позвольте мне представить вам, что такое Канико и как он работает.
Что такое Канико?
Kaniko — это инструмент для создания образов контейнеров из Dockerfile внутри контейнера или кластера Kubernetes. Канико не зависит от демона Docker и выполняет каждую команду в Dockerfile полностью в пользовательском пространстве. Это позволяет создавать образы контейнеров в средах, которые не могут легко или безопасно запускать демон Docker, например в стандартном кластере Kubernetes.
Короче говоря, Kaniko позволит вам создавать и отправлять образы в кластер Kubernetes без каких-либо специальных привилегий или разрешений, а также создавать их из Dockerfile без доступа к Docker Daemon.
Это здорово, потому что теперь нам больше не нужен Docker Daemon для создания образов контейнеров.
Как работает Канико?
Образ исполнителя kaniko отвечает за создание образа из Dockerfile и его отправку в реестр. В образе исполнителя мы извлекаем файловую систему базового образа (образ FROM в Dockerfile). Затем мы выполняем команды в Dockerfile, делая снимки файловой системы в пользовательском пространстве после каждой. После каждой команды мы добавляем к базовому образу слой измененных файлов (если они есть) и обновляем метаданные образа.
Известные вопросы
- kaniko не поддерживает создание контейнеров Windows.
- Запуск kaniko в любом образе Docker, отличном от официального образа kaniko, не поддерживается (например, YMMV).
- Это включает в себя копирование исполняемых файлов kaniko из официального образа в другой образ.
- kaniko не поддерживает API реестра v1 (устаревание API реестра v1 )
Подробнее о Канико можно посмотреть здесь .
Теперь, когда вы знаете, что такое Kaniko и как он работает, я покажу вам пример использования, где я расскажу, как настроить его с помощью Gitlab CI для создания образов докеров и отправки их в ECR (AWS Elastic Container Registry).
Пример использования
Я собираюсь показать вам сценарий, в котором мы используем:
- AWS Elastic Container Registry для хранения образов докеров
- Gitlab CI для автоматизации процесса создания образов контейнеров
- Gitlab Runners, работающие внутри кластера Kubernetes (EKS)
- Инструмент Kaniko, который будет отвечать за создание образа Docker на основе Dockerfile.
Учитывая, что мы запускаем Gitlab Runner в кластере EKS, первое, что нам нужно сделать, — это повысить разрешения роли IAM, используемой Gitlab Runner.
Если вы не знакомы с Gitlab CI или Gitlab Runners, подробнее см. здесь:
Шаг за шагом
Ниже приведены пошаговые инструкции, необходимые для настройки Kaniko для создания и отправки образов в ECR через Gitlab CI Pipeline:
Шаг 1. Добавьте следующую политику ECR в каждый репозиторий, в котором будут храниться образы, созданные Канико:
ПРИМЕЧАНИЕ. В строках 9, 10 и 11 видно, что мы даем разрешение на отправку и получение изображений трем ролям IAM, а в строках 29 и 30 мы разрешаем двум учетным записям AWS извлекать изображения.
Шаг 2. В этом сценарии наши Gitlab Runners используют роль IAM, что позволяет Kaniko отправлять данные в ECR без аутентификации. Итак, нам нужно привязать к IAM-роли следующую IAM-политику:
Эта политика включает следующие разрешения:
ecr– Позволяет участникам читать и записывать в репозитории, а также читать политики жизненного цикла. Участникам не предоставляется разрешение на удаление репозиториев или изменение применяемых к ним политик жизненного цикла.
Шаг 3. Создайте Dockerfile:
В этом примере мы собираемся создать Dockerfile для установки Terraform и Terragrunt:
Шаг 4. Настройте файл Gitlab CI (.gitlab-ci) в корне вашего репозитория:
Учитывая, что мы будем собирать образ с установленными Terraform и Terragrunt, вы увидите некоторые переменные, характерные для сборки этого образа, например, TF_VERSION и TG_VERSION.
ЗАМЕТКИ:
Ключевые слова, определенные здесь в этом конвейере:
В строке 1 мы определили этапы этого пайплайна. В этом случае у нас будет только файл Build.
От строки 5 до строки 10 у нас есть следующие переменные:
CONTAINER_REGISTRY: адрес ECR в регионе, который мы используем.
IMAGE_NAME: имя репозитория ECR.
IMAGE_TAG: Тег, который создаст Канико, в данном случае мы используем предопределенную переменную .
TF_VERSION: версия клиента Terraform.
TG_VERSION: версия клиента Terragrunt.
CACHE_TTL: Срок действия в часах.
С 12 по 22 строки мы определили шаблон (он же Gitlab Anchors для скриптов. Подробнее здесь ).
Со строки 24 по строку 35 у нас есть определение задания, где мы используем:
В строке 25 у нас есть Стадия, к которой относится эта Работа, Сборка.
От строки 27 до строки 29 у нас есть раздел изображения, где основной строкой является строка 28, указывающая на имя изображения, которое мы будем использовать для запуска задания. В этом случае рекомендуется отладочный образ kaniko (gcr.io/kaniko-project/executor:debug), так как он имеет оболочку, необходимую для работы с GitLab Runner. Подробнее здесь .
В строках 30 и 31 у нас есть определение извлечения образов докеров из ECR без аутентификации.
В строках 32 и 33 мы определяем сценарий, который нам нужно выполнить в этом задании. Вы можете видеть, что мы вызываем этот шаблон, определенный в строках с 12 по 22.
А в строках 34 и 35 мы контролируем, когда создаются рабочие места. В этом случае только при событиях push/merge для ветки main.
Подробнее о ссылке на ключевое слово для файла .gitlab-ci.yml см . здесь.
Вывод
Kaniko — это мощный инструмент для создания образов Docker без Docker Daemon. Для тех, кто работает с Gitlab CI, плюсом является поддержка использования Kaniko. Один из хороших аргументов, которым вы можете воспользоваться, используя Kaniko, касается кеша:
- — кеш=истина
- — cache-repo <ваш-ecr-репозиторий>
Используя эти два аргумента, вы можете сократить время сборки, поскольку Kaniko будет использовать ваш репозиторий ECR для хранения промежуточных слоев образов докеров, чтобы оптимизировать время сборки.
Об ответе на цитату Загадочника
Ответ: «возможность».
Итак, воспользуйтесь возможностью, чтобы получить эти советы, чтобы проверить и использовать гораздо больше Канико. знак равно
Спасибо за прочтение статьи и помните: — «знание, полученное, но не переданное, — это потерянное знание» — .
Эта статья является переводом – webera.blog
