Это ещё не туториал, но относительно подробный гайд о том, как компоненты Операторов взаимодействуют с Kubernetes API на уровне кода (Golang), чтобы реализовать заложенную в них логику для автоматизации вполне определённых практических задач. И да, всем известно, максимальный уровень автоматизации работы в Кубернетес ограничен лишь желанием самих разработчиков избавиться от рутины в близкой для них предметной области, потому я разделил текст на три части, чтобы вы могли без промедления промотать к наиболее актуальной, в которой узреете нечто достойное вашего внимания:

1. Кастомные ресурсы - мониторы Прометеус-оператора
2. Информеры и контроллеры
3. Сайдкар-Инжекторы с помощью аннотаций и вебхуков

Всем привет! Я работаю Dev-Ops инженером в небольшой команде и мы уже 4-ый месяц используем Yandex Cloud для наших сервисов. Так сложилось, что с Kubernetes и облачными вычислениями я столкнулся впервые, поэтому многое приходится изучать на ходу, иногда на "горьком" опыте. На данный момент наши микросервисы развернуты в зональном кластере Kubernetes с одним рабочим узлом, по одной реплике на каждый Deployment. Это означает, что никакой отказоустойчивости и масштабируемости нет и при малейшей нагрузке приложения упадут.

Поэтому, пока нагрузка идет только от команды разработчиков, я решил заранее побеспокоиться об отказоустойчивости наших сервисов, развернутых в Yandex Managed Service for Kubernetes. Сегодня я разверну на своем облаке Kubernetes кластер и покажу как будет вести себя автомасштабируемое приложение под нагрузкой. Для управления инфраструктурой воспользуемся Terraform, для имитирования нагрузки сервисом Yandex Load Testing (в стадии Preview) от Yandex Cloud.

Привет! Это снова я :)

Первая статья из цикла “Скандальное разоблачение x86: ARM врывается с двух ног” получила отклик больше, чем я ожидал: 155+ комментариев и 55 плюсов. Спасибо всем за активное обсуждение — в комментариях получился холивар с кучей интересных мыслей по сабжу. 

В конце той статьи я сделал голосование, чтобы узнать, ждут ли читатели Хабра продолжения?

66.6% (600+ голосов) ответили “да”

26% отметили, что они — человеки-пауки :D

7.3% не хотят

В общем, спрос адский (не удержался от каламбура), а поэтому пришло время для второй части. Кстати, в конце будет новое голосование :)

Привет!

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

Статья задумана как констатация существующей проблемы – сравнительно низкого качества российских веб-ресурсов, и как стартер для серии предстоящих публикаций, развивающих эту тему. Обозначить проблему – единственная ее цель, поэтому она не предполагает какого бы то ни было анализа, тем более готовых ответов на логичный вопрос «что делать?».

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

Во-первых, он по природе своей децентрализован и в настоящее время на удивление демократично не стеснен законодательством – во-вторых.

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

Технологии и наилучшие практики, использующиеся во всем мире для строительства веба, доступны повсеместно и многие из них open source и free. Сам процесс строительства не требует капитальных вложений, требующихся на строительство дорог, газопроводов, запуск космических станций. Поэтому, в отличие от прочих глобальных составляющих жизни любого общества, применительно к вебу вопрос «почему он у нас такой хреновый?» не является риторическим.