Kubernetes *

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».

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

Администрировать их порой — сплошная головная боль. В этой статье мы расскажем об Istio — инструменте для service mesh (эту архитектуру мы рассматривали ранее), который выводит управление крупными облачными развертываниями на новый уровень.

Часть 1 Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian)

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

В прошлой публикации я рассказал, как развернуть отказоустойчивый кластер Kubernetes. Но дело в том, что в Kubernetes удобно деплоить stateless приложения, которым не требуется сохранять свое состояние или работать с данными. Но в большинстве случаев нам требуются сохранять данные и не терять их при рестартах подов.
Для этих целей в Kubernetes используются тома (volume). Когда мы работаем с облачными решениями Kubernetes, то проблем особо нет. Нам лишь нужно у Google, Amazon или иного облачного провайдера заказать требуемый объем и, руководствуясь документаций , подключить полученные тома к подам.
Когда же мы имеем дело с bare metal, тут дела обстоят немного сложнее. Сегодня я хочу рассказать об одном из решений основанном на использовании ceph.

В данной публикации я расскажу:

• как развернуть распределенное хранилище Ceph
• как использовать Ceph при работе с Kubernetes

Случилось то, чего мы (и не только мы) долго ждали: werf, наша Open Source-утилита для сборки приложений и их доставки в Kubernetes, теперь поддерживает применение изменений с помощью 3-way-merge-патчей! В дополнение к этому, появилась возможность adoption’а существующих K8s-ресурсов в Helm-релизы без пересоздания этих ресурсов.



Если совсем коротко, то ставим WERF_THREE_WAY_MERGE=enabled — получаем деплой «как в kubectl apply», совместимый с существующими инсталляциями на Helm 2 и даже немного больше.

Но давайте начнём с теории: что вообще такое 3-way-merge-патчи, как люди пришли к подходу с их генерацией и почему они важны в CI/CD-процессах с инфраструктурой на базе Kubernetes? А после этого — посмотрим, что же представляет собой 3-way-merge в werf, какие режимы используются по умолчанию и как этим управлять.

В 2009 году Патрик «крёстный отец DevOps» Дебуа вместе со словом DevOps запустил движение DevOpsDays, которое несет в себе истинный дух DevOps-а. Сегодня DevOpsDays — это международное движение, которое объединяет тысячи DevOps-специалистов по всему миру. В 2019 году прошло уже 90 (!) конференций DevOpsDays в разных странах.

7 декабря DevOpsDays пройдет в Москве. DevOpsDays Moscow — это комьюнити-конференция, которую организовывает DevOps-сообщество для того, чтобы участники сообщества встретились лично и обсудили то, что их волнует. Поэтому помимо докладов, мы уделим много времени камерным форматам и активностям, которые подталкивают к знакомствам и разговорам.

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

Конференцию делает DevOps-сообщество

Каждый DevOpsDays организовывает локальное комьюнити, заинтересованное в движухе, а не в заработке миллионов. Именно локальные сообщества сделали 90 конференций DevOpsDays по всему миру в 2019 году. А с момента первой конференции в Генте в 2009 году провели уже больше 300 конференций в разных городах.

В России DevOpsDays делает крутая команда. Наверняка многих из этих ребят вы знаете лично: Дмитрий Зайцев (flocktory.com), Александр Титов (Express 42), Артем Каличкин (Faktura.ru), Азат Хадиев (Mail.ru Cloud Solutions), Тимур Батыршин (Provectus), Валерия Пилия (Deutsche bank), Виталий Рыбников (Tinkoff.ru), Денис Иванов (talenttech.ru), Антон Струков (Яндекс), Сергей Малютин (Lifestreet media), Михаил Леонов (Kodix), Александр Акилин (Aquiva Labs), Виталий Хабаров (Express 42), Андрей Лёвкин (один из организаторов DevOps Moscow).

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

Как известно, учиться на чужом опыте дешевле, а посему — пусть эти истории помогут быть готовыми к возможным неожиданностям. Кстати, большая и регулярно обновляемая подборка ссылок на такие «failure stories» публикуется на этом сайте (по данным из этого Git-репозитория).

С базой данных Apache Cassandra и необходимостью её эксплуатации в рамках инфраструктуры на базе Kubernetes мы сталкиваемся регулярно. В этом материале поделимся своим видением необходимых шагов, критериев и существующих решений (включая обзор операторов) для миграции Cassandra в K8s.

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».

---

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

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

В нашем блоге мы много говорили об иностранных решениях для мониторинга и аудита, и вот пришло время для отечественной разработки. MONQ — зонтичная система с коннекторами для распространённых систем мониторинга, ресурсно-сервисными моделями, анализом данных, высоким потенциалом к AI и особенной моделью лицензирования. Нам выдали дистрибутив на посмотреть и мы решили поделиться как оно там под капотом и всё ли так нанотехнологично как говорит вендор (проект, всё-таки, резидент Сколково). Честь потестить выпала мне и я тут расскажу про установку, возможности системы и немного про лицензирование. Прошу под кат.

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



Каким же стал ответ? Как гласил заголовок на одном из информационных ресурсов, «Единорог [компания, оцениваемая в 1+ млрд USD] пал: Docker отказывается от enterprise». И вот что послужило поводом к такому заявлению…

Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.


Схема взята из другого обзора стратегий выката, сделанного в Container Solutions

Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.

Более короткие и частые развертывания имеют следующие преимущества:

• Сокращается время выхода на рынок.
• Новые функции быстрее попадают к пользователям.
• Отклики пользователей быстрее доходят до команды разработчиков. Это означает, что команда может дополнять функции и исправлять проблемы более оперативно.
• Повышается моральный дух разработчиков: с большим количеством функций в разработке интереснее работать.

