Kubernetes *

Привет, Хабр! Продолжаю серию статей по проектированию и разработке отказоустойчивой микросервисной системы сокращения ссылок.

Если вы только присоединились, рекомендую ознакомиться с предыдущими частями:

График CPU может выглядеть спокойно, пока контейнеры уже теряют время на троттлинге, ожидании памяти или вводе‑выводе. В Kubernetes 1.36–1.37 для такой диагностики появились более полезные сигналы и возможность менять ресурсы работающих подов без пересоздания.

Разберём, как читать PSI, отличать реальное ресурсное давление от обычной утилизации и связывать эти данные с ресайзом подов.

Pod'ы в Kubernetes появляются, исчезают и меняют IP. Разбираемся, как Service даёт приложению стабильную точку доступа, как работает ClusterIP, DNS, selectors, EndpointSlice и readiness - и как запрос в итоге попадает на конкретный Pod.

Запустить контейнер — дело нескольких секунд. Но как только их количество начинает исчисляться сотнями и тысячами, начинаются сложности — их нужно размещать по узлам, распределять ресурсы, обновлять приложения, не нарушая их доступность, обеспечивать отказоустойчивость и следить, чтобы вся система работала стабильно. И очень быстро оказывается, что основная проблема уже не в самих контейнерах, а в инфраструктуре, на которой они работают.

В ответ на эти сложности появились сервисные модели, позволяющие снять с команд часть рутинных задач и операций. Одни из них полностью скрывают от пользователя серверы и механику оркестрации, оставляя только возможность передать образ и получить работающий сервис. Другие предоставляют готовый Kubernetes-кластер,  избавляя от необходимости разворачивать и обслуживать его control plane, но сохраняя привычную модель работы через API Kubernetes.

На первый взгляд различие между ними не то чтобы огромное — и там, и там в итоге запускаются контейнеры. Но по факту это два разных подхода с разным уровнем контроля, гибкости и разделением зон ответственности. В этой статье разберем, чем Container as a Service отличается от Kubernetes as a Service и как выбрать более подходящую под ваши задачи модель.

У нас начали активно появляться кластеры на Talos Linux, в том числе и небольшая песочница для тестирования продуктов, о которой пойдёт речь далее. Доступы раздавались через обмен рутовыми kubeconfig'ами в yopass. Быстро, привычно и, к сожалению, абсолютно неуправляемо.

Проблема даже не в самом факте передачи файла. Проблема в том, что лежит внутри: клиентский сертификат, который выписан на год, работает всегда и отовсюду, не привязан ни к какому конкретному человеку и не отзывается ничем, кроме ротации CA всего кластера. Сотрудник уходит из компании — его kubeconfig продолжает работать. Ноутбук потеряли — конфиг продолжает работать. Кто-то выполнил kubectl delete не в том кластере — найти его не удастся. Blameless culture в чистом виде.

Хотелось получить другое поведение:

TL;DR. Мы выкатили Татарнетес — национальную обёртку над Kubernetes, где команды, сообщения, ошибки и даже перерывы на чай с чак-чаком и т.п. на татарском. Рядом — TatarOS Linux (обёртка над Talos, которая поднимает кластер с Татарнетесом) и Татарнетес UI (панель на фоне татарского келәма). Всё под собственной лицензией Tatarch 2.0.

Под капотом i18n на чистом bash 3.2 без единой зависимости, три системы письма (кириллица, яңалиф, гарәп язуы), детерминированный чайный график (кластер рандомно останавливается на попить чай с молоком и бабушкиными кыстыбыями) и первый черновик татарской IT-терминологии Kubernetes. А ещё мы прогнали всё на реальном кластере CozyStack — с живыми kubectl/talosctl, RBAC, метриками и одним пойманным багом.

Репозитории tatar-ncf: tatarnetes · tataros · tatarnetes-ui. Лицензия — Tatarch 2.0.

Проект посвящается Саше, Роме, Максу и Рамилю из одного замечательного кубер-чатика.

Часто ли вы сталкиваетесь с проблемой потери данных, неконсистентными состояниями или ошибками в Sentry о внезапно закрытых соединениях при рестарте сервисов? Если вы когда-нибудь пытались это исправить, то наверняка слышали про Graceful Shutdown.

Привет! Меня зовут Антон, я бэкенд-разработчик Python в Selectel. В этой статье поделюсь опытом внедрения Graceful Shutdown в наши сервисы и расскажу, с какими сложностями мы столкнулись.

