Я из команды технологической платформы НЛМК ИТ. Спойлер — это все, что про централизованные сервисы около DevOps, Kubernetes, стриминг вокруг Kafka и так далее. Расскажу, зачем и по каким принципам мы ее строили, что получилось неплохо и всем советуем. Обо что споткнулись и всем советуем там не спотыкаться.
В статье разберем процесс внедрения виртуализации в платформу контейнеризации, обсудим ее преимущества для пользователей и покажем, каким образом это решение упрощает администрирование ИТ-инфраструктуры.
В 2017 году мы рассказывали о том, как спроектировали нашу систему поиска сообщений так, чтобы она могла индексировать миллиарды сообщений. Благодаря этому наша поисковая инфраструктура стала высокопроизводительной, экономной, масштабируемой и простой в использовании. Мы решили выбрать Elasticsearch, в котором сообщения Discord шардились по индексам и использовалось логическое пространство имён для сообщений Elasticsearch в двух кластерах Elasticsearch. Сообщения шардились или по серверу Discord (который ниже будем называть гильдией) или по личным сообщениям (DM). Это позволило нам хранить все сообщения гильдии рядом для обеспечения высокой скорости запросов и работать с маленькими, более удобными кластерами. Так как поиском пользуются не все, сообщения индексировались лениво, и мы создали очередь сообщений, позволявшую воркерам получать блоки сообщений для индексирования, чтобы воспользоваться возможностями массового индексирования (bulk-indexing) Elasticsearch.
Но с ростом объёмов Discord наша поисковая инфраструктура начала трещать по швам…
Всё началось с того, что в 2024 году мне в руки попал интересный экземпляр мини-ПК ( Характеристики: Процессор Intel N100 / RAM 16 GB / SSD 500 GB.) решив, что раз уж основная рабочая лошадка у меня уже есть, этот мики-ПК предстоит переделать в мини-сервер и приспособить к мои pet-проектам. Заказал себе 1Гбит интернет, белый IP адрес и ушел творить.
Первая моя задумка с треком провалилась, т.к изначально я разместил на нем Gitlab Server, NextCloud и пару своих приложений. «Жужжал» он не по-детски, я взаправду подумал, что в какой-то момент он просто отлетит к своим небесным производителям.
В Kubernetes важно правильно настроить StorageClass, чтобы эффективно использовать место для хранения данных приложений. Выбирать StorageClass по умолчанию можно вручную, но такой способ часто приводит к ошибкам и усложняет работу. В статье расскажем, почему ручной способ — не самый удобный, и покажем подход, который реализовали в Deckhouse. Он помогает проще и надёжнее управлять хранением данных.
Когда я был маленьким и глупым, в своей домашней лаборатории я развернул kuber‑barick — его возможностей хватало на баловство с нейронками и обучением крутить поды, но при попытке поднять второй (например, для стейджинга) всё упёрлось в дефицит железа. Решил перейти на более автоматный подход: наткнулся на Talos и Cluster API (CAPI).
Привет, на CKA курсе туторы нарочито вдалбливают последовательность действи: set the cluster, set the namespace, set the pod... И все это происходит в консоли, используя kubectl - консольная утилита для управления k8s кластерами. Мне настолько это вдолбилось что я решил это автоматизировать. У меня уже был интересный проект автоматизации ssh подключений (sshto), не долго думая, я взял его за основу и написал kui. Это bash скрипт, dialog обёртка для kubectl. У диалога есть приятная фича присваивать горячку каждому пункту меню по первому символу. Это очень удобно, в результате весь k8s кластер оказывается у вас на кончиках пальцев.
Сегодня официально выпустили очередную версию Kubernetes — 1.33. Собрали все 64 изменения в одном материале. Из основных нововведений: упорядоченное удаление ресурсов в пространстве имён на основе логических зависимостей и соображений безопасности, декларативная валидация для нативных API-типов, расширение механизма CredentialProvider, доступ подов к информации о топологии кластера, изменение алгоритма выдержки CrashLoopBackOff, обязательная аутентификация при извлечении private-образов из репозиториев и многое другое.
В этой статье мы разберём основные недостатки Istio в сравнении с Cilium Service Mesh, чтобы даже начинающий разработчик мог понять, в чём разница и почему некоторые команды выбирают Cilium вместо Istio.
Привет! Меня зовут Георг Гаал. Я CTO в AEnix, и мы разработали платформу cozystack на базе технологий Talos Linux и Kubernetes. Она позволяет легко и просто запустить своё частное или даже публичное облако. У нас уже есть множество клиентов, в том числе и среди хостинговых компаний, и у них регулярно возникает вопрос: «можно ли запустить систему в air-gapped режиме?» Ответ будет универсальным для любого дистрибутива kubernetes. Частности будут в названии образов. Давайте разберёмся как же можно этого добиться, но начнём с определений.
Управление Kubernetes в продакшене требует внимательности и соблюдения лучших инженерных практик, особенно в масштабных средах. В этой статье мы собрали основные принципы эксплуатации, которые помогут избежать распространённых проблем, повысить стабильность и минимизировать сложность работы с Kubernetes. Вы узнаете о важнейших аспектах, таких как управление ресурсами, настройка высокой доступности, мониторинг, автоматизация через GitOps и оптимизация затрат — всё это позволяет эффективно управлять инфраструктурой, снижая риски и улучшая производительность.
Про информационную безопасность Kubernetes-кластеров много пишут с позиции специалистов ИБ. Но полезно взглянуть на эту тему глазами обычных пользователей K8s — инженеров и разработчиков. Тех, кто много работает со своими приложениями в подах, но не управляет служебными частями кластера.
Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.
Pyroscope — это мощный инструмент непрерывного профилирования, созданный для мониторинга производительности приложений в реальном времени. В этой статье мы рассмотрим, как быстро развернуть Pyroscope, подключить к нему Node.js приложение и проанализировать поведение кода без использования Grafana Alloy.
Привет! На связи снова Саша Хренников, руководитель DevOps-юнита в KTS.
На прошлой неделе мы запустили испытание для DevOps-инженеров, приуроченное к дате первого полета человека в космос. Участникам было необходимо найти и исправить ошибку в конфигурации ArgoCD, чтобы обеспечить корректный запуск приложения. Как мы и обещали, 10 победителей испытания получат наш фирменный мерч, но перед тем, как огласить их список, я предлагаю познакомиться с решением.
Spoiler alert: мы оставляем доступ к этому испытанию (и ко всем предыдущим) открытым, чтобы вы могли потренироваться перед будущими челленджами. Если вы еще не пытались решить его, не торопитесь читать разгадку — лучше попробуйте найти ее самостоятельно. Сделать это вы можете в нашем боте.
Для тех же, кому не терпится узнать ответ, продолжаем.
Джон Такер помогает разобраться с ключевыми аспектами управления ресурсами CPU в Kubernetes. Он объясняет разницу между запросами и лимитами, показывает их влияние на производительность приложений и делится практическими советами по настройке контейнеров. Если хотите улучшить работу кластеров, эта статья станет вашим гидом.
Когда мы упаковываем Spring Boot-приложение в Docker-образ, важно не только обеспечить его запуск. Нам нужен такой образ, который поможет понять причины проблем: падений, тормозов и других сбоев.
В новой статье выясним, какие нештатные ситуации могут возникнуть, какие инструменты пригодятся для диагностики и как собрать образ, в котором всё это учтено.
Если вы когда-либо разворачивали Kubernetes-кластер на виртуальных машинах (ВМ), то знаете, насколько это может быть ресурсоёмко. Особенно это ощущается на одноплатных компьютерах вроде Orange Pi 5 Plus, даже несмотря на его 16 ГБ оперативной памяти. Для домашнего лабораторного стенда или лёгкой продакшн-инфраструктуры хочется чего-то более лёгкого и быстрого
Обычно Talos Linux предоставляется в виде набора готовых образов под различные системы.
Стандартный метод установки предполагает, что вы возьмёте подготовленный образ под конкретное облако или гипервизор и просто создадите из него виртуальную машину. Если же говорить о физических серверах, то предполагается, что для загрузки образа Talos Linux и последующей установки вы будете использовать ISO или PXE.
К сожалению, это не работает, когда речь заходит о провайдерах, которые предоставляют преднастроенный сервер или виртуальную машину без возможности использовать кастомный образ или даже ISO для установки через KVM. В этом случае ваш выбор будет ограничен лишь теми дистрибутивами, которые предлагает облачный провайдер.
Привет, Хабр! Меня зовут Александр Цай, я ведущий аналитик в МТС Web Services, но на деле занимаюсь всеми вопросами, касающимися DA/DE/BI: выявлением потребностей и сбором требований, проектированием дашбордов и витрин для них, построением и развитием внутреннего хранилища, поиском источников данных, созданием сложных ETL-пайплайнов по их доставке, DQ, проведением аналитики и много чем еще.
В этом материале я расскажу про разворачивание пайплайна по стримингу данных из MongoDB в PostgreSQL с помощью Apache Flink (стримить из Kafka банально, а так заодно пощупаем документоориентированную БД). Делать это мы будем в minikube (kubernetes), а языком программирования для заданий выступит Python. Все описанное в посте выполняется на MacBook с процессором i7.
В интернете, тем более русскоязычном, нет информации о стриминге из MongoDB в Postgres с помощью Flink. Почти все материалы по Flink, которые мне попадались, сводятся к пережевыванию примера WordCount из flink-kubernetes-operator, где на запущенном поде из папки с примерами читается файл и в консоль выводится количество слов в нем. Если спускаться до использования PyFlink, то мы натыкаемся на кастомные образы с Harness SDK и Apache Beam и другие страшные слова. Знакомо?
Так вот, это не наш путь! Данное руководство будет полезно тем, кто такой же извращенец хочет пощупать Flink на родном Python и кто не планирует брать примеры, оторванные от реальности.
