Kubernetes *

17 сентября Acceleration Team Райффайзенбанка приглашает на свой первый открытый Meetup, который пройдет в офисе в Нагатино. Тренды в DevOps, построение конвейера, управление релизами продуктов и еще больше про DevOps!

Вопросы можно будет позадавать тут

Kubernetes становится де-факто стандартом для запуска stateless-приложений. В основном потому, что позволяет значительно сократить time-to-market для доставки новых фич. Запуск stateful-приложений — баз данных, stateful-микросервисов — все еще представляет собой сложную задачу, но необходимость выдерживать конкуренцию и поддерживать высокий темп доставки подталкивает компании к экспериментам в этой области и создает спрос на подобные решения.

Представляем вам наше решение для запуска stateful-кластеров Tarantool Cartridge: Tarantool Kubernetes Operator, за подробностями прошу под кат.

За годы существования Pinterest 300 миллионов пользователей сервиса создали более 200 миллиардов пинов на более чем 4 миллиардов досок. Чтобы обслуживать эту армию пользователей и обширную контент-базу, портал разработал тысячи сервисов, начиная от микросервисов, с которыми может справиться несколько CPU, и заканчивая гигантскими монолитами, которые крутятся на целом парке виртуальных машин. И вот наступил момент, когда взгляд компании упал на k8s. Чем же «кубик» глянулся «Пинтересту»? Об этом вы узнаете из нашего перевода свежей статьи из блога Pinterest engeneering.



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

В ходе поддержки этого зоопарка инструментов команда разработки сталкивается с рядом проблем:

Во времена, когда Kubernetes был ещё v1.0.0, существовали плагины для томов (volume plugins). Нужны они были для подключения к Kubernetes систем для хранения персистентных (постоянных) данных контейнеров. Количество их было невелико, а в числе первых — такие провайдеры хранилищ, как GCE PD, Ceph, AWS EBS и другие.

Поставлялись плагины вместе с Kubernetes, за что и получили своё название — in-tree. Однако многим существующего набора таких плагинов оказалось недостаточным. Умельцы добавляли простенькие плагины в ядро Kubernetes при помощи патчей, после чего собирали свой собственный Kubernetes и ставили его на свои серверы. Но со временем разработчики Kubernetes поняли, что рыбой проблему не решить. Людям нужна удочка. И в релизе Kubernetes v1.2.0 она появилась…

Прим. перев.: Если вы задаётесь вопросами безопасности в инфраструктуре, основанной на Kubernetes, этот замечательный обзор от компании Sysdig станет отличной отправной точкой для беглого знакомства с актуальными на сегодняшний день решениями. В него включены и комплексные системы от известных игроков рынка, и значительно более скромные утилиты, закрывающие ту или иную проблему. А в комментариях мы как всегда будем рады узнать о вашем опыте использования этих инструментов и увидеть ссылки на другие проекты.


Программные продукты для обеспечения безопасности Kubernetes… их так много, и у каждого свои цели, область применения и лицензии.

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

Здравствуйте уважаемые читатели Хабра!

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

Данный цикл будет состоять минимум из четырех статей:

1. В первой из них я расскажу, как на голое железо установить отказоустойчивый кластер kubernetes, как установить стандартный дашборд и настроить доступ к нему, как установить ingress контроллер.
2. Во второй статье я расскажу, как развернуть отказоустойчивый кластер Ceph и как начать использовать RBD тома в нашем кластере Kubernetes. Также немного затрону остальные виды стораджей (storages) и более подробно рассмотрю local-storage. Дополнительно расскажу, как на базе созданного кластера CEPH организовать отказоустойчивое хранилище S3
3. В третьей статье я расскажу, как в нашем кластере Kubernetes развернуть отказоустойчивый кластер MySql, а именно — Percona XtraDB Cluster on Kubernetes. И также опишу все проблемы с которыми мы столкнулись, когда решили перенести БД в kubernetes.
4. В четвертой статье я постараюсь собрать все вместе и рассказать, как задеплоить и запустить приложение, которое будет использовать БД и тома ceph. Расскажу, как настроить ingress контроллер для доступа к нашему приложению извне и сервис автоматического заказа сертификатов от Let's Encrypt. Еще — как автоматически поддерживать данные сертификаты в актуальном состоянии. Также немного затронем тему RBAC в контексте доступа до панели управления. Расскажу в двух словах про Helm и его установку.
   Если Вам интересна информация данных публикаций, то — добро пожаловать!

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