Всем привет! Нашел в блоге Kubernetes интересную статью о том, как написать собственный экспортер метрик на Go и подключить его к Prometheus. Автор разбирает весь путь: от выбора показателей и первых строк кода до развертывания в кластере и проверки сбора данных. Перевел материал и делюсь.

Корпоративный мессенджер обычно работает внутри управляемого контура: ИТ управляет доступом, информационная безопасность — политиками и потоками данных. Но проектные команды редко совпадают с юридическими границами компании. Сотрудникам нужно постоянно общаться с подрядчиками, партнерами и коллегами из дочерних обществ, и желательно не переносить рабочий контекст в публичные сервисы.

В ноябре 2025 года мы выпустили федерацию VK WorkSpace для двух On-Premise-инсталляций. В релизе 26.2, вышедшем в июле 2026 года, сняли ограничение на парное взаимодействие: теперь в одном чате могут работать участники из нескольких независимых контуров. В статье разберем, как устроена модель доверия, почему мы выбрали репликацию данных на стороне каждой организации, что пришлось изменить в клиентских приложениях и какие ограничения у решения остаются.

Меня зовут Андрей Ковайкин, я старший менеджер продукта направления Мессенджер в команде VK WorkSpace. Мы развиваем единый контур корпоративных коммуникаций, а федерация решает его внешний сценарий: позволяет организациям общаться между собой, не объединяя инфраструктуру, администрирование и политики безопасности.

Я архитектор и до сих пор отхожу от VMware: Kubernetes дался мне не сразу. Как выяснилось, я не один такой. С этим сталкиваются разработчики в нашей команде, которым нужно быстро освоить Kubernetes для повседневной работы. С этим же сталкиваются ИТ-специалисты широкого профиля у заказчиков: они десятилетиями эксплуатировали vSphere, а теперь уходят от него, потому что всё больше ПО поставляется в контейнерах.

Люди приходят к одному вопросу: с чего действительно начать изучение Kubernetes?

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

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

Команда VK Cloud перевела статью о том, как начать изучать Kubernetes без попыток сразу охватить всю экосистему: сначала разобраться в базовых принципах работы кластера, а затем переходить к специализированным инструментам и сценариям эксплуатации. Все схемы взяты из оригинала статьи по ссылке.

Kubernetes дал платформенным командам единообразный способ развёртывать, масштабировать и эксплуатировать контейнеризированные приложения. Теперь многим из них приходится поддерживать и ИИ-нагрузки.

Переход уже начался. По данным CNCF 2025 Annual Cloud Native Survey, 66% организаций, которые размещают генеративные ИИ-модели, используют Kubernetes для части или всех инференс-нагрузок. Однако ежедневно развёртывают ИИ-модели лишь 7% организаций. Этот разрыв показывает разницу между запуском ИИ-нагрузок в Kubernetes и платформой, которая готова непрерывно эксплуатировать ИИ в production.

Проблема заметна и внутри платформенных команд. Исследование 2025 State of AI in Platform Engineering2 показало, что 35% таких команд всё ещё не оркестрируют ИИ-нагрузки. Это говорит о разрыве между внедрением ИИ и зрелостью операционных платформ, необходимых для его масштабной поддержки.

ИИ не требует от платформенных команд отказываться от Cloud Native-практик. Kubernetes, GitOps, observability, автоматизация и самообслуживание по-прежнему составляют ценный фундамент. Однако ИИ предъявляет дополнительные требования к вычислительным ресурсам, планированию, доставке моделей и эксплуатации.

Команда VK Cloud перевела статью о том, что должно измениться, чтобы Kubernetes-платформа была готова к эксплуатации ИИ-нагрузок.

Привет, Хабр! Продолжаем цикл про инфраструктуру для ИИ-задач. В первой статье мы разбирали стратегический вопрос: что проще и выгоднее — собирать самостоятельно или брать готовый ПАК (на примере ПАК Скала^р)? Поговорили и о том, что именно заказчик узнает о самосборе — не на этапе закупки, а через полгода эксплуатации. 

Сегодня же переместимся на следующий уровень: поговорим про аппаратный стек.

Структура статьи такова: для каждого слоя железа — GPU, питание, охлаждение, хранение — я покажу, какую инженерную задачу мы решали при проектировании ПАК и почему приняли именно такие решения, а не другие. Там, где это уместно, приведем цифры, которые помогут понять пороги: когда одно решение заменяется другим и что это означает по деньгам и по производительности.

