CNCF — созданная при фонде The Linux Foundation международная организация, занимающаяся развитием и продвижением Open Source технологий, которые используются для построения и функционирования инфраструктур, предназначенных для запуска облачных приложений. Но это вы, наверное, и так знаете. Зато, возможно, вы не знали, что CNCF «балуется» издательством книг. Более того, книг для детей. Более того, книг для детей про современные IT-технологии! Перед Новым годом нам попалась одна из них — «The Illustrated Children’s Guide to Kubernetes». И она оказалась такой милой, что даже самые суровые из наших коллег светлели взглядом, листая виртуальные странички.

«Ого, — подумали мы. — Это же так круто!» Конечно, круто: детская иллюстрированная книжка, где на примере историй смешных персонажей простыми словами объясняется, что такое Kubernetes. А ведь K8s — давным-давно уже вездесущее настоящее в мире IT… Вот мы и решили, что нашим детям пора бы знать, чем занимаются их родители. Решили — и перевели книгу на русский язык.

Привет! В четверг, 23 января, пройдёт наш первый митап про Apache Kafka. Будем говорить об интеграции, source коннекторах и запуске масштабируемых приложений в Kubernetes. С докладами выступят инженеры Booking.com, Confluent и Авито.

Встречаемся в 18:00. Регистрируйтесь сами и приглашайте коллег. Под катом — анонсы выступлений, ссылка на регистрацию и видеотрансляцию митапа.

werf — это GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. werf поддерживает сборку образов приложения с помощью Dockerfile или собственного встроенного сборщика (на основе синтаксиса YAML, с поддержкой Ansible и инкрементальной пересборки на базе Git). Для доставки приложения используется формат конфигурации, совместимый с Helm. Код приложения, конфигурация собираемых образов и конфигурация выката приложения хранятся в одном Git-репозитории.

Долгожданный стабильный релиз 1.0 — это законченная по функциям базовая версия утилиты (точный номер версии первого стабильного релиза — это 1.0.6). В базовой версии werf поддерживает полный цикл доставки приложения и его сопровождения. Это включает в себя сборку образов приложения, деплой в Kubernetes, очистку неиспользуемых образов.

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

Куб-на-кубе, метакластеры, соты, распределение ресурсов

Рис. 1. Экосистема Kubernetes в облаке Alibaba Cloud

С 2015 года Alibaba Cloud Container Service for Kubernetes (ACK) является одним из самых быстрорастущих облачных сервисов в Alibaba Cloud. Он обслуживает многочисленных клиентов, а также поддерживает внутреннюю инфраструктуру Alibaba и другие облачные сервисы компании.

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

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

Прим. перев.: Эта статья, ставшая хитом на Medium, — обзор ключевых (за 2010-2019 годы) изменений в мире языков программирования и связанной с ними экосистемы технологий (особое внимание уделяется Docker и Kubernetes). Её оригинальным автором является Cindy Sridharan, которая специализируется на инструментах для разработчиков и распределённых системах — в частности, она написала книгу «Distributed Systems Observability» — и достаточно популярна в интернет-пространстве среди IT-специалистов, особенно интересующихся темой cloud native.



2019-й подошел к концу, поэтому я хотела бы поделиться своими мыслями о некоторых наиболее важных технологических достижениях и инновациях прошедшего десятилетия. Кроме того, я попытаюсь немного заглянуть в будущее и обозначить основные проблемы и возможности предстоящего десятилетия.

Хочу сразу оговориться, что в этой статье я не охватываю изменения в таких областях, как наука о данных (data science), искусственный интеллект, frontend engineering и т.п., поскольку лично у меня отсутствует достаточный опыт в них.

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

В наступившем новом году мы планируем всерьез развивать темы контейнеров, Cloud-Native Java и Kubernetes. Логичным продолжением этих тем на русском языке будет рассказ о фреймворке Quarkus, уже рассмотренном в хорошей статье на Хабре. Сегодняшняя статья посвящена не столько устройству "субатомной сверхбыстрой Java", сколько тем перспективам, которые Quarkus привносит в Enterprise.

В мире IT, свободном от политики и условностей, от ограничений и догм, рано или поздно зародится Полдень XXII века.

Команда Слёрма поздравляет читателей Хабра и участников Слёрмов — от Базового и Мега до DevOps и SRE. Спасибо, что вы были с нами весь этот год. За ваши неожиданные вопросы на интенсивах. За вашу критику — потому что благодаря вам мы становимся лучше.

Спасибо Хабру и его читателям. За ваши комментарии — одобрительные, критические, ироничные.

