На днях американский инженер Andrew Rynhard представил интересный проект: компактный дистрибутив Linux, предназначенный специально для запуска Kubernetes-кластеров. Он получил название из древнегреческой мифологии — Talos.

Прим. перев.: Оригинальная статья была написана инженером из Швеции — Christian Abdelmassih, — который увлекается архитектурой уровня enterprise, ИТ-безопасностью и облачными вычислениями. Недавно он получил степень магистра в области Computer Science и спешит поделиться своим трудом — магистерской диссертацией, а точнее — её частью, посвящённой проблемам изоляции контейнеризированного [и запущенного в Kubernetes] приложения. В качестве «клиента», для которого была подготовлена эта исследовательская работа, выступает ни много ни мало полиция его родины.



Оркестровка контейнеров и облачные (cloud-native) вычисления стали очень популярными в последние годы. Их адаптация дошла до такого уровня, что интерес к ним проявляют даже финансовые предприятия, банки, госсектор. На фоне других компаний их выделяют обширные требования в области безопасности информации и ИТ.

Сообщество Linux занято сейчас устранением недавно обнаруженной уязвимости, которая касается средства для запуска контейнеров runC, используемого Docker, CRI-O, containerd и Kubernetes.

Уязвимость, получившая идентификационный номер CVE-2019-5736, даёт заражённому контейнеру возможность перезаписать исполняемый файл runC на хосте и получить к нему root-доступ. Это позволяет такому контейнеру получить контроль над хостом и даёт атакующему возможность выполнять любые команды.

На примере gitlab бота я покажу, каким образом можно автоматизировать процесс релиза для serverless функций через автоматическое их обновление из git репозитория. Переходим от игр к практической разработке на serverless.

Прим. перев.: Минувшей ночью Aleksa Sarai, старший инженер по контейнерам из SUSE Linux, сообщил в почтовой рассылке oss-sec о критической уязвимости в безопасности runc/LXC, которая позволяет злоумышленнику, имеющему доступ в изолированный контейнер, получить привилегии root на хостовой системе. Поскольку проблема выявлена в эталонной реализации исполняемой среды для контейнеров — runc, — она затрагивает многочисленные контейнерные системы включая Docker/Moby, Podman, cri-o (и собственно Kubernetes). Ниже представлены подробности в виде перевода сообщения инженера в почтовую рассылку.


Я являюсь одним из мейнтейнеров runc (нижележащей среды исполнения контейнеров, используемой в Docker, cri-o, containerd, Kubernetes и т.п.). Недавно стало известно об уязвимости, которую мы проверили и пропатчили.

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

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

В качестве источника я шел вслед за серией статей Mark Gituma, в которых описана аналогичная работа, но только с Minikube, а не с MicroK8s.

Все же есть одно требование, которое необходимо удовлетворить до начала работы. У Вас должен быть установлен Snap, что в свою очередь означает, что у Вас должен быть установлен Linux.

Скандальные, важные и просто очень крутые материалы выходят в СМИ не каждый день, да и со 100% точностью спрогнозировать успешность той или иной статьи не возьмётся ни один редактор. Максимум, чем располагает коллектив — на уровне чутья сказать, «крепкий» материал или же «обычный». Все. Дальше начинается непредсказуемая магия СМИ, благодаря которой статья может выйти в топы поисковой выдачи с десятками ссылок от других изданий или же материал канет в Лету. И вот как раз в случае публикации крутых статей сайты СМИ периодически падают под чудовищным наплывом пользователей, который мы с вами скромно называем «хабраэффектом».

Этим летом жертвой профессионализма собственных авторов стал сайт издания Republic: статьи на тему пенсионной реформы, о школьном образовании и правильном питании в общей сложности собрали аудиторию в несколько миллионов читателей. Публикация каждого упомянутого материала приводила к настолько высоким нагрузкам, что до падения сайта Republic оставалось совсем «вот столечко». Администрация осознала, что надо что-то менять: нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.

По итогам совместного со специалистами Republic обсуждения различных вариантов реализации озвученных хотелок мы решили перевести сайт издания на Kubernetes*. О том, чего нам всем это стоило, и будет наш сегодняшний рассказ.

*В ходе переезда ни один технический специалист Republic не пострадал

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

TL; DR

Поднимаем кластер для обслуживания веб-приложений без записи состояния (stateless web applications) вместе с ingress, letsencrypt, не используя средства автоматизации вроде kubespray, kubeadm и любых других.
Время на чтение: ~45-60 минут, на воспроизведение действий: от 3-х часов.

Преамбула

На написание статьи меня сподвигла потребность в своём собственном кластере kubernetes для экспериментов. Автоматические решения установки и настройки, которые есть в открытом доступе, не работали в моем случае, так как я использовал не-мейнстримовые дистрибутивы Linux. Плотная работа с kubernetes в IPONWEB стимулирует иметь такую площадку, решая свои задачи в комфортном ключе, в том числе и для домашних проектов.

Компоненты

В статье будут фигурировать следующие компоненты:

— Ваш любимый Linux — я использовал Gentoo (node-1: systemd / node-2: openrc), Ubuntu 18.04.1.
— Kubernetes Server — kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy.
— Containerd + CNI Plugins (0.7.4) — для организации контейнеризации возьмем containerd + CNI вместо docker (хотя изначально вся конфигурация была поднята на docker, так что ничего не помешает использовать его в случае необходимости).
— CoreDNS — для организации service discovery компонентов, работающих внутри kubernetes кластера. Рекомендована версия не ниже 1.2.5, так как с этой версии появляется вменяемая поддержка работы coredns в качестве процесса, запущенного вне кластера.
— Flannel — для организации сетевого стека, общения подов и контейнеров между собой.
— Ваша любимая db.

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


Мы используем Helm в своём арсенале инструментов непрерывного выката. На момент написания статьи в наших кластерах более тысячи приложений и примерно 4000 инсталляций этих приложений в различных вариациях. Периодически мы сталкиваемся с проблемами, но в целом довольны решением, не имеем простоев и потерь данных.

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