На прошлой неделе Kubernetes отметил своё 4-летие: первый коммит в его публичной кодовой базе состоялся 6 июня 2014 года. По этому случаю один из его основателей, Joe Beda, поделился в блоге проекта своими воспоминаниями о том, как всё начиналось.

Вчера компания Amazon Web Services объявила о полноценном запуске своего облачного сервиса на базе Kubernetes — EKS (Amazon Elastic Container Service for Kubernetes). Впервые он был анонсирован в ноябре прошлого года (вскоре после того, как AWS присоединилась к стоящему за Kubernetes фонду CNCF), но тогда он имел статус предварительного доступа. Что скрывается за EKS?

На днях — 13 мая 2018 года — нам как компании формально исполнилось 10 лет. На самом деле, мы начинали ещё раньше, но были слишком молоды для осознания того, что это уже самостоятельный бизнес… Как двум студентам без опыта в предпринимательстве и внешних инвестиций удалось что-то создать, а потом ещё и привести к настоящему успеху? Я постарался собрать в этой статье ключевые этапы нашего долгого пути.

Пройдя длинный путь системного администрирования Linux-серверов, в качестве базовых инструментов для сбора статистики и мониторинга мы успели попробовать разные варианты реализации. Самописные скрипты (и даже веб-приложения), Cacti, Zabbix — наиболее устоявшиеся у нас в то или иное время опции, на смену которым в последние годы пришли Okmeter и Prometheus. В этой статье мы собрали и объединили: а) впечатления Okmeter по сотрудничеству с нами, б) обратную связь от тимлидов и инженеров компании «Флант» по использованию Okmeter в многочисленных и разнообразных обслуживаемых нами проектов (от малых до крупных, от достаточно тривиальных инсталляций веб-хостинга до кластеров Kubernetes).

В конце марта у фонда CNCF, помогающего развивать Open Source-проекты для облачных (cloud native) приложений, случилось двойное пополнение: в «песочницу» были добавлены OPA (Open Policy Agent) и SPIFFE (Secure Production Identity Framework For Everyone), которых роднит тема безопасности. Для чего же они могут пригодится?

В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

На прошлой неделе авторы Open Source-проекта Jenkins представили своё новое детище, «расширяющее экосистему Jenkins» и предназначенное специально для непрерывной интеграции/доставки приложений в рамках кластеров Kubernetes. Решение получило название Jenkins X. Что же оно делает?

8 марта фонд CNCF, созданный при The Linux Foundation, представил значительно обновлённую версию своей «карты ранее неизведанной территории облачных (cloud native) технологий» — Cloud Native Landscape 2.0. Собранная в рамках этого проекта информация ориентирована на компании, которые только начинают свой путь в мир инфраструктуры для cloud native-приложений, и призвана познакомить их с множеством имеющихся решений с открытым исходным кодом и не только.

Развитие сложной ИТ-инфраструктуры китайской компании Huawei, насчитывающей более 180 тысяч сотрудников, привело к новым вызовам и требованиям, ответом на которые стало создание PaaS, основанной на Kubernetes и Docker. Внутреннее применение новой платформы не просто отлично зарекомендовало себя, но и продемонстрировало реальную заинтересованность извне — со стороны заказчиков Huawei. Так, используя Open Source-продукты и свой обширный enterprise-опыт, компания сумела закрыть внутренние потребности, предложить конкурентные услуги на рынке и помочь сообществу с разработкой важных проектов.

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

29 января технический комитет организации CNCF (Cloud Native Computing Foundation), стоящей за Kubernetes, Prometheus и другими Open Source-продуктами из мира контейнеров и cloud native, объявил о принятии проекта Rook в свои ряды. Отличный повод познакомиться поближе с этим «оркестровщиком систем распределённого хранения данных в Kubernetes».

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



В последние годы микросервисы стали очень популярной темой. «Микросервисное безумие» выглядит примерно так:

«Netflix хороши в DevOps. Netflix делают микросервисы. Таким образом, если я делаю микросервисы, я хорош в DevOps».

