Сообщество 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 без категорических заключений, а также желание поделиться опытом и нашими решениями.

По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

Kubernetes — это просто. Почему же банки платят мне за работу в этой сфере большие деньги, в то время как любой может освоить эту технологию буквально за несколько часов?

В воскресенье закончился Слёрм-3: интенсив по Kubernetes.

Поставили личный рекорд: 132 участника, 65 в онлайне и 67 в зале.
На первом Слёрме было 50 человек, на втором 87. Растем потихоньку.

126 человек создали кластер (задание первого дня), а 115 выполнили практику до конца.
6 человек вообще проигнорировали практику. Будем считать, что им нужны были только лекции.

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

Привет, друзья. Недавно мы запустили свою серию митапов по Kubernetes в Mail.ru – @Kubernetes Meetup. Мы немного недооценили интерес к теме и получили несколько сотен заявок на участие в первом событии серии – больше, чем смогли подтвердить.

В честь 14 февраля мы решили устроить special edition-митап для всех, кто любит Kubernetes: соберемся бо́льшим кругом, начнем чуть раньше, расширим традиционную программу выступлений горячей дискуссией и интерактивом. Также мы подготовили для участников несколько особых сюрпризов.

Встреча пройдет 14 февраля (четверг) в 17:00 в московском офисе Mail.ru Group (Ленинградский проспект, д. 39, стр. 79).

На митапе Booking.com раскроет детали своего сетапа Kubernetes; крупнейший чешский хостинг WEDOS поделится своим опытом работы с K8S на Bare Metal, а Mail.ru Cloud Solutions расскажут, как сделать Kubernetes по-настоящему безопасным. В рамках дискуссии приглашенные спикеры обсудят, за чем будущее – за ванильным Kubernetes или дистрибутивом вендора?

Регистрация обязательна и закрывается 12 февраля в 23:59 (или раньше, если закончатся места).

Это вторая часть введения в Kubernetes для пользователей VMware. Прежде чем перейти к практической части, ознакомьтесь с предыдущей статьей по ссылке.

Краткое знакомство с kubernetes для разработчиков на примере разворачивания простого шаблонного сайта, с постановкой его на мониторинг, выполнением джобов по расписанию и health checks (все исходники прилагаются)

— Установка Kubernetes
— Установка UI
— Запуск своего приложения в кластере
— Добавление кастомных метрик в приложение
— Сбор метрик через Prometheus
— Отображение метрик в Grafana
— Выполнение задач по расписанию
— Отказоустойчивость
— Выводы
— Заметки
— Список литературы

Прим. перев.: Это уже не первая статья с общими рекомендациями по безопасности в Kubernetes, что мы переводим в своём блоге. Однако её актуальность — по меньшей мере, как напоминание о простых и важных вещах, на которые не стоит закрывать глаза из-за нехватки времени, — только подтверждается недавними событиями, упоминаемыми автором в начале материала. К слову, автором является Connor Gilbert — менеджер продуктов компании StackRox, предлагающей готовую платформу для обеспечения безопасности приложений, разворачиваемых в рамках Kubernetes-кластеров. Итак, вот что он советует читателям блога CNCF…

NB: Чтобы сделать статью более информативной, для некоторых из упоминаемых автором терминов/методов мы добавили ссылки на соответствующую документацию.



В прошлом месяце в Kubernetes, самой популярной в мире системе оркестровки контейнеров, обнаружили первую крупную уязвимость в безопасности, что ударило по экосистеме проекта. Уязвимость CVE-2018-1002105 даёт возможность злоумышленникам скомпрометировать кластеры через API-сервер Kubernetes, что позволяет исполнять вредоносный код для установки malware и т.п.

Представляю вашему вниманию туториал для генерации доступов к Kubernetes-кластеру с помощью Dex, dex-k8s-authenticator и GitHub.


Локальный мем из русскоязычного чата Kubernetes в Telegram

Чтобы собирать образы Docker в контейнере и при этом обойтись без Docker, можно использовать kaniko. Давайте узнаем, как запускать kaniko локально и в кластере Kubernetes.

Дальше будет многабукаф

Это вторая часть из моей серии постов “Kubernetes in the Enterprise”. Как я упоминал в моем последнем посте, очень важно при переходе к “Design and Implementation Guides” всем быть на одном уровне понимания Kubernetes (K8s).

Я не хочу здесь применять традиционный подход для объяснения архитектуры и технологий Kubernetes, а объясню все через сравнение с vSphere платформой, которая вам, как пользователям VMware, хорошо знакома. Это позволит вам преодолеть кажущуюся запутанность и тяжесть понимания Kubernetes. Я использовал этот подход внутри VMware для представления Kubernetes разным аудиториям слушателей, и он доказал, что отлично работает и помогает людям быстрее освоиться с ключевыми концепциями.

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

Гадания на кофейной гуще

В моей работе Kubernetes уже сыграл важную роль, а в будущем она станет ещё важнее. Но 2018 год подходит к концу, так что забудем о скромности и сделаем смелый прогноз:

Будущее Kubernetes — это виртуальные машины, а не контейнеры

По китайскому гороскопу 2018 год был годом собаки, но в технике это был год Kubernetes. Многие только сейчас узнают об этой революционной технологии, а IT-отделы повсеместно пытаются разработать «стратегию Kubernetes» [1]. Некоторые организации уже перевели на Kubernetes большие рабочие нагрузки.

[1] Если вы пытаетесь разработать стратегию Kubernetes, вы уже потерпели неудачу, но это тема для другой статьи.

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

1-3 февраля пройдёт Слёрм-3, интенсив по Kubernetes. Анонс и программа тут.

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

Я сам 2-3 раза в год прохожу платные курсы, всегда беру варианты с практикой, и очень редко доделываю ее до конца. Для меня ситуация выглядит, как если бы я заказал в ресторане килограммовый стейк: съел, сколько мог, остальное оставил на тарелке. Но в тех, кто едет на Слёрм, хотелось бы запихнуть всю порцию.

На первом Слёрме мы отнеслись к практике спокойно, мол, мы даем задания, а участники справляются как могут. И это привело бы к катастрофе, если бы в аудитории не нашлось инициативных и талантливых парней: «15 минут назад я писал в чат о проблеме, я ее уже решил сам и помог еще пятерым».

Поэтому на втором Слёрме кроме трех спикеров со студентами работал десяток саппортов: системных администраторов из команды Southbridge.