Kubernetes *

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

Сегодня, 18 сентября, выходит очередная версия Kubernetes — 1.16. Как всегда нас ждет много улучшений и новинок. Но я хотел бы обратить ваше внимание на разделы Action Required файла CHANGELOG-1.16.md. В этих разделах публикуются изменения, которые могут сломать работу вашего приложения, инструментов по обслуживанию кластера или требуют внесения изменений в файлы конфигурации.

В общем, требуют ручного вмешательства…

Сегодня, в среду, состоится очередной релиз Kubernetes — 1.16. По сложившейся для нашего блога традиции, вот уже в юбилейный — десятый — раз мы рассказываем о наиболее значимых изменениях в новой версии.

Информация, использованная для подготовки этого материала, взята из таблицы Kubernetes enhancements tracking, CHANGELOG-1.16 и соответствующих issues, pull requests, а также Kubernetes Enhancement Proposals (KEP). Итак, поехали!..

В настоящее время всё больше компаний переводят свою инфраструктуру с железных серверов и собственных виртуалок в облака. Такое решение легко объяснить: нет необходимости заботиться о железе, кластер легко конфигурируется множеством различных способов… а самое главное — имеющиеся технологии (вроде Kubernetes) позволяют просто масштабировать вычислительные мощности в зависимости от нагрузки.

Всегда важен и финансовый аспект. Инструмент, речь о котором пойдет в этой статье, призван способствовать сокращению бюджетов при использовании облачной инфраструктуры с 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-кластера.