BlackRock — одна из крупнейших инвестиционных компаний мира и крупнейшая по размеру активов под управлением (5,7 трлн USD по состоянию на июль'17). Её также называют крупнейшим в мире «теневым банком». Имея 30-летнюю историю и такие впечатляющие показатели, компания не отстаёт от современных тенденций в ИТ-инфраструктуре. В минувшую пятницу в блоге организации CNCF появилась информация о том, что BlackRock удалось за 100 дней выкатить своё production-окружение на Kubernetes. Как они к этому пришли?

Прим. перев.: Автор статьи — Melvin Dave Vivas, возглавляющий команду разработчиков и SRE-инженеров в сингапурском банке, — делится своим опытом знакомства с поддержкой Kubernetes в платформе Docker.

Когда в октябре прошлого года на DockerCon 2017 технический директор Docker Inc Соломон Хайкс (Solomon Hykes) анонсировал родную поддержку Kubernetes, мне стало очень любопытно, как это будет работать.



Поэтому после анонса я решил проверить наличие этой поддержки в Edge-версии, о чём писал Michael Frills в блоге Docker. Но на тот момент её не оказалось. И вот, после нескольких месяцев ожиданий, она наконец-то появилась.

В конце декабря облачный провайдер DigitalOcean опубликовал результаты своего второго опроса Currents, собравшего данные от 2500+ разработчиков (и не только — подробнее см. ниже), преимущественно (на 89 %) использующих GNU/Linux в качестве серверной операционной системы. Интересная статистика была получена в вопросах, посвящённых непрерывной интеграции и доставки приложений (CI/CD):

Основанный в 2006 году BlaBlaCar считается крупнейшим в мире онлайн-сервисом поиска автомобильных попутчиков (ridesharing). Появившись во Франции, сервис прошёл активную экспансию в Европе, с 2014 года стал доступен в России и Украине, а позже добрался до стран Латинской Америки и Азии. Рост популярности онлайн-сервисов неизбежно связан с развитием стоящей за ними ИТ-инфраструктуры, и, как легко догадаться из названия статьи, сегодняшние потребности BlaBlaCar реализуются благодаря Kubernetes. К чему же пришли ИТ-инженеры компании?

Прим перев.: OpenFaaS — serverless-фреймворк, формально представленный в августе, но появившийся около года назад и быстро укрепившийся на самой вершине проектов GitHub по тегу Kubernetes. Опубликованный ниже текст — перевод технической части официального анонса проекта от его автора Alex Ellis, который хорошо известен в сообществе своим энтузиазмом в области Docker (имеет статус Docker Captain).


Functions as a Service или OpenFaaS — фреймворк для создания serverless-функций поверх контейнеров. Я начал проект как proof of concept в октябре прошлого года, когда хотел понять, можно ли запускать Alexa skills или функции AWS Lambda в Docker Swarm. Начальные успехи привели меня к публикации в декабре того же года первой версии кода на Golang в GitHub.

В эти дни (6-8 декабря) в США проходит местная версия конференций KubeCon + CloudNativeCon 2017, в фокусе внимания которой многочисленные проекты некоммерческой организации CNCF во главе с Kubernetes. Мероприятие собрало более 4100 посетителей, 77 % из которых используют K8s, причём в 75 % случаев речь идёт про production. Событие оказалось не только богатым на анонсы от различных стартапов и гигантов индустрии, но и стало поводом для подведения итогов Open Source-сообщества из мира cloud native — достаточно заметить, что в декабре сразу у четырёх проектов CNCF состоялся знаковый релиз 1.0. Так что новенького?

Все мы любим --help и man. Несмотря на появление многочисленных форумов, Stack Exchange и прочих ресурсов, хорошим тоном в начале решения своих проблем по-прежнему остаётся самостоятельный поиск ответа в официальной документации (и на этих ресурсах вам скорее всего об этом сразу напомнят). Однако лень продолжает двигать прогресс даже там, где не всегда того ожидаешь. Впрочем, это не только лень — бывают и другие аргументы в пользу «упрощений»…

В общем, оказалось, что классический man устраивает не всех. Поэтому появился проект tldr, который, следуя своей расшифровке «Too long; didn't read», решил принести в консоль лаконичную документацию, содержащую только самое главное. Проекту tldr уже больше 3 лет, но про него ещё почему-то не писали на хабре.

Прим. перев.: Это перевод статьи из блога компании New Relic, где на протяжении года публикуются подобные материалы о разных ИТ-специализациях, связанных с разработкой и эксплуатацией программного обеспечения. Автором является Kevin Casey — независимый журналист и обладатель премии Azbee Award, который пишет для различных изданий и компаний (включая Red Hat).



В недавней публикации мы рассмотрели восхождение Site Reliability Engineer в современных организациях, занимающихся программным обеспечением. Но называться SRE — одно дело, а нам же хотелось бы ещё узнать, что требуется для того, чтобы преуспеть в этой должности.