Kubernetes *

Компания «УРУС» попробовала Kubernetes в разных видах: самостоятельный деплоймент на bare metal, в Google Cloud, а затем перенесла свою платформу в облако Mail.ru Cloud Solutions (MCS). Как выбирали нового облачного провайдера и как удалось мигрировать к нему за рекордные два часа рассказывает Игорь Шишкин (t3ran), старший системный администратор «УРУС».

Прим. перев.: Эта заметка была написана исследователем ИТ-безопасности из компании Aqua Security, специализирующейся на DevSecOps. Она является прекрасной иллюстрацией тех тонкостей в конфигурации Kubernetes, что важно всегда держать в голове, обслуживая кластеры в production. Конечно, если вы думаете про их безопасность…



Kubernetes состоит из множества компонентов, и иногда их комбинирование определенным образом приводит к неожиданным результатам. В этой статье я покажу, как pod, запущенный с привилегиями root'а и примонтированной директорией /var/log узла, может раскрыть содержимое всей файловой системы хоста пользователю с доступом к его логам. Мы также обсудим варианты решения этой проблемы.

Сегодня свершился релиз нового и очень полезного опенсорсного проекта, созданного дирекцией разработки ITSumma — плагина в Grafana для мониторинга Kubernetes. Он включён в официальный графана-стор — grafana.com/grafana/plugins/devopsprodigy-kubegraf-app

Наступил третий и последний день первого, но не последнего Слёрма DevOps.

Мы не рассчитывали, что сможем повторить Слёрм DevOps. Но неожиданно для нас все спикеры согласились приехать на Слёрм в феврале, а фидбек показал, как именно доработать программу. Есть понимание, как сделать программу интенсива более целостной и детальной, а некоторые темы — более практичными. Так что в феврале мы собираемся провести Слёрм DevOps в Москве. Подробности будут ближе к декабрю. Анонс обязательно появится на Хабре.

За окном классическая позитивная осенняя питерская погода, в конференц-зале Selectel тепло, кофе, кока-кола и почти лето. В окружающем мире 5 сентября 2019 года, у нас второй день от начала Слёрма DevOps.

В первый день интенсива мы прошли наиболее простые темы: Git, CI/CD. На второй день мы приготовили участникам Infrastructure as Code и тестирование инфраструктуры — темы многогранные, с большим количеством нюансов и практических заданий.

Если в ответ на команду kubectl get pod вы получаете:

Unable to connect to the server: x509: certificate has expired or is not yet valid

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

4 сентября в Санкт-Петербурге начался Слёрм DevOps.

В одном месте и в одном времени собрались все необходимые факторы для увлекательного интенсива длительностью в три дня: удобный конференц-зал Selectel, семь десятков любопытных разработчиков в зале и 32 участника в онлайне, сервера Selectel для практики. И зелёный динозавр, притаившийся в углу.

В первый день Слёрма перед участниками выступили три спикера.

Павел Селиванов, архитектор решений в Southbridge, занимается администрированием более 10 лет, является Certified Kubernetes Administrator. Постоянный спикер Слёрма. Делал доклады на конференциях Moscow Kubernetes Meetup и UWDC. Обладает богатым опытом внедрения Kubernetes: 5 проектов — индивидуальная работа, 20+ проектов в составе команды.

Артём Галонский, СТО «БюроБюро», специально прибыл на Слёрм DevOps из Калининграда. Опыт в коммерческой разработке более 12 лет. Выступал в роли тимлида\руководителя отдела разработки с 2011 года. Техническим директором стал в 2016 году. Считает, что devops-инженер — это что-то вроде единорога. Не в том смысле, что поймать его может только девственница. А в том, что никто не знает, что это такое на самом деле.

Алексей Степаненко, инженер отдела облачной платформы Selectel, занимается инфраструктурными задачами по обслуживанию облака OpenStack: мониторинг, CI/CD и управление конфигурациями.

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