Kubernetes *

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



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

В отзывах о Слёрме Kubernetes звучала фраза: «Kubernetes оказался проще, чем я думал». Сейчас уже не звучит, мифа о сложности k8s больше нет. Он перешел в разряд инструментов easy to learn, hard to master.

Мы хотим повторить то же самое с SRE. Показать, что SRE проще и понятнее, чем кажется. Сдвинуть парадигму: дать людям посмотреть на проект глазами инженера SRE.

Как всегда на старте, в уравнении много неизвестных. И как всегда на старте, самое интересное достанется первым.

3-5 февраля мы проводим в Москве Слёрм SRE. Билет на трехдневный интенсив стоит 60 тысяч. Что же участник получит за свои деньги?

Когда я рассказываю друзьям и коллегам про SRE, я встречаю здоровый скептицизм:

• Впервые слышу про SRE, это какая-то алхимия.
• Внедрить SRE сложно, это для гигантов вроде Гугла.
• Это дорого и долго, не дадут времени, не выделят бюджет.
• То, что вы описываете, слишком хорошо, чтобы быть правдой.

Эти вопросы я хочу разобрать.

Ephemeral Containers Kubernetes интересная затея для дебага проблем в контейнерах которые кроме исполняемого бинаря не содержат в себе ничего.

Немного информации есть на сайте Kubernetes и несколько примеров можно найти на просторах.

UPDATE: добавили ссылки на презентации и фото!

Всем привет!

Скоро новый год, а с ним долгожданные праздники, снег, елка, дед мороз и прочие радости…
Вот и мы в преддверии праздников решили подвести некоторые итоги этого насыщенного событиями года и поговорить о реальном опыте построения масштабируемых систем на Kubernetes.
Планируем 4 выступления, от архитекторов с реальным опытом внедрения kubernetes.
Будет интересно!

Мероприятие пройдет в четверг, 12 декабря, в клиентском центре IBM (Москва-сити — Пресненская набережная, 10). Собираемся в 18:30, а начало выступлений в 19:00. Участие в митапе бесплатное, количество мест ограничено. Ждем всех, кому интересно узнать о реальном опыте использования Kubernetes в построении продуктивных систем!

Прим. перев.: Эта статья, написанная Galo Navarro, что занимает должность Principal Software Engineer в европейской компании Adevinta, — увлекательное и поучительное «расследование» в области эксплуатации инфраструктуры. Её оригинальное название было немного дополнено в переводе по причине, которую объясняет автор в самом начале.



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

Пару недель назад моя команда занималась миграцией одного микросервиса на основную платформу, включающую CI/CD, рабочую среду на основе Kubernetes, метрики и другие полезности. Переезд носил пробный характер: мы планировали взять его за основу и перенести еще примерно 150 сервисов в ближайшие месяцы. Все они отвечают за работу некоторых из крупнейших онлайн-площадок Испании (Infojobs, Fotocasa и др.).

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

Такой хайп у одних формирует лишние ожидания, а у других — ненужные опасения. SRE — это реализация идей DevOps, которая стирает грань между разработкой и эксплуатацией, и заполняет метриками пропасть между IT и бизнесом. Где-то нет ни этой грани, ни этой пропасти. А где-то именно SRE-практик не хватает для DevOps-трансформации.

12 декабря в 11:00 (Мск) на вебинаре «SRE — хайп или будущее?» Эдуард Медведев, CTO Tungsten Lab, SRE-инженер, один из спикеров Слёрма SRE, расскажет про применимость, базовые понятия и инструменты SRE, а затем опишет, что будет происходить на Слёрме SRE.

UPD: Запись тут, звук не очень, завтра опубликую расшифровку.

Мы уже рассказывали, как/почему нам нравится Rook: в заметной мере он упрощает работу с хранилищами в кластерах Kubernetes. Однако с этой простотой приходят и определённые сложности. Надеемся, новый материал поможет лучше разбираться в таких сложностях ещё до того, как они себя проявят.

А чтобы читать было интереснее, начнём с последствий гипотетической проблемы в кластере.

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

---

Это третья статья из серии публикаций, посвященных  Kubernetes и технологии service mesh (также известной как «сеть микросервисов» и «mesh-сеть микросервисов»). В предыдущей статье мы изучили основы работы с Istio и выяснили, как этот инструмент помогает настраивать и администрировать сложные облачные архитектуры. Так, с его помощью можно сконфигурировать mesh-сеть микросервисов и получить некоторые возможности централизации в распределенной микросервисной среде. Сегодня мы более подробно изучим функции Istio, чтобы по достоинству оценить преимущества технологии service mesh.

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

На вопросы ответили: Александр Титов (Express 42), Александр Чистяков (vdsina.ru), Валерия Пилия (Deutsche bank), Азат Хадиев (Mail.ru Cloud Solutions) и Владимир Утратенко (X5 Retail Group).

Лично я не люблю скидки. Большие скидки означают, что цена изначально была мощно заряжена.
Если есть резерв, лучше уменьшить цену. Первый Слёрм Мега стоил 75 тысяч, вторая Мега — 60, а третья стоит 50.

С другой стороны, мне нравится традиция Черной пятницы, пусть она и опошлена в России конским подъемом цен накануне.

Мы не можем скинуть цену на интенсивы (некуда), но можем нарушить принцип «единая цена на все формы обучения: зал, удаленка, онлайн».

29 ноября, ровно на сутки, Слёрм делает скидку 50% на все онлайн-курсы. Слёрм Kubernetes (Джуниор + База + Мега) можно купить за 32 500 рублей, а новый Слёрм Пром (Prometheus) за 7500 рублей. Не забывайте указывать промокод BF19.

Если прямо сейчас денег нет, или бюджет надо обсуждать с руководством, оставьте заявку, пока есть скидка, а по срокам оплаты договоримся.

Сфера DevOps развивается очень стремительно. Команда DevOpsDays Moscow составила список каналов и чатов для тех, кто интересуется DevOps и хочет оставаться в центре событий. Мы сами читаем эти каналы, а некоторыми даже руководим.

Все сообщества для удобства мы разделили на группы: общие, про инструменты, новостные и те, кого нет в телеграме. Надеемся, вам будет полезно.

Инструментов для мониторинга платформ виртуализации немало. Особенно на этом рынке сильны позиции вендорских решений — vRealize и SCOM относительно родственных платформ VMware и Hyper-V соответственно. Третья популярная платформа виртуализации OpenStack. Вендорского решения для мониторинга этой платформы нет, но есть сторонние решения. Из популярных — решения с открытым исходным кодом. В этой статье я расскажу о комплексном решении для мониторинга перечисленных выше платформ (и не только) — Quest Foglight. Под катом много картинок и мало текста.

В курсах Слёрм Kubernetes постепенно остается один Kubernetes. Смежные темы системно переходят в отдельные курсы.

Первыми были Docker, Ansible, Ceph. Двухчасовые лекции по ним сначала превратались в цикл вебинаров, а потом — в онлайн-курсы.

Пришел черед мониторинга. Тема «Мониторинг кластера» превратилась в онлайн-курс Слёрм Пром, целиком посвященный Prometheus. Как мы любим, с практикой на учебном стенде. Онлайн-курс — это записанные лекции, практические задания, стенд для выполнения практики, помощь саппортов. Прохождение Слёрма Пром занимает 12-16 часов.

Содержание курса:

1. Основы Prometheus
2. Exposition (Node exporter, Blackbox exporter, Custom exporter, Application library)
3. Prometheus (Service Discovery, Labels, PushGateway)
4. PromQL (Хранение данных, типы данных, выражения, Record Rules)
5. Alerting (Alertrules, Alertmanager)
6. Визуализация данных (Grafana)
7. Продвинутое использование Prometheus (High Availability, Federation, Remote read/write, Thanos, HTTP API)
8. Prometheus в Kubernetes

Курс стоит 15 000 ₽ (10 000 ₽ для тех, кто был на Слёрмах).

Пример лекции.

Автор курса — Владимир Гурьянов, специалист по мониторингу и спикер Слёрма. Я взял у него интервью про курс, жизнь и работу в нашей компании. Мне интересны люди, которые направляют свой корабль в моря, обозначенные на картах «Здесь живут драконы».

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе 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».

---

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

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