Kubernetes *

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

Эта лекция в рамках «Вечерней школы Слёрма по Кубернетес». Вы можете просмотреть открытые теоретические лекции Вечерней Школы на Youtube, сгруппированные в плейлист. Для тех же, кому удобнее текст, а не видео, мы подготовили эту статью.

Зовут меня Павел Селиванов, на текущий момент я являюсь ведущим DevOps инженером компании Mail.ru Cloud Solutions, мы делаем «облака», мы делаем мэнедж-кубернетисы и так далее. В мои задачи сейчас как раз-таки входит помощь в разработке, раскатывание эти облаков, раскатывание приложения, которые мы пишем и непосредственно разработка инструментария, который мы предоставляем для наших пользователей.

Доброго времени суток, читатель!

Вот мы и подошли к заключительной части цикла статей о Канареечных релизах в Kubernetes и методах их реализации. Желаю приятного чтения и надеюсь, что данный цикл был для вас полезным.

---

Использование решения Jenkins X для выполнения Canary деплоя в кластере Kubernetes

---

В этом цикле:

1. Canary Deployment через GitlabCI + GitOps/Manual Approach
2. Canary Deployment через Argo Rollouts
3. Canary Deployment с Istio
4. (эта статья)

Что мы будем делать здесь?

Мы создадим Jenkins X k8s кластер и тестовое приложение на Python шаг за шагом. Вы можете повторять по примеру, либо просто читать, смотреть иллюстрации и результаты для получения представления о взаимодействии JenkinsX+Flagger+Istio сanary deployment и решить для себя, стоит ли эта связка более глубокого изучения.

Прим. перев.: это перевод статьи, подготовленной по мотивам недавнего выступления Richard Hartmann — заметного представителя команды разработчиков Prometheus, директора по сообществам из Grafana Labs, основателя проекта OpenMetrics и председателя группы SIG Observability в CNCF. Автор подводит итоги последнего года в жизни Open Source-проекта (и сообщества) Prometheus, а также рассказывает об основных трудностях и ближайших перспективах.



Во время PromCon Online 2020 я выступил с докладом под названием «Будущее Prometheus и его экосистемы». И хочу поделиться с вами его ключевыми моментами.

Использование Istio+Kiali для запуска и визуализации Canary деплоя

---

Статьи этого цикла

1. Canary Deployment в Kubernetes #1: Gitlab CI
2. Canary Deployment в Kubernetes #2: Argo Rollouts
3. (эта статья)
4. Canary Deployment с Jenkins-X, Istio и Flagger

Внутри компании мы активно делимся между собой полученными знаниями: не только в виде формальных wiki-инструкций, но и сообщениями в Slack (а чтобы ничего не терялось, предусмотрена умная система поиска, но это уже отдельная история…). У нас накопилось уже большое количество разнообразных заготовок для консольных операций в Kubernetes с kubectl. Про них и пойдет речь в этой статье.



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

Перевод статьи подготовлен в преддверии старта курса «DevOps практики и инструменты».

---

Если вы это читаете, вероятно, вы что-то слышали о Kubernetes (а если нет, то как вы здесь оказались?) Но что же на самом деле представляет собой Kubernetes? Это “Оркестрация контейнеров промышленного уровня”? Или «Cloud-Native Operating System»? Что вообще это значит?

Честно говоря, я не уверен на 100%. Но думаю интересно покопаться во внутренностях и посмотреть, что на самом деле происходит в Kubernetes под его многими слоями абстракций. Так что ради интереса, давайте посмотрим, как на самом деле выглядит минимальный “кластер Kubernetes”. (Это будет намного проще, чем Kubernetes The Hard Way.)

Я полагаю, что у вас есть базовые знания Kubernetes, Linux и контейнеров. Все, о чем мы здесь будем говорить предназначено только для исследования/изучения, не запускайте ничего из этого в продакшене!

TL;DR: обзорная статья-руководство по сравнению сред для запуска приложений в контейнерах. Будут рассмотрены возможности Docker и других схожих систем.

Мы будем использовать k8s-нативный контроллер развертывания Argo Rollouts и GitlabCI для запуска Canary деплоя в Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статьи этого цикла

1. Canary Deployment в Kubernetes #1: Gitlab CI
2. (Эта статья)
3. Canary Deployment using Istio
4. Canary Deployment с Jenkins-X, Istio и Flagger

Прим. перев.: автор это статьи (Luc Perkins) — developer advocate в организации CNCF, являющейся домом для таких Open Source-проектов, как Linkerd, SMI (Service Mesh Interface) и Kuma (кстати, вы тоже задумывались, почему в этом списке нет Istio?..). В очередной раз пытаясь принести в DevOps-сообщество лучшее понимание в модный хайп под названием «service mesh», он приводит 16 характерных возможностей, которые предоставляют подобные решения.

Сегодня service mesh ― одна из самых горячих тем в области программной инженерии (и по праву!). Я считаю эту технологию невероятно перспективной и мечтаю стать свидетелем ее широкого распространения (конечно, когда это имеет смысл). Тем не менее, она до сих пор окружена ореолом таинственности для большинства людей. При этом даже те, кто хорошо знаком с ней, нередко затрудняются сформулировать ее плюсы и что именно она собой представляет (включая и вашего покорного слугу). В статье я попытаюсь исправить ситуацию, перечислив различные сценарии использования «сервисных сеток»*.

Мы будем использовать Gitlab CI и ручной GitOps для внедрения и использования Canary-деплоя в Kubernetes

---

Статьи из этого цикла:

1. (эта статья)
2. Canary Deployment при помощи ArgoCI
3. Canary Deployment при помощи Istio
4. Canary Deployment с Jenkins-X, Istio и Flagger

Выполнять Canary-деплой мы будем руками через GitOps и создание/изменение основных ресурсов Kubernetes. Эта статья предназначена в первую очередь для знакомства с тем, как работает в Kubernetes Canary деплой, так как есть более эффективные способы автоматизации, которые мы рассмотрим в следующих статьях.

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

А ещё кофебрейки с единомышленниками, бодрая и драйвовая атмосфера, обмен опытом, самые неожиданные вопросы спикерам. И ответы, и информация, которую не встретишь в мануалах, а только на практике.

Как думаете, сколько ушло времени, сил и нервов, чтобы оно выглядело именно так?

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

Откуда берется спрос на платформенных инженеров?

В последнее время все больше компаний осознают необходимость в создании внутренней инфраструктурной платформы, которая была бы единой средой для разработки, подготовки релизов, выпуска и эксплуатации цифровых продуктов компании. Такая платформа содержит в себе системы и сервисы для управления вычислительными и сетевыми ресурсами, систему непрерывной интеграции, хранилище артефактов поставки, системы мониторинга и прочих сервисов, которые используют ваши команды разработки. Движение в сторону построения внутренних платформ и формирования платформенных команд началось несколько лет назад. Подтверждения тому можно найти в отчетах State of DevOps от организации DORA, публикациях от Gartner и книгах, вроде Team Topologies.

Если вы применяли в работе предыдущие выпуски Kubernetes — тот же 1.16 — вы, возможно, видели странное предупреждение от kubectl run.

До недавнего времени этой командой можно было сгенерировать объекты для развертывания или YAML из командной строки. Начиная с Kubernetes 1.18 такая возможность была сломана весьма удивительным образом. В статье будут ответы на вопросы «Почему?» и «Как дальше с этим жить?»

Утекло уже немало воды с момента публикации нашего последнего очерка об интересных случаях из практики обслуживания Kubernetes-кластеров и запускаемых в нём сервисов/приложений. Хотим представить очередную серию приключений инженеров «Фланта» в неспокойных водах большой (и не очень) веб-разработки.

Дорогие читатели, доброго дня. Сегодня поговорим немного про Apache Spark и его перспективы развития.



В современном мире Big Data Apache Spark является де факто стандартом при разработке задач пакетной обработки данных. Помимо этого, он также используется для создания стриминговых приложений, работающих в концепции micro batch, обрабатывающих и отгружающих данные маленькими порциями (Spark Structured Streaming). И традиционно он являлся частью общего стека Hadoop, используя в качестве менеджера ресурсов YARN (или, в некоторых случаях, Apache Mesos). К 2020 году его использование в традиционном виде для большинства компаний находится под большим вопросом в виду отсутствия приличных дистрибутивов Hadoop — развитие HDP и CDH остановлено, CDH недостаточно проработан и имеет высокую стоимость, а остальные поставщики Hadoop либо прекратили своё существование, либо имеют туманное будущее. Поэтому всё больший интерес у сообщества и крупных компаний вызывает запуск Apache Spark с помощью Kubernetes — став стандартом в оркестрации контейнеров и управлении ресурсами в приватных и публичных облаках, он решает проблему с неудобным планированием ресурсов задач Spark на YARN и предоставляет стабильно развивающуюся платформу с множеством коммерческих и открытых дистрибутивов для компаний всех размеров и мастей. К тому же на волне популярности большинство уже успело обзавестись парой-тройкой своих инсталляций и нарастить экспертизу в его использовании, что упрощает переезд.

Начиная с версии 2.3.0 Apache Spark обзавёлся официальной поддержкой запуска задач в кластере Kubernetes и сегодня, мы поговорим о текущей зрелости данного подхода, различных вариантах его использования и подводных камнях, с которыми предстоит столкнуться при внедрении.

TL;DR: будет описание Keycloak, системы контроля доступа с открытым исходным кодом, разбор внутреннего устройства, детали настройки.

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

---

За последние несколько месяцев я потратил немало личного времени на изучение работы Linux-контейнеров. В частности, что конкретно делает docker run. В этой статье я собираюсь резюмировать то, что я выяснил, и попытаюсь показать как отдельные элементы формируют цельную картину. Начнем мы наше путешествие с создания контейнера alpine с помощью docker run:

$ docker run -i -t --name alpine alpine ash

Этот контейнер будет использоваться в выводе ниже. Когда вызывается команда docker run, она анализирует параметры, переданные ей в командной строке, и создает JSON объект для представления объекта, который нужно создать docker. Затем этот объект отправляется демону docker через сокет домена UNIX /var/run/docker.sock. Для наблюдения за вызовами API мы можем использовать утилиту strace:

Что нас побудило создать курс по Docker — хотя на рынке десятки предложений по этой теме, и практически каждая IT-школа отметилась в этом направлении?

Побудили нас студенты «Вечерней школы по Кубернетес». В обратной связи мы неоднократно получали запрос, что в ВШК получилась лучшая обучалка по Докеру — именно в составе курса по K8s.

И мы поняли, что у нас хватает материала, практических кейсов, внутренней энергетики спикеров. Плюс есть запрос студентов, есть явный интерес — осталось только выделить Docker в отдельный курс.

Команда Kubernetes aaS от Mail.ru перевела короткую заметку о том, как автоматически генерировать секреты Helm при обновлении. Далее текст от автора статьи — технического директора Intoware, компании-разработчика SaaS-решений.

Контейнеры — это круто. Сначала я был противником контейнеров (стыдно признаться), но теперь я полностью поддерживаю использование этой технологии. Если вы читаете это, то, надеюсь, успешно плавали по морям Docker, осознали преимущества Kubernetes и сделали свою жизнь намного проще с Helm.

Тем не менее некоторые вещи явно сложнее, чем должны быть.

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

Эти же инструменты должны быть эффективными и производительными. В этой статье мы рассмотрим два популярных стека технологий: EFK (Elasticsearch) и PLG (Loki) и разберём их архитектуры и различия.