Это вторая часть серии статей, где мы шаг за шагом строим PaaS на базе Kubernetes без написания кода. Напомню, для чего мы это делаем: наша цель — выжать максимум из современных технологий и экосистемы Kubernetes, чтобы создать PaaS-решение, которое упростит жизнь разработчикам. Мы хотим, чтобы приложения и сервисы разворачивались быстро, удобно и без глубокого погружения в инфраструктуру.
Низкий порог входа в разработку контроллеров Kubernetes часто приводит к проблемам в production. Мы перевели статью, в которой автор делится опытом создания надёжных контроллеров, рассказывает о принципах проектирования API и объясняет важность автономной реконсиляции. Узнайте, как сделать контроллеры действительно масштабируемыми.
Обычно, когда мы говорим о безопасности Kubernetes, мы прежде всего говорим о защите подов от внешних угроз, но в некоторых случаях они сами могут представлять определенную опасность. Для того, чтобы эти угрозы мог реализовать атакующий, у него должны быть доступ к кластеру, разрешение RBAC на создание одного некоторых типов ресурсов (CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet) хотя бы в одном пространстве имен, и также должны отсутствовать политики безопасности.
Если у вас все это есть — тогда мы идем к вам в этой статье мы рассмотрим, какие атаки из подов вам могут грозить. А даже если есть не все, то особенно расслабляться все равно не стоит.
Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.
Ранее, автор уже рассмотрел способ масштабирования через партицирование. В данной статье рассмотрим шардирование сервиса Баланс дабы обеспечить его работу с миллиардами пользователей без необходимости использовать суперкомпьютеры, а при желании вовсе запускать на "кофеварках".
После ухода известных вендоров у многих возникла задача импортозамещения и миграции между платформами контейнеризации. В этой статье разберём опыт решения этой задачи и как свести к минимуму зависимости приложений от конкретной версии и/или реализации Kubernetes. Рассмотрим проблемы, обсудим возможные пути и конкретные технологии для их решения и, главное, посмотрим, как всё это работает.
Статья написана по мотивам выступления Максима Чудновского, лидера по продукту Platform V Synapse Service Mesh СберТех на Highload++, где он рассматривал кейс миграции с OpenShift на Platform V DropApp, но предложенные подходы могут быть использованы и для миграции на другие российские Kubernetes-платформы: Deckhouse, Штурвал, Боцман и так далее.
Помимо вариантов использования механизмов ETL, трансляции шаблонов в релизных конвейерах, рассматривается подход применения менеджера политик Kubelatte для того, чтобы мигрировать с OpenShift без единой правки кода.
Привет, Хабр! Меня зовут Павел Минкин, тружусь в качестве DevOps-инженера в FinTech-компании. Интересуюсь технологиями, автоматизирую все, что попадает под руку, верю в DevSecOps, провожу вебинары.
Давайте ответим на вопросы, которые витают в воздухе, но остаются незаданными: а что произойдет, если засунуть AI приложение в кластер? А надо ли это делать? И как это сделать минимальным количеством инструментов? А можно без GPU?
Я из команды технологической платформы НЛМК ИТ. Спойлер — это все, что про централизованные сервисы около 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).
Сегодня официально выпустили очередную версию 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. Настоящий кейс — никаких идеальных диаграмм, только пот, баги и консоль. Если вы думаете о миграции с монолита, эта статья — как разговор со старшим братом, который уже наступил на все грабли и показывает, где не ходить.
Про информационную безопасность Kubernetes-кластеров много пишут с позиции специалистов ИБ. Но полезно взглянуть на эту тему глазами обычных пользователей K8s — инженеров и разработчиков. Тех, кто много работает со своими приложениями в подах, но не управляет служебными частями кластера.
Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.
Pyroscope — это мощный инструмент непрерывного профилирования, созданный для мониторинга производительности приложений в реальном времени. В этой статье мы рассмотрим, как быстро развернуть Pyroscope, подключить к нему Node.js приложение и проанализировать поведение кода без использования Grafana Alloy.