Это история в двух частях — о новом витке развития automotive. Эта «серия» посвящена собственной разработке EPAM – Aos Connected Vehicle Platform. Алекс Агизим, CTO, Automotive & Embedded Systems, объясняет, чем она отличается от традиционного облачного решения и как дает software-разработчикам доступ в автомобиль. Ознакомиться с первой частью можно здесь.



В первой части я рассказывал, как наши разработки XEN Hypervisor позволяют изолировать сервисную часть автомобильного ПО от safety required software. Это один из барьеров перед широким применением в индустрии. Впервые опенсорсный гипервизор станет полноценным конкурентом закрытым коммерческим решениям.

Но это только первая ступенька. Чтобы вывести автомобильные сервисы на новый уровень, нужно «пустить» в него сервис-компании и разработчиков, далеких от embedded и automotive. Для этого требуется следующий уровень абстракции. Чтобы разработчик пользующийся современными фреймворками в разработке программного обеспечения мог, не переучиваясь, дизайнить свои сервисы для автомобилей.

Возможно, после прочтения вы захотите сказать: «Зачем такие сложности? Я, к примеру, купил Android-планшет для автомобиля, настроил нужные сервисы и вполне счастлив». Это классический инженерный подход, очень поддерживаю. Но давайте посмотрим шире. Автомобильная индустрия с точки зрения software как раз таки давно застряла в классических подходах. Я расскажу, каким ее будущее видим мы и что для этого делаем. А в конце пройдемся по основным сложностям.

Итак.

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

В этом обзоре представлена краткая информация о некоторых инструментах, которые упрощают жизнь программисту, чей код крутится в pod’ax Kubernetes-кластера.

Прим. перев.: Тот восторг, что испытали наши тимлиды, увидев в блоге IBM Cloud этот материал — своеобразное «расширение» легендарного Twelve-Factor App, — говорит сам за себя. Поднятые автором вопросы не просто на слуху, а по-настоящему жизненны, т.е. актуальны в повседневной жизни. Их понимание полезно не только для DevOps-инженеров, но и разработчиков, создающих современные приложения, запускаемые в Kubernetes.

Известная методология «12 factor application» представляет собой свод четко определенных правил для разработки микросервисов. Они широко используются для запуска, масштабирования и деплоя приложений. В облачной платформе IBM Cloud Private мы следуем тем же 12 принципам при разработке контейнеризированных приложений. В статье «Kubernetes & 12-factor apps» обсуждается специфика применения этих 12 факторов (они поддерживаются моделью оркестровки контейнеров Kubernetes).

Размышляя о принципах разработки контейнеризированных микросервисов, работающих под контролем Kubernetes, мы пришли к следующему выводу: вышеуказанные 12 факторов совершенно справедливы, однако для организации production-среды крайне важны и другие, а в частности:

Привет, Хабр! Представляю вашему вниманию перевод статьи «Service mesh data plane vs control plane» автора Matt Klein.



В этот раз «захотелось и перевелось» описание обоих компонентов service mesh, data plane и control plane. Это описание мне показалось самым понятным и интересным, а главное подводящим к пониманию «А нужно ли оно вообще?».

Поскольку идея «Сервисной сети (Service mesh)» становится все более популярной в течение последних двух лет (Оригинальная статья от 10 октября 2017), а число участников в пространстве возросло, я увидел соразмерный рост путаницы среди всего технического сообщества в отношении того, как сравнивать и противопоставлять разные решения.

Эта статья продолжает наш недавний материал про миграцию RabbitMQ и посвящена MongoDB. Поскольку мы обслуживаем множество кластеров Kubernetes и MongoDB, пришли к естественной необходимости мигрировать данные из одной инсталляции в другую и делать это без простоя. Основные сценарии прежние: перенос MongoDB из виртуального/железного сервера в Kubernetes или же перенос MongoDB в рамках одного кластера Kubernetes (из одного пространства имён в другое).

Суть рассказа о самом популярном пакетном менеджере для Kubernetes можно было бы изобразить с помощью эмоджи:

• коробка — это Helm (это самое подходящее, что есть в последнем релизе Emoji);
• замок — безопасность;
• человечек — решение проблемы.

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

• Кратко, что такое Helm, если вы не знали или забыли. Какие проблемы он решает и где находится в экосистеме.
• Рассмотрим архитектуру Helm. Ни один разговор о безопасности и о том, как сделать инструмент или решение более безопасным, не может обойтись без понимания архитектуры компонента.
• Обсудим компоненты Helm.
• Самый животрепещущий вопрос — будущее — новая версия Helm 3. 

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

