Kubernetes *

Приветствуем вас, Хабр!

В свое время мы первыми вывели на российский рынок тему Kafka и продолжаем следить за ее развитием. В частности, нам показалась интересной тема взаимодействия Kafka и Kubernetes. Обзорная (и довольно осторожная) статья на эту тему выходила в блоге компании Confluent еще в октябре прошлого года под авторством Гвен Шапиры. Сегодня же мы хотим обратить ваше внимание на более свежую, апрельскую статью Йоханна Гайгера (Johann Gyger), который, хотя и не обошелся без вопросительного знака в названии, рассматривает тему в более предметном ключе, сопровождая текст интересными ссылками. Простите нам пожалуйста вольный перевод «chaos monkey», если сможете!

Kubernetes (K8s) — это мощная платформа, которая за последние пять лет кардинально изменила методы работы с программным обеспечением. Она пользуется активным спросом, и поэтому некоторые компании стали предлагать Kubernetes-as-a-service. Cloud4Y предлагает познакомиться с наиболее интересными дистрибутивами K8s.

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

27 мая в главном зале конференции DevOpsConf 2019, проходящей в рамках фестиваля РИТ++ 2019, в рамках секции «Непрерывная поставка», прозвучал доклад «werf — наш инструмент для CI/CD в Kubernetes». В нём рассказывается о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая возможные пути решения, мы показываем, как это реализовано в Open Source-инструменте werf.

С момента выступления наша утилита (ранее известная как dapp) преодолела исторический рубеж в 1000 звёзд на GitHub — мы надеемся, что растущее сообщество её пользователей упростит жизнь многим DevOps-инженерам.



Итак, представляем видео с докладом (~47 минут, гораздо информативнее статьи) и основную выжимку из него в текстовом виде. Поехали!

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



В пятницу, 19 июля, сервис Hosted Prometheus в Grafana Cloud перестал функционировать примерно на 30 минут. Приношу извинения всем клиентам, пострадавшим от сбоя. Наша задача — предоставлять нужные инструменты для мониторинга, и мы понимаем, что их недоступность усложняет вашу жизнь. Мы крайне серьезно относимся к этому инциденту. В этой заметке объясняется, что произошло, как мы на это отреагировали и что делаем для того, чтобы подобное больше не повторялось.

Несмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!

Вводные

Для начала обозначу контекст:

• Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
• Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
• В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).

Прим. перев.: Dailymotion — один из крупнейших в мире сервисов хостинга видео и потому заметный пользователь Kubernetes. В этом материале системный архитектор David Donchez делится итогами создания production-платформы компании на базе K8s, которая начиналась с облачной инсталляции в GKE и закончилась как гибридное решение, что позволило добиться лучшего времени реакции и сэкономить на инфраструктурных затратах.

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

Почему стоит создавать собственную платформу на базе Kubernetes?

Платформа Red Hat OpenShift Container Platform 4 позволяет поставить на поток создание хостов для развертывания контейнеров, в том числе в инфраструктуре поставщиков облачных сервисов, на платформах виртуализации или в bare-metal системах. Чтобы создать в полном смысле облачную платформу, нам пришлось взять под жесткий контроль все применяемые элементы и таким образом повысить надежность сложного процесса автоматизации.



Очевидным решением стало использование в качестве стандарта Red Hat Enterprise Linux CoreOS (разновидности Red Hat Enterprise Linux) и CRI-O, и вот почему…

Go на данный момент является монополистом среди языков программирования, которые люди выбирают для написания операторов для Kubernetes. Тому есть такие объективные причины, как:

1. Существует мощнейший фреймворк для разработки операторов на Go — Operator SDK.
2. На Go написаны такие «перевернувшие игру» приложения, как Docker и Kubernetes. Писать свой оператор на Go — говорить с экосистемой на одном языке.
3. Высокая производительность приложений на Go и простые инструменты для работы с concurrency «из коробки».