IT, изучение мозга и космонавтика — это последние фронтиры нашего мира. И там собираются самые свободные, самые ищущие, самые сомневающиеся, самые безрассудные.

Стив Джобс: «Оставайтесь голодными. Оставайтесь безрассудными. Всем большое спасибо».

С Новым годом, друзья!

Прим. перев.: Представляем вниманию перевод статьи старшего инженера по безопасности приложений британской компании ASOS.com. С ней он начинает цикл публикаций, посвящённых повышению безопасности в Kubernetes благодаря использованию seccomp. Если введение понравится читателям, мы последуем за автором и продолжим с его будущими материалами по этой теме.



Эта статья — первая из серии публикаций о том, как создавать профили seccomp в духе SecDevOps, не прибегая к магии и колдовству. В первой части я расскажу об основах и внутренних деталях реализации seccomp в Kubernetes.

Экосистема Kubernetes предлагает достаточное разнообразие способов по обеспечению безопасности и изоляции контейнеров. Статья посвящена Secure Computing Mode, также известному как seccomp. Его суть состоит в фильтрации системных вызовов, доступных для выполнения контейнерами.

29 ноября прошла конференция @Kubernetes, организованная Mail.ru Cloud Solutions. Конференция выросла из митапов @Kubernetes — и стала четвёртым событием серии. Мы собрали в Mail.ru Group более 350 участников — чтобы обсудить самые актуальные проблемы с теми, кто вместе с нами делает экосистему Kubernetes в России.

Под катом видео докладов конференции — как Tinkoff.ru писали свой Infrastructure Provider BareMetal, как поднимали Kubernetes в эксплуатации Mail.ru Group, интерактив про загадки Helm с его RollingUpdate — и много другого интересного в выступлениях CarPrice, Eldorado.ru, «Росгосстрах», Brain4Net, — а также конкурс для будущих спикеров @Kubernetes.

Шёл 2019 год, а у нас всё ещё нет стандартного решения для агрегации логов в Kubernetes. В этой статье мы хотели бы, используя примеры из реальной практики, поделиться своими поисками, встречаемыми проблемами и их решениями.

Однако для начала оговорюсь, что разные заказчики под сбором логов понимают очень разное:

• кто-то хочет видеть security- и audit-логи;
• кто-то — централизованное логирование всей инфраструктуры;
• а кому-то достаточно собирать только логи приложения, исключив, например, балансировщики.

О том, как мы реализовывали различные «хотелки» и с какими трудностями столкнулись, — под катом.

Потестируйте Backyards на собственных кластерах: curl https://getbackyards.sh | sh && backyards install -a --run-demo. Если интересно, см. детали последнего релиза.

В июне мы представили Backyards, автоматизированную «сервисную сетку» (service mesh) поверх нашего оператора Istio. Она сильно упрощает управление service mesh в многооблачной и гибридной инфраструктуре. Backyards интегрирован в платформу управления контейнерами Pipeline на Banzai Cloud, но также доступен как отдельный продукт. Конечно, интеграция с Pipeline даёт множество конкретных преимуществ (как управление приложениями на нескольких облаках), но Backyards работает на любой установке Kubernetes.

Друзья, всем привет!

В прошедшие выходные состоялся долгожданный (а принятие PR шло больше месяца) релиз новой версии нашего плагина для мониторинга kubernetes-приложений DevOpsProdigy KubeGraf v1.2.0!
Вкратце: плагин предназначен для мониторинга приложений и node в k8s-кластере, с его помощью можно следить за потребляемыми ресурсами, количеством доступных реплик приложений, информацией о прохождении liveness/readyness проб, а также строить визуальную схему всех приложений, запущенных в кластере.

Подробно о плагине мы писали здесь, а сейчас хочу рассказать вам о его новых фишках.

Прим. перев.: Эта практическая заметка от создателя LayerCI — отличная иллюстрация так называемых tips & tricks для Kubernetes (и не только). Предлагаемое здесь решение — лишь одно из немногих и, пожалуй, не самое очевидное (для некоторых случаев может подойти уже упомянутый в комментариях «родной» для K8s kubectl port-forward). Однако оно позволяет как минимум посмотреть на проблему с позиции применения классических утилит и их дальнейшего комбинирования — одновременно простого, гибкого и мощного (см. «другие идеи» в конце для вдохновения).



Представьте типичную ситуацию: вы хотите, чтобы порт на локальном компьютере волшебным образом перенаправлял трафик в pod/контейнер (или наоборот).

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