Приветствуем вас, Хабр!

В свое время мы первыми вывели на российский рынок тему Kafka и продолжаем следить за ее развитием. В частности, нам показалась интересной тема взаимодействия Kafka и Kubernetes. Обзорная (и довольно осторожная) статья на эту тему выходила в блоге компании Confluent еще в октябре прошлого года под авторством Гвен Шапиры. Сегодня же мы хотим обратить ваше внимание на более свежую, апрельскую статью Йоханна Гайгера (Johann Gyger), который, хотя и не обошелся без вопросительного знака в названии, рассматривает тему в более предметном ключе, сопровождая текст интересными ссылками. Простите нам пожалуйста вольный перевод «chaos monkey», если сможете!

Kubernetes (K8s) — это мощная платформа, которая за последние пять лет кардинально изменила методы работы с программным обеспечением. Она пользуется активным спросом, и поэтому некоторые компании стали предлагать Kubernetes-as-a-service. Cloud4Y предлагает познакомиться с наиболее интересными дистрибутивами K8s.

У платформы есть сильное open-source комьюнити, которое привносит в продукт множество инноваций. Отсюда происходят и некоторые из текущих недостатков: трудность в установке, сложность в настройке. Во многом Kubernetes похож на ядро Linux: он предоставляет среду для запуска программного обеспечения, но не предоставляет никаких инструментов для управления.

27 мая в главном зале конференции DevOpsConf 2019, проходящей в рамках фестиваля РИТ++ 2019, в рамках секции «Непрерывная поставка», прозвучал доклад «werf — наш инструмент для CI/CD в Kubernetes». В нём рассказывается о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая возможные пути решения, мы показываем, как это реализовано в Open Source-инструменте werf.

С момента выступления наша утилита (ранее известная как dapp) преодолела исторический рубеж в 1000 звёзд на GitHub — мы надеемся, что растущее сообщество её пользователей упростит жизнь многим DevOps-инженерам.



Итак, представляем видео с докладом (~47 минут, гораздо информативнее статьи) и основную выжимку из него в текстовом виде. Поехали!

Прим. перев.: Представляем вашему вниманию технические подробности о причинах недавнего простоя в работе облачного сервиса, обслуживаемого создателями Grafana. Это классический пример того, как новая и, казалось бы, исключительно полезная возможность, призванная улучшить качество инфраструктуры… может навредить, если не предусмотреть многочисленные нюансы её применения в реалиях production. Замечательно, когда появляются такие материалы, позволяющие учиться не только на своих ошибках. Подробности — в переводе этого текста от вице-президента по продукту из Grafana Labs.



В пятницу, 19 июля, сервис Hosted Prometheus в Grafana Cloud перестал функционировать примерно на 30 минут. Приношу извинения всем клиентам, пострадавшим от сбоя. Наша задача — предоставлять нужные инструменты для мониторинга, и мы понимаем, что их недоступность усложняет вашу жизнь. Мы крайне серьезно относимся к этому инциденту. В этой заметке объясняется, что произошло, как мы на это отреагировали и что делаем для того, чтобы подобное больше не повторялось.

Несмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!

Вводные

Для начала обозначу контекст:

• Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
• Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
• В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).

Прим. перев.: Dailymotion — один из крупнейших в мире сервисов хостинга видео и потому заметный пользователь Kubernetes. В этом материале системный архитектор David Donchez делится итогами создания production-платформы компании на базе K8s, которая начиналась с облачной инсталляции в GKE и закончилась как гибридное решение, что позволило добиться лучшего времени реакции и сэкономить на инфраструктурных затратах.

Принимая решение о перестройке основного API Dailymotion три года назад, мы хотели разработать более эффективный способ размещения приложений и облегчить процессы в разработке и production. Для этой цели мы решили использовать платформу оркестрации контейнеров и естественным образом выбрали Kubernetes.

Почему стоит создавать собственную платформу на базе Kubernetes?

Платформа Red Hat OpenShift Container Platform 4 позволяет поставить на поток создание хостов для развертывания контейнеров, в том числе в инфраструктуре поставщиков облачных сервисов, на платформах виртуализации или в bare-metal системах. Чтобы создать в полном смысле облачную платформу, нам пришлось взять под жесткий контроль все применяемые элементы и таким образом повысить надежность сложного процесса автоматизации.



Очевидным решением стало использование в качестве стандарта Red Hat Enterprise Linux CoreOS (разновидности Red Hat Enterprise Linux) и CRI-O, и вот почему…