Поехали!

Классическая ситуация: Go-сервис падает с panic: runtime error: invalid memory address or nil pointer dereference, Nuxt-фронтенд логирует NUXT_UNHANDLED: unhandled rejection. Клиент видит лишь общее «что-то сломалось» — точный текст ошибки остаётся только в логах.

Решение — алертинг по логам. Связка VictoriaLogs + Vector + vmalert + Alertmanager следит за потоком, и как только приложение пишет panic, log.Fatal или NUXT_UNHANDLED, в Telegram уходит алерт. Ниже — как поднять эту связку в Kubernetes без лишней нагрузки на хранилище.

От YAML-манифеста до работающих контейнеров: разбираемся, что Kubernetes делает после kubectl apply.

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

На первый взгляд оба подхода делают одно и то же: позволяют запускать несколько приложений на одном сервере так, чтобы они не мешали друг другу и эффективно использовали ресурсы. Различие кроется в самом подходе к изоляции, который и определяет особенности их применения.

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

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

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

Команда VK Cloud перевела материал Netflix о двух подходах к автомасштабированию Apache Flink. Сначала компания разработала собственный автоскейлер, который анализировал внешние метрики кластера и эффективно экономил ресурсы на простых потоковых конвейерах. Но с ростом числа stateful-задач и сложных графов обработки этого стало недостаточно.

В статье — о том, чем автомасштабирование на уровне отдельных операторов отличается от масштабирования всего кластера, как Flink Autoscaler использует показатель True Processing Rate, зачем Netflix запускает отдельный Temporal workflow для каждой задачи и почему ради стабильности иногда выгоднее сознательно оставить запас вычислительных ресурсов.

Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.

Денис, добрый день! После изучения вашей анкеты, к сожалению, мы не готовы пригласить вас к дальнейшему рассмотрению на обучение в компании. У нас очень большой поток кандидатов на курсы. В данный момент взяли в рассмотрение участников с показателями выше. Ваша анкета будет сохранена, возможно, вернемся к вашей кандидатуре, при наборе на следующий поток. Благодарим за внимание к нашей компании.

Хотя я даже не понял, как смогли оценить мои показатели и в чем они измерялись, если не давали ни тестового задания, ни собеседования. В анкете у них несколько вопросов и уровень образования. Но да ладно, это тема отдельной статьи.

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

На первый взгляд, задание кажется не таким уж и сложным, однако, дьявол кроется в деталях и есть неоднозначное право выбора, которое будет зависеть от ситуации.

Тестовое задание состоит из 4 задач, начнем с первой.

Добавление физического сервера в кластер Kubernetes требует ручных действий: подключиться по SSH, установить пакеты, добавить параметры подключения и секреты, сконфигурировать kubelet, проверить, что узел появился в кластере, повторить для следующего сервера.

Привет, Хабр! Меня зовут Андрей Волков, я руководитель SRE в команде Managed Service for Kubernetes в Yandex Cloud и мы добавили возможность подключать BareMetal-серверы в кластер Kubernetes одной кнопкой.

Привет, Хабр! Наши sheet-ербьюторы не спят и продолжают развивать экосистему даже утром в субботу, когда сон для усталых взрослых людей. Теперь к делу!

Sheeternetes держит кластер контейнеров, у которого control plane — электронная таблица. Этот пост — про то, как заставить два таких кластера работать как один: on-prem-кластер поверх локального Excel-файла и облачный поверх Google-таблицы — по сети, с общей ёмкостью, живой миграцией и рантаймом, которому не нужен Docker. Всё воспроизводимо; код — один небольшой репозиторий.

Привет, Хабр! Значю, что вам на это плевать и вы не хотите это читать, но я все равно продолжу это писать:) В общем, Sheet-Native Computing Foundation продолжает цвести и пахнуть и у нас даже есть сторонние контрибьюторы. А чего добились вы?

Итак, вот что теперь можно сделать в таблице: запушить в неё настоящий OCI-образ контейнера и вытянуть его обратно. Не ссылку на образ, не метаданные о нём — сами слои, хранящиеся как base64 по ячейкам, с адресацией по sha256, собирающиеся байт-в-байт на выходе. У SheetHub — нашего форжа в стиле GitLab, который работает на Google-таблице — появился реестр контейнеров, и он целиком живёт в ячейках.

Этот пост — про то, как это всё устроено.