Всем привет. Меня зовут Александр, я Java-разработчик в группе компаний Tinkoff.

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

В статье я расскажу про наш опыт перехода на сервис-ориентированную архитектуру, сопровождающуюся переездом в Kubernetes, и про решение сопутствующих проблем. Будет рассмотрен подход к организации системы распределенного кэширования In-Memory Data Grid (IMDG), его преимущества и недостатки, из-за которых мы решили написать собственное решение.

В статье рассматривается проект, бэкэнд которого написан на Java. Поэтому речь также пойдет про стандарты в области временного In-memory-кэширования. Обсудим спецификацию JSR-107, несостоявшуюся спецификацию JSR-347, а также особенности кэширования в Spring. Добро пожаловать под кат!

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



В Red Hat OpenShift Service Mesh мы выходим за рамки традиционной маршрутизации и предлагаем компоненты для трассировки и визуализации таких запросов, чтобы сделать взаимодействие сервисов более простым и надежным. Введение специального логического уровня управления, так называемой сервисной сетки service mesh, помогает упростить подключение, контроль и оперативное управление на уровне каждого отдельного приложения, развернутого на Red Hat OpenShift, ведущей Kubernetes-платформе корпоративного класса.

Полтора года назад, 5 марта 2018, компания Google выпустила первую альфа-версию своего Open Source-проекта для CI/CD под названием Skaffold, целью которого стало создание «простой и воспроизводимой разработки под Kubernetes», чтобы разработчики могли сфокусироваться именно на разработке, а не на администрировании. Чем может быть интересен Skaffold? Как оказалось, у него есть несколько козырей в рукаве, благодаря которым он может стать сильным инструментом для разработчика, а может — и инженера по эксплуатации. Познакомимся с проектом и его возможностями.

Кто сказал, что красивая девушка не сможет в IT? Да ещё и Kubernetes-штурвалом будет крутить так, что мужики позавидуют.

У нас в Southbridge всё возможно. Я уговорил сурового, но красивого админа Елизавету Михно рассказать, почему она променяла три чихуахуа к 40 годам, розовый «поршик», «лиапёрдовый» плащ, лабутены и борщ на k8s, Prometheus, Zabbix и карьеру SRE-инженера.

Привет!

7 декабря мы проводим третью конференцию DevOpsDays Moscow. Это не yet another конференция про DevOps. Это комьюнити-конференция, которую сообщество готовит для сообщества.

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

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

Билет стоит 7000 ₽, но есть лайфхак: если покупать два билета сразу, они станут по 6000 ₽.

Под катом все подробности.

Всем привет! Несколько месяцев назад мы запустили в продакшн наш новый open-source проект — Grafana-плагин для мониторинга kubernetes, который назвали DevOpsProdigy KubeGraf. Исходный код плагина доступен в публичном репозитории на GitHub. А в этой статье мы хотим поделиться с вами историей о том, как мы создавали плагин, какие инструменты использовали и с какими подводными камнями столкнулись в процессе разработки. Погнали!

Компания Rancher Labs, специализирующаяся на решениях и услугах для Kubernetes, объявила о передаче своего Open Source-хранилища для постоянных данных Longhorn в некоммерческую организацию CNCF, ответственную за развитие Kubernetes, Prometheus и ряда других проектов.

О проекте и его статусе

Longhorn был представлен в апреле 2017 года и называется распределённым блочным хранилищем для кластеров Kubernetes. Среди его главных особенностей — отказоустойчивость (нет единой точки отказа) и ориентированность на применение в enterprise, инкрементальные снапшоты, бэкапы на дополнительные хранилища (NFS или совместимые с S3), автоматизированные обновления без простоя в работе, простой в использовании GUI.

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

Руководителю важно, чтобы в отделе всё крутилось, вертелось, стабильно выдавало результат. А ещё KPI постоянно висят дамокловым мечом. Потому поиск новых технологий и курсов уходит на 5-10 место.

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

Кубернетес меняет жизнь компании. Это факт.

А давайте посмотрим с другой стороны. K8s меняет в первую очередь жизнь самого администратора. Даёт возможность заработать больше денег, избавляет от многих рутинных задач, делает свободнее и значимее как профессионала, Kubernetes делает работу интересней.

Нам стало интересно, как изменилась профессиональная и личная жизнь ребят, которые прошли базовые Слёрмы. Чтобы обосновать потраченное время, мы предложили скидку на Слёрм Мега — и попросили участников дать ответы на несколько коротких вопросов: что им понравилось в Слёрме, что не понравилось, что бы они хотели улучшить.

Управление ресурсами кластера всегда сложная тема. Как объяснить необходимость настройки ресурсов пода пользователю, который деплоит свои приложения в кластер? Может проще это автоматизировать?

Всем привет!

Так сложилось, что наша небольшая команда разработки, не сказать, чтобы недавно, и уж точно не внезапно, доросла до переноса некоторых (а в перспективе и всех) продуктов в Kubernetes.

Причин тому было множество, но наша история не про холивар.

Из инфраструктурной основы выбор у нас был небольшой. vCloud Director и vCloud Director. Выбрали версию поновее и решили начать.

В очередной раз полистав «The Hard Way», я очень быстро пришёл к выводу, что инструмент для автоматизации хотя бы базовых процессов, таких как деплой и сайзинг, нужен ещё вчера. Глубокое погружение в Google явило на свет такой продукт как VMware Container Service Extension (CSE) — опенсорсный продукт, позволяющий автоматизировать создание и сайзинг k8s кластеров для тех, кто в vCloud-е.