Произвольные команды с Helm и werf

Приложение — это не только бизнес-логика и данные, но и набор произвольных команд, которые необходимо выполнить для успешного обновления. Это могут быть, например, миграции для баз данных, «ожидатели» готовности внешних ресурсов, какие-то перекодировщики или распаковщики, регистраторы во внешних Service Discovery — на разных проектах можно встретить разные задачи.

Что же предлагает Kubernetes для решения таких задач?

Расшифровка:
Азат Хадиев: Здравствуйте. Меня зовут Азат Хадиев. Я разработчик PaaS направления Mail.ru Cloud Solutions. Со мной здесь Павел Селиванов из компании Southbridge. Мы находится на конференции DevOpsDays. Он здесь выступит с докладом о том, что с Kubernetes можно построить DevOps, но скорее всего у вас ничего не получится. Почему такая мрачная тема?

7 декабря прошла третья конференция DevOpsDays Moscow, организованная московским DevOps-сообществом при поддержке Mail.ru Cloud Solutions. Кроме докладов ведущих практиков DevOps, участники могли посетить короткие мотивирующие Lightning Talks, воркшопы и пообщаться в опенспейсах.

Мы собрали важные инсайты с шести выступлений и провели интервью с несколькими спикерами, чтобы узнать о том, что осталось за рамками докладов.

Внутри:

1. Барух Садогурский, JFrog: «Пусть софт течет от вендора к пользователю, как жидкость»
   
2. Павел Селиванов, Southbridge: «У Dev и Ops одна общая задача — делать продукт, который работает»
   
3. Владимир Утратенко, X5 Retail Group: «DevOps в Enterprise — это разработка без боли и пожаров»
   
4. Сергей Пузырёв, Facebook: «Production Engineer заботится о сервисе в целом: чтобы и пользователям, и разработчикам было хорошо»
   
5. Михаил Чинков, AMBOSS: «По пути DevOps не может идти одно подразделение, по нему должна идти вся компания»
   
6. DevOps-энтузиасты Росбанка: «1000 дней, чтобы внедрить DevOps в кровавом энтерпрайзе»
   

Прим. перев.: service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык (более 2 лет назад мы предлагали вариант «сетка для сервисов» или «сервисная сетка», а чуть позже некоторые коллеги стали продвигать сочетание «сервисное сито»). Постоянные разговоры об этой технологии привели к ситуации, в которой слишком тесно переплелись маркетинговая и техническая составляющие. Этот замечательный материал от одного из авторов оригинального термина призван внести ясность для инженеров и не только.


Комикс от Sebastian Caceres

Введение

Если вы инженер-программист, работающий где-то в районе бэкенд-систем, термин «service mesh», вероятно, уже прочно закрепился в вашем сознании за последние пару лет. Благодаря странному стечению обстоятельств, это словосочетание захватывает отрасль все сильнее, а хайп и связанные с ним рекламные предложения нарастают словно снежный ком, летящий вниз по склону и не подающий никаких признаков замедления.

Service mesh зародилась в мутных, тенденциозных водах экосистемы cloud native. К сожалению, это означает, что значительная часть связанной с ней полемики варьируется от «низкокалорийной болтовни» до — если воспользоваться техническим термином — откровенной чуши. Но если отсеять весь шум, можно обнаружить, что у service mesh есть вполне реальная, определенная и важная функция.

В этой публикации я попытаюсь проделать именно это: представить честное, глубокое, ориентированное на инженеров руководство по сервисным сеткам. Я собираюсь ответить не только на вопрос: «Что это такое?», — но и «Зачем?», а также «Почему именно сейчас?». Наконец, попытаюсь обрисовать, почему (по моему мнению) конкретно эта технология вызвала такой сумасшедший ажиотаж, что само по себе интересная история.

Разработку можно сравнить с картиной, где художник — ведущий разработчик. Создание элегантного микросервисного приложения — с творениями лучших архитекторов — модернистов. А вот поставить процесс на поток и оставить возможность выбирать — искусство. В первой статье из серии мы хотим рассказать о том, как создавался и работает облачный сервис IBM Kubernetes service и IBM Managed OpenShift, а также рассказать, как вы можете бесплатно развернуть и протестировать свой кластер Kubernetes в облаке IBM.

9 декабря вышла очередная версия Kubernetes — 1.17. Ее девиз — «Стабильность», множество фич получили статус GA, некоторое количество устаревших фич было удалено…

И, как всегда, наш любимый раздел Action Required файла CHANGELOG-1.17.md требует к себе внимания.

Поработаем руками…