Kubernetes *

Привет!

26 июня (среда) в 18.00 мы проведем митап под названием QIWI JS DETOX. Проходить он будет в Loft #2 (недалеко от м. Автозаводская)



Поговорим о Kubernetes и многом другом.

И снова здравствуйте! Перевод следующей статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes», который запускается уже в этом месяце Начнем.



В последние дни некоторые из моих подов постоянно аварийно завершали работу, оставляя в системном журнале ОС запись о том, что OOM Killer уничтожил процесс контейнера. Я решил разобраться, почему это происходит.

<TL;DR>

1. Слёрм действительно позволяет войти в тему Kubernetes или подтянуть свои знания.
2. Участники довольны. Тех, кто ничего нового не узнал или не решил свои задачи, считанные единицы. Безусловным манибеком первого дня («Если вы чувствуете, что Слёрм вам не подходит, мы вернем полную цену билета») воспользовался всего один человек, обосновав тем, что переоценил свои силы.
3. Следующий Слёрм пройдет в начале сентября в Питере. Selectel, наш бессменный спонсор, предоставляет не только облако для стендов, но и свой конференц-зал.
4. Мы повторяем базовый Слёрм (9-11 сентября) и представляем новую программу: Слёрм DevOps (4-6 сентября).

Привет, Хабр!

Напоследок перед летними каникулами решили порадовать уважаемых подписчиков серией митапов! На следующей неделе их будет целых три! И не только в Москве…

• 19 июня в 18:00 (Москва) в офисе IBM митап по Java технологиям. У нас будет Java Champion, Себастиан Дашнер. Будем обсуждать использование Java в новых облачных реалиях.
• 20 июня в 18:00 (Москва) в офисе IBM митап по Service Mesh — Istio. Давно хотели сделать и тут к нам приезжают основные контрибьюторы проекта. К примеру, Вадим Айзенберг входит в топ-5 людей — контрибьюторов Istio.
• 20 июня в 18:00 (Санкт-Петербург) — Себастиан Дашнер выступит совместно с Денисом Цыплаковым на площадке DataArt по темам Java и микросервисных архитектур

Для детальной программы и регистрации (количество мест, к сожалению, ограничено!) — смотрите далее!

Вслед за shell-operator мы представляем его старшего брата — addon-operator. Это Open Source-проект, который используется для установки в кластер Kubernetes системных компонентов, которые можно назвать общим словом — дополнения.

Доброе утро всем!

Сегодня мы рады предложить вам перевод статьи, кратко рассказывающей о новом технологическом веянии под названием «Service mesh» (сервисная сеть). Наиболее интересным решением в этой сфере (на наш взгляд) является Istio, но предлагаемая статья интересна, в первую очередь, экспресс-сравнением имеющихся технологий такого рода и high-level обзором всей парадигмы. Автор Тобиас Кунце также написал вторую, более практически-ориентированную статью о service mesh — просьба высказаться, стоит ли опубликовать и ее перевод

В этом году Plesk решил отправить нескольких людей на KubeCon — главное событие по Kubernetes в мире. Профильных конференций в России на эту тему нет. Конечно, о K8s у нас говорят, и все его хотят, но столько практикующих его компаний в одном месте больше не собирается нигде. Я оказался одним из участников, так как работаю над платформой, основанной на Kubernetes.

Прим. перев.: Оригинал этого текста написал Rob Scott — ведущий SRE-инженер компании ReactiveOps, которая и стоит за разработкой анонсируемого проекта. Нам очень близка идея централизованной валидации того, что деплоится в Kubernetes, поэтому мы с интересом следим за подобными инициативами.



Рад представить Polaris — проект с открытым исходным кодом, который помогает поддерживать «здоровье» кластера Kubernetes. Мы создали Polaris для автоматизации некоторых из лучших практик, используемых в ReactiveOps для поддержания безопасной и надежной работы кластеров у большого числа клиентов. Пришло время открыть исходный код.

На прошлой неделе, 19—23 мая, в Барселоне проходила главная европейская конференция по Kubernetes и связанным технологиям, одно из крупнейших Open Source-событий в мире — KubeCon + CloudNativeCon Europe 2019. Мы впервые приняли участие в ней, став серебряным спонсором мероприятия и первой российской компанией на KubeCon со своим стендом. На него была отправлена делегация из шести сотрудников «Фланта», и вот что мы увидели…

Прим. перев.: 16 мая этого года — значимая веха в развитии менеджера пакетов для Kubernetes — Helm. В этот день был представлен первый альфа-релиз будущей крупной версии проекта — 3.0. Её выход принесёт в Helm существенные и долгожданные изменения, на которые многие в Kubernetes-сообществе возлагают большие надежды. К таковым относимся и мы сами, поскольку активно используем Helm для деплоя приложений: мы интегрировали его в свой инструмент для реализации CI/CD werf и от случая к случая вносим посильный вклад в развитие upstream. Этот перевод объединяет 7 заметок из официального блога Helm, что приурочены к первому альфа-релизу Helm 3 и рассказывают об истории проекта и основных фичах Helm 3. Их автор — Matt «bacongobbler» Fisher, сотрудник Microsoft и один из ключевых мейнтейнеров Helm.

Как-то так исторически сложилось, что IT-индустрия по любому поводу разбивается на два условных лагеря: которые «за» и которые «против». Причем предмет споров может быть абсолютно произвольным. Какая ОС лучше: Win или Linux? На смартфоне Android или iOS? Хранить все в облаках или заливать на холодные RAID-хранилища и класть винты в сейф? Имеют ли PHP-шники право называться программистами? Эти споры носят, временами, исключительно экзистенциальный характер и не имеют под собой никакой прочей, кроме спортивного интереса, базы.

Так уж получилось, что с появлением контейнеров и всей этой любимой нами кухни с докером и условным k8s начались и споры «за» и «против» использования новых возможностей в различных сферах бэкэнда. (Заранее оговоримся, что хотя чаще всего в данном рассуждении в качестве оркестратора будет указываться Kubernetes, принципиального значения выбор именно этого инструмента не имеет. Вместо него можно подставить любой другой, какой вам кажется наиболее удобным и привычным.)

И, казалось бы, был бы это простой спор о двух сторонах одной медали. Такой же бессмысленный и беспощадный, как извечное противостояние Win vs Linux, в котором адекватные люди вполне себе существуют где-то посередине. Вот только в случае контейнеризации не все так просто. Обычно в таких спорах не бывает правой стороны, но в случае «применять» или «не применять» контейнеры для хранения БД все становится с ног на голову. Потому что в определённом смысле правы и сторонники и противники подобного подхода.

В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.



Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

Kubernetes Dashboard — простой в работе инструмент для получения актуальных сведений о работающем кластере и минимального управления им. Начинаешь его ценить ещё больше, когда доступ к этим возможностям нужен не только администраторам/DevOps-инженерам, но и тем, кто меньше привык к консоли и/или не намерен разбираться со всеми тонкостями взаимодействия с kubectl и другими утилитами. Так случилось и у нас: разработчикам захотелось быстрого доступа к веб-интерфейсу Kubernetes, а поскольку мы используем GitLab, решение напросилось само собой.

В интернете куча статей о сервис-мешах (service mesh), и вот ещё одна. Ура! Но зачем? Затем, что я хочу изложить своё мнение, что лучше бы сервис-меши появились 10 лет назад, до появления контейнерных платформ, таких как Docker и Kubernetes. Я не утверждаю, что моя точка зрения лучше или хуже других, но поскольку сервис-меши — довольно сложные животные, множественность точек зрения поможет лучше их понять.

Я расскажу о платформе dotCloud, которая была построена на более чем сотне микросервисах и поддерживала тысячи приложений в контейнерах. Я объясню проблемы, с которыми мы столкнулись при её разработке и запуске, и как сервис-меши могли бы помочь (или не могли).

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

О себе: Опыт администрирования ceph с версии hammer, основатель комьюнити t.me/ceph_ru в телеграм.

Дабы не быть голословным я буду ссылаться на принятые хабром (судя по рейтингу) посты о проблемах с ceph. С бОльшей частью проблем в этих постах я тоже столкнулся. Ссылки на использованный материал в конце поста.

В посте про Rook мы упоминаем ceph не просто так — Rook по сути ceph завернутый в kubernetes, а значит наследует все его проблемы. С проблем ceph и начнем.

Меня зовут Сергей, я из компании ITSumma, и я хочу вам рассказать, как мы подходим к резервированию в Kubernetes. В последнее время я много занимаюсь консультативной работой по внедрению разнообразных devops-решений для различных команд, и, в частности, плотно работаю по проектам с использованием K8s. На конференции Uptime day 4, которая была посвящена резервированию в сложных архитектурах, я выступал с докладом о резервировании «кубика», и вот его вольный пересказ. Только заранее предупрежу, что он является не непосредственным руководством к действию, а скорее, обобщением размышлений на указанную тему.



В принципе мониторинг и резервирование — это два основных инструмента повышения отказоустойчивости любого проекта. Но ведь в кубере всё балансируется само, скажете вы, всё масштабируется само, и если что-то произойдёт — поднимется само… То есть, при первом поверхностном исследовании темы, на вопрос, кто как подходит к резервированию K8s, интернет ответил мне «а зачем?» Многие думают, что кубер представляет собой такую магическую штуку, которая избавляет от всех инфраструктурных проблем и делает так, что проект никогда не упадет. Но… мир не то, чем кажется.

В начале этого месяца, 3 мая, был анонсирован крупный релиз «системы управления для распределённых хранилищ данных в Kubernetes» — Rook 1.0.0. Более года назад мы уже публиковали общий обзор Rook. Тогда же нас просили рассказать об опыте его использования на практике — и вот, как раз к столь значимой вехе в истории проекта, мы рады поделиться накопленными впечатлениями.

Если кратко, Rook представляет собой набор операторов для Kubernetes, которые полностью берут под контроль развертывание, управление, автоматическое восстановление таких решений для хранения данных, как Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Через 2 недели стартуют интенсивы по Kubernetes: Слёрм-4 для тех, кто знакомится с k8s и МегаСлёрм для инженеров и архитекторов k8s.

На Слёрм-4 остались последние 10 мест в зале. Желающих освоить k8s на базовом уровне хватает.

Для Ops, который знакомится с Kubernetes, запустить кластер и задеплоить приложение – уже неплохой результат. У Dev запросы и того меньше: понять, как оптимизировать приложение под работу в кластере.

У инженеров и архитекторов задачи другого уровня:

• можно ли запустить базу данных в k8s, нужно ли это делать, что мы выигрываем и проигрываем от такой архитектуры;
• какие подходы к деплою очевидно не подходят для k8s;
• какие угрозы безопасности несет k8s (например, разработчик легко может получить админский доступ) и как их предотвратить;
• какие схемы автоматизации инфраструктуры допускает k8s и как научиться их находить и использовать.

Если вы уже дошли до такого уровня, на МегаСлёрме вас ждет много интересного.

Добрый день.

Практически сразу после установки и конфигурации CI/CD по инструкции из предыдущего поста у команды возник вопрос как правильно осуществлять интеграционное тестирование. У нас уже был опыт запуска тестовых зависимостей в docker контейнерах, но это стало проблематичным так как теперь сама сборка была запущена в контейнере. В этой заметке я бы хотел описать два возможных способа интеграционного тестирования внутри контейнера, которые подошли моей команде.

Прим. перев.: Сотрудники всемирно известного сервиса Tinder недавно поделились некоторыми техническими деталями миграции своей инфраструктуры на Kubernetes. Процесс занял почти два года и вылился в запуск на K8s весьма масштабной платформы, состоящей из 200 сервисов, размещённых на 48 тысячах контейнеров. С какими интересными сложностями столкнулись инженеры Tinder и к каким результатам пришли — читайте в этом переводе.