«Однажды темным-темным вечером в темной-темной комнате», — так должна начинаться любая по-настоящему страшная история. Однако история, от которой шевелятся волосы на голове DevOps-инженера, звучит совсем иначе: прод упал и ничего не работает.
Об одном таком случае — как Kube API-серверы заняли всю память и уронили API Kubernetes — мы и рассказали в статье. И конечно, поделились, как ограничивать число запросов в Kubernetes API, чтобы с вами такого не случалось.
В статье мы расскажем, как столкнулись с множественными запросами к API-серверу Kubernetes от одного из приложений, к чему это привело и каким образом проблема была решена.
Разработка приложений иногда достигает такого уровня, когда тестировать новые функции на статических окружениях становится неудобно. Окружений не хватает, разработчики мешают друг другу при запуске тестов. Такая проблема возникла у одного из наших клиентов.
Мы решили сделать гибридный кластер Kubernetes на базе существующего bare-metal-кластера, чтобы на лету заказывать узлы у облачного провайдера, когда в основном кластере заканчиваются ресурсы; разворачивать на этих узлах нужные окружения для тестов; сворачивать окружения после выхода изменений в production и отключать узлы. Для этого мы воспользовались модулем cloud-provider-openstack, который входит в состав Kubernetes-платформы Deckhouse.
Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса etcd из одного облачного кластера Kubernetes в другой. Такой способ поможет избежать простоя и связанных с ним последствий. Согласно стартовым условиям, оба кластера находятся в облаке, а потому нам предстоит столкнуться с некоторыми ограничениями и трудностями — им мы уделим особое внимание.
Примечание: Сразу оговорим, что речь идет про миграцию не того etcd, в котором Kubernetes хранит все состояние кластера. В статье описана миграция отдельной инсталляции etcd, которая используется сторонними приложениями и находится внутри кластера k8s.
На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.
В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры.
В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.
Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется.
Звучит как фантастика?
Привет! На связи Василий Мармер, DevOps-тимлид компании «Флант». Сегодня мы поговорим об Atlas — еще одной утилите, которая делает работу DevOps-инженера более комфортной. Atlas увидел мир в ноябре 2021 года, а сейчас у него более 3,3 тысячи звёзд на GitHub. Язык программирования — Go.
Рассматриваемая утилита служит для управления схемами миграций баз данных и позволяет задействовать современные паттерны DevOps. Разработчики Atlas воспринимают свой инструмент как универсальный способ визуализировать, планировать и выстраивать миграции схем баз данных в соответствии с CI.
В 2023 году люди боятся многих новых для них вещей, например, systemd, SELinux, IPv6 и др. От этих вещей люди стараются избавиться, отключить, удалить. Об этом написано во множестве любительских мануалов в интернете, коим может являться и этот. Далее речь пойдёт о протоколе интернета IP версии 6, для краткости — IPv6.
Целью данной заметки показать, что IPv6 не намного страшней того IPv4, который вы сейчас используете. Он способен решить все те же ваши задачи, что вы решали с помощью старого протокола, а также упростить себе жизнь за счёт более простой настройки сети. Кроме того, возможно, даже сейчас используете новый протокол даже не подозревая об этом.
Текст я попытался написать максимально доступным языком. Это не технические руководство. Воспринимайте эту заметку как отправную точку, просто чтобы перестать бояться использовать IPv6 и познакомиться с его основными особенностями, которые отличают его от IPv4, но при этом дают заметные преимущества.
Всем привет, меня зовут Зуев Алексей, и я работаю DevOps-инженером в компании Bimeister! Сегодня я расскажу вам о том, как мы облегчаем жизнь нашим разработчикам и как разработчик может отследить состояние своего микросервиса в namespace Kubernetes. Основная цель этой статьи - описать, как мы пришли к дашборду для персональных стендов разработчиков.
Меня давно заинтриговала тема дедупликации данных. Это произошло в далеком 2016 году, когда передо мной встала задача впихнуть не впихуемое, на продакшн-серверах. Но обнаружить доступное решение оказалось невероятно сложно (на тот момент невозможно). Со временем у меня возникли и личные задачи, когда я хотел уменьшить объем третьей или четвертой копии данных, чтобы сэкономить место на диске. Но, возможно, я просто одержим датахордингом, и это тоже не исключено.
Привет, меня зовут Панов Михаил, я DevOps‑инженер МТС Digital. Хочу поделиться с вами опытом построения «модульных» pipelines на основе gitlab-ci. В этой статье я расскажу, что такое модульный CI/CD, из чего он состоит, для чего нужен и как поможет командам, поддерживающим большой список нетиповых репозиториев.
Привет! Меня зовут Игорь, я управляющий партнёр и системный архитектор в KTS.
В этой статье, подготовленной по мотивам моего доклада в «Школе мониторинга» Slurm, хочу поделиться своим набором best practice «Как лучше всего настроить Grafana Loki для сбора логов в инфраструктуре».
На мой взгляд, порог входа в систему достаточно низкий, и в Интернете много туториалов. Поэтому я расскажу о более сложных и не совсем очевидных вещах, с которыми не раз сталкивался при работе с Grafana Loki.
Я люблю старые программы, мне нравится их изучать и смотреть, как они развивались и во что сейчас превратились, или умерли, так и не дожив до сегодняшнего дня. Ещё мне нравится смотреть разные YouTube-каналы, посвящённые ретро-тематике, на которых рассказывают об истории программ, игр, игровых приставок или старых компьютеров. Хочу сказать всем этим людям «спасибо» за то, что сохраняете частичку истории технологий. И, вдохновившись их трудами, мне захотелось попробовать самому прикоснутся к истории, собрав и запустив что-то относительно старое, но до сих пор живущее и развивающееся. Мой выбор пал на первую версию Linux, а именно версию 0.01.
Те, кто знаком с ранними днями создания Linux, знают, что Линус Торвальдс писал её для компьютеров на основе 386-х процессоров в пропатченной версия Minix 1.5.10. И не смотря на то, что linux-0.01 собирали не раз, в том числе и на современных версиях компилятора, мне хотелось побыть хоть немного в шкуре самого Линуса и самому собрать ядро в родной для этой ОС среде. А именно на максимально близком, хоть и виртуальном аппаратном обеспечении, в настоящей Minix 1.5.10 (точнее, Minix-386) с древней версией GCC 1.37.1
17 сентября ядру Linux исполнится 32 года. Это прекрасный повод вспомнить, как всё начиналось…
И снова здравствуйте! В этой статье я хочу продолжить вопрос динамических gitlab-раннеров, которые запускаются в Яндекс Облаке. В прошлой статье мы рассмотрели старый подход, основанный на docker-machine.
Естественным будет вопрос: «Чем плох docker-machine?» И тут такой же простой ответ: «Ничем, он хорош». Но хорош он ровно до момента его промышленного использования.
Постановка задачи — есть виртуальная машина в облаке — мы хотим решить две задачи:
1. Резервировать ее по расписанию на наш сервер(а), находящиеся под нашим полным контролем.
2. Иметь возможность в любой момент сконвертировать нужную версию из резервной копии в виртуальную машину (в любом формате) и запустить ее на нашем оборудовании (т. е. приземлить виртуальную машину из облака на грешную...).
И так, поехали!
Всем привет, в данной статье мы затронем основные аспекты работы со спотовыми нодами AWS, как, что, и почему? А так же будут живые примеры инфраструктуры построенной на спотах, и в конце самое интересное это кол-во сэкономленных денег $. За подробностями прошу код кат.