NB: Кстати, как написать свой оператор на Go, мы уже описывали в одном из наших переводов зарубежных авторов.

Но что, если изучать Go вам мешает отсутствие времени или, банально, мотивации? В статье приведен пример того, как можно написать добротный оператор, используя один из самых популярных языков, который знает практически каждый DevOps-инженер, — Python.

27 апреля на конференции Стачка-2019, в рамках секции «DevOps», прозвучал доклад «Автомасштабирование и управление ресурсами в Kubernetes». В нём рассказывается о том, как с помощью K8s обеспечить высокую доступность приложений и гарантировать их максимальную производительность.



По традиции рады представить видео с докладом (44 минуты, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!

В апреле ко мне постучались организаторы Слёрм — курсов по Kubernetes — потестировать и рассказать своё впечатление:

Дмитрий, Слёрм — это трехдневный интенсив по Kubernetes, плотное учебное мероприятие. Вряд ли вы сможете о нем написать, если просто посидите два часа на первой лекции. Вы готовы полноценно участвовать?

Перед слёрмом надо было пройти подготовительные online-курсы по ansible, docker и ceph.
Затем в репах взять код и точные инструкции, по которым уже на лекциях проходить каждую командную строчку за строчкой с ведущими.

— Подтверждаю, что готов полноценно участвовать в обоих курсах.

И после этого обеспечена напряженная работа на 6 дней (базовый Слёрм и МегаСлёрм) в аудитории, битком набитой сисадминами.

Прим. перев.: С Kubernetes-энтузиастами из проекта Garden мы познакомились на недавнем мероприятии KubeCon Europe 2019, где они произвели на нас приятное впечатление. Этот их материал, написанный на актуальную техническую тему и с заметным чувством юмора, — наглядное тому подтверждение, а посему мы решили его перевести.

Он рассказывает о главном (одноименном) продукте компании, идея которого — автоматизация рабочих процессов и упрощение разработки приложений в Kubernetes. Для этого утилита позволяет легко (буквально одной командой) разворачивать в dev-кластере новые изменения, сделанные в коде, а также предоставляет разделяемые ресурсы/кэши для ускорения сборки и тестирования кода командой. Две недели назад у Garden состоялся релиз 0.10.0, в котором стало возможным использовать не только локальный Kubernetes-кластер, но и удаленный: именно этому событию и посвящена данная статья.

Меньше всего я люблю работать с Kubernetes на своем ноутбуке. «Кормчий» поглощает его процессор и аккумулятор, заставляет кулеры вращаться без остановки и сложен в обслуживании.


Фотография со стока в тему для пущего эффекта

Прим. перев.: После недавней публикации материала о методах pull и push в GitOps мы увидели интерес к этой модели в целом, однако русскоязычных публикаций на эту тему оказалось совсем мало (на хабре их попросту нет). Посему рады предложить вашему вниманию перевод другой статьи — пусть и уже почти годичной давности! — от компании Weaveworks, глава которой придумал термин «GitOps». В тексте поясняется суть подхода и ключевые отличия от уже существующих.



Год назад мы опубликовали введение в GitOps. Тогда мы рассказали, как команда Weaveworks запустила SaaS, целиком основанную на Kubernetes, и разработала набор предписывающих лучших практик для развертывания, управления и мониторинга в среде cloud native.

Всем привет. Перед уходом на выходные спешим поделиться с вами еще одним переводом, подготовленным специально для студентов курса «Android-разработчик. Продвинутый курс».

Пробуем новый UI-фреймворк для Android-приложений

В течение последних нескольких лет, участвуя во многих мобильных проектах, мне приходилось использовать различные технологии, например, такие как Android, ReactNative и Flutter. Переключение с ReactNative обратно на классический Android вызвало у меня смешанные чувства. Возвращение к Kotlin прошло хорошо, но я очень скучал по UI-фреймворку React. Небольшие повторно используемые компоненты, с помощью которых создается пользовательский интерфейс, великолепны и обеспечивают большую гибкость и скорость разработки.

Салют, хабровчане! Перевод следующей статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes», занятия по которому стартуют уже завтра. Начнем.

Автомасштабирование в Kubernetes

Автомасштабирование позволяет автоматически увеличивать и уменьшать рабочие нагрузки в зависимости от использования ресурсов.

У автомасштабирования в Kubernetes два измерения:

• автомасштабирование кластера (Cluster Autoscaler), которое отвечает за масштабирование узлов;
• горизонтальное автомасштабирование подов (Horizontal Pod Autoscaler, HPA), которое автоматически масштабирует количество подов в развертывании или наборе реплик.

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

Добрый день.

Недавно передо мной встала задача запуска spring boot 2 приложения в kubernetes кластере используя docker образ. Эта проблема не является новой, достаточно быстро я нашел примеры в гугле и запаковал свое приложение. Я был очень удивлен не найдя alpine образ для jdk11 и надеялся что slim будет достаточно небольшим, но момент отправки образа на docker registry я обратил внимание что его размер составлял почти 422 мегабайт. Под катом описание того как я уменьшил docker образ с моим spring boot и java 11 до 144 мегабайт.

Привет! Меня зовут Вадим Мадисон, я руковожу разработкой System Platform Авито. О том, как мы в компании переходим с монолитной архитектуры на микросервисную, было сказано не раз. Пора поделиться тем, как мы преобразовали свою инфраструктуру, чтобы извлечь из микросервисов максимум пользы и не дать себе в них потеряться. Как нам здесь помогает PaaS, как мы упростили деплой и свели создание микросервиса к одному клику — читайте дальше. Не всё, о чём я пишу ниже, в Авито реализовано в полной мере, часть — то, как мы развиваем нашу платформу.

(А ещё в конце этой статьи я расскажу о возможности попасть на трехдневный семинар от эксперта по микросервисной архитектуре Криса Ричардсона).

Прим. перев.: В сообществе Kubernetes явную популярность набирает тренд под названием GitOps, в чём мы лично убедились, посетив KubeCon Europe 2019. Этот термин был относительно недавно придуман главой компании Weaveworks — Alexis Richardson — и означает применение привычных для разработчиков инструментов (в первую очередь — Git, откуда и само название) для решения задач эксплуатации. В частности, речь об эксплуатации Kubernetes через хранение его конфигураций в Git и автоматического выката изменений в кластер. О двух подходах к этому выкату и рассказывает Matthias Jg в данной статье.



В прошлом году (на самом деле, формально это произошло в августе 2017 г. — прим. перев.) появился новый подход к развёртыванию приложений в Kubernetes. Он называется GitOps, а в его основе лежит базовое представление о том, что отслеживание версий deployment'ов ведется в безопасной среде Git-репозитория.

В Челябинске проходят митапы системных администраторов Sysadminka, и на последнем из них я делал доклад о нашем решении для работы приложений на 1С-Битрикс в Kubernetes.

Битрикс, Kubernetes, Сeph — отличная смесь?

Расскажу, как мы из всего этого собрали работающее решение.

Поехали!

Всем привет! Сегодня мы продолжаем делиться материалом, переведенным специально для студентов курса «Инфраструктурная платформа на основе Kubernetes». Приятного прочтения.

Kubernetes быстро стал стандартом для поставок и масштабирования контейнерных приложений и управления ими. Это очень гибкое и универсальное решение с открытым исходным кодом. У него обширная документация, и в ней не всегда легко найти нужный раздел. Поэтому Kubernetes так непросто освоить. После планирования кластера его еще нужно установить, а тут тоже не все гладко. Поэтому и существуют инструменты развертывания, вроде Kubespray, которые упрощают работу. Я расскажу об автоматическом развертывании кластера Kubernetes с помощью Kubespray в облаке OpenStack (Open Telekom Cloud).