Электричество можно экономить по-разному, но в основном экономия связана с энергосберегающими устройствами типа светодиодных лампочек, холодильников с высоким классом энергоэффективности или умных розеток с таймерами. Но в этой статье мы расскажем о другом способе — он позволяет снизить платежи за электроэнергию до 30%. Причем новое оборудование покупать не надо, да и режим потребления менять тоже.

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

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

Что потребляет электричество в Ростелекоме
Объекты Ростелекома — это не просто офисы с компьютерами. Это целая инфраструктура телекоммуникационной сети с тысячами зданий и сооружений по всей стране:

Автоматические телефонные станции (АТС) — те самые здания, куда приходят все телефонные линии города


Базовые станции — вышки сотовой связи со всем оборудованием


Узлы связи — технические помещения с оборудованием, обеспечивающим работу сети интернет


Контейнеры с оборудованием связи — компактные модули в отдаленных районах


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

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

У Ростелекома сотни тысяч таких объектов от Калининграда до Владивостока, в каждом регионе страны. Сейчас наша система охватывает 15 тысяч из них — те, на которых уже стоят умные счетчики, умеющие передавать данные удаленно. И в дальнейшем их количество будет расти.

Откуда берётся экономия, если всё продолжает работать?
В отличие от квартиры, где у вас есть тариф день/ночь и всё просто, для бизнеса существует шесть ценовых категорий тарифов на электроэнергию, и в зависимости от характера потребления электроэнергии один и тот же объект может платить по-разному:

• Простой тариф (Первая ценовая категория): Платите за общее количество киловатт, как в квартире по обычному счётчику
• Многозонный тариф (Вторая ЦК): День дороже, ночь дешевле — как в квартире с двухтарифным счётчиком, только для бизнеса
• Почасовой тариф (Третья ЦК): Каждый час имеет свою цену — утренние и вечерние пиковые часы дороже, ночные — дешевле
• Почасовой тариф с учётом мощности (Четвертая ЦК): То же, что и третья категория, но дополнительно платите за пиковую нагрузку — чем равномернее потребляете, тем выгоднее
• Тариф с планированием (Пятая ЦК): Стоимость электроэнергии также меняется каждый час, но вы должны заранее сообщать план потребления на следующий месяц — если уложитесь в план, тариф может стать выгоднее
• Тариф с планированием и учётом мощности (Шестая ЦК): Как пятая категория, но с дополнительной платой за пиковую нагрузку

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

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

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

Выбор правильной ценовой категории для каждого объекта может дать экономию до 30% без изменения режима работы оборудования. Просто потому, что вы будете платить по более выгодному для вас тарифу.

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

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

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

Одной из десяти программ учета была наша, её мы внедрили несколько лет назад. Однако, в отличие от других, мы не просто собирали данные со счетчиков, но и показали значительную экономию от внедрения. В Архангельском филиале она достигла 12 млн рублей в год, в Псковско-Новгородском филиале — около 8-10 млн, а в Карелии — порядка 6-8 млн рублей.

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

Как мы делали единую систему: план и реальность
План был таким:

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

А в реальности…

Шаг 1: Анализ и подготовка (сентябрь 2023)
Первый этап занял больше года. Это заключение договора. Ростелеком — большая компания с множеством согласований. Нужно было выяснить, какие системы стоят в филиалах, какие счетчики установлены на объектах и как всю эту разнородную инфраструктуру соединить в одну систему.

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

Это как расследование, только с техническим уклоном. Нам нужно было понять, как работают чужие системы, чтобы потом аккуратно перенести всё в нашу.

Шаг 2: Разворачиваем систему на серверах (октябрь-декабрь 2023)
Тут начались первые сюрпризы. В обычных проектах мы просто заходим на сервер клиента и устанавливаем нашу систему. Но с Ростелекомом всё оказалось сложнее. Из-за повышенных требований по информационной безопасности работа сильно затянулась:

• Ограниченный доступ: нам выделили специальный VPN-канал для доступа к инфраструктуре, но прямого доступа к серверам не дали
• Учетные записи: для каждого нашего сотрудника создали отдельную учетную запись с фиксацией, с какого устройства он работает
• Документирование: мы готовили подробную документацию на каждого нашего сотрудника и какие действия он должен выполнять
• «Карантин»: наш установочный пакет проходил проверку службой безопасности в течение двух недель в специальной изолированной среде.

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

Также нам пришлось доработать интеграцию с Active Directory — службой каталогов Microsoft, которая у клиента используется для авторизации пользователей. Это позволило сотрудникам компании входить в нашу систему с теми же учетными данными, которые они используют для других корпоративных систем.

Шаг 3: Подключение счетчиков (январь-март 2024)
Обычно с переключением счетчиков, по которым уже налажен опрос, сложностей не возникает. Но сюрпризы нас поджидали и тут. Когда мы начали проверять сетевую доступность до счетчиков, выяснилось, что в разных филиалах есть счетчики с устройствами связи, IP-адреса которых совпадают. Такие пересечения возникли в силу того, что разные филиалы настраивают свои локальные сети независимо друг от друга.

Представьте, что у вас есть счетчик в Пскове и счетчик в Петрозаводске, для связи с которыми используется один и тот же IP-адрес 192.168.1.100. Если счетчики находятся в изолированных друг от друга сетях, то проблем не возникает. Мы же все счетчики стали объединять в единую сеть и обнаружили пересечения диапазонов IP-адресов, это приводило к конфликтам.

Казалось бы, есть очевидное решение — сменить сетевые адреса, чтобы они не совпадали, и все заработает без лишних хлопот. Но нет, сетевая инфраструктура нашего клиента формировалась исторически сложным путем. Раньше каждый региональный филиал был фактически отдельной компанией со своими стандартами и правилами настройки сетей. Когда все эти компании объединились под единым национальным брендом, их сетевые инфраструктуры просто «сшили» вместе, сохранив исходную адресацию. За годы в каждой из этих сетей накопилось множество разного оборудования — не только счетчики электроэнергии, но и системы связи, безопасности, управления. И все они были настроены на работу в определенных диапазонах IP-адресов.

Если мы станем менять адреса, то в результате может отвалиться какое-нибудь другое устройство, которое используется совсем для других целей, например, оборудование связи. Проблема усугубилась тем, что в некоторых филиалах никто не мог пояснить, как именно всё настроено — документация неполная, а инженеры, которые всё это создавали, давно сменились.

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

Мы спроектировали распределенную архитектуру, похожую на сеть почтовых отделений. В каждой подсети компании поставили свой сервер-сборщик, который общается только с устройствами в своей «зоне ответственности». Затем все собранные данные передаются на центральный сервер. При этом пользователь видит полную картину в едином интерфейсе — ему не нужно знать про всю эту сложную систему, он просто заходит в единый личный кабинет и получает все данные.



Это более сложная архитектура, чем мы изначально планировали, но она гораздо надежнее и масштабируемее. И самое главное — она решила проблему с пересекающимися IP-адресами.

Шаг 4: Перенос счетчиков и настройка отчетов (июнь-декабрь 2024)
Самый долгий и кропотливый этап. Нужно было перенести информацию обо всех точках измерения и счетчиках из старых систем в новую. И сделать это с учетом жестких требований Ростелекома: сохранить историю потребления за прошлые годы, обеспечить полностью бесшовный переход без потери данных для ежемесячной отчетности и ни в коем случае не прерывать процесс передачи почасовых показаний в энергосбытовые компании, чтобы не нарваться на претензии и штрафы.

Это как заменить двигатель в автомобиле, не останавливаясь в пути.

Процесс был таким:

• Выгружали данные из старой системы
• Дополняли недостающую информацию (часто в старых системах не хватало важных параметров)
• Приводили данные к единому формату
• Загружали в новую систему
• Проверяли корректность загрузки
• Перенастраивали оборудование на передачу данных в новую систему

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

Поэтому мы разработали план поэтапного перехода:

• Согласовывали с филиалом удобное время для перенастройки
• Подтверждали, что данные за прошлый месяц уже переданы
• Удаленно перенастраивали оборудование на передачу данных в новую систему
• Проверяли корректность сбора данных
• Обучали сотрудников филиала работе с новой системой отчетности

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

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

Теперь видно все объекты в едином интерфейсе. Центральный аппарат видит всю картину по предприятию, а инженеры филиалов — данные только по своему региону.

Первое, на что инженеры обращают внимание — это общая картина сбора данных. По сути, это диспетчерский экран, где сразу видно состояние всех объектов.



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

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

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


Остается только убедиться, что все отчеты были отправлены и получены поставщиками электроэнергии:


Шаг 5: Обучение пользователей (сентябрь 2024)
Когда система заработала, мы обучили команду Ростелекома ей пользоваться. Собрали более 60 сотрудников со всех филиалов на большой вебинар, а затем провели отдельные тренинги для энергетиков, инженеров и операторов — каждому объяснили его часть работы. Для особо любознательных филиалов проводим дополнительные вебинары с глубоким погружением в возможности системы.

Как теперь экономит Ростелеком
Самый ценный функционал системы — это анализ потребления и расчет оптимальных тарифов. Посмотрим, как это работает на конкретных примерах.

Пример 1: Сравнение тарифов и выбор оптимального


На этом скриншоте показано сравнение стоимости электроэнергии по всем возможным вариантам из тарифного меню одной энергосбытовой компании. Данный поставщик предлагает 5 вариантов расчета за электроэнергию, и система автоматически рассчитывает, сколько будет стоить один и тот же объем потребления (127 806 кВт) по разным тарифам:

• Выбрав первый вариант расчетов (I), компания должна оплатить 1,4 млн. руб. — это самый оптимальный вариант.
• Выбрав тарифы, дифферинцированные по зонам суток (2 зоны: день и ночь), за тот же объем компания заплатит 1,6 млн. руб. — дороже на 13%
• Переплата на почасовых тарифах (III и IV ЦК) составит 7% и 17%.

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

Пример 2: Расчет экономии при переходе с одного тарифа на другой
Этот пример показывает посуточный анализ затрат при переходе с IV ценовой категории на I ценовую категорию:


В таблице показаны детали расчета:

• В рабочие дни экономия составляет 0,5 млн руб или 32% в сравнении с текущим тарифом
• В нерабочие дни наблюдается переплата 0,2 млн. руб.
• Общая экономия за месяц: 0,3 млн. руб. или 17%

Графики демонстрируют ежедневную статистику по экономии:


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

Что в итоге получил Ростелеком?
Теперь вместо 10 разных систем у Ростелекома единая централизованная система учета электроэнергии, которая:

• Собирает данные с более чем 15 тысяч счетчиков, раскиданных по 32 регионам страны.
• Отслеживает проблемы передачи данных
• Контролирует качество электроэнергии — напряжение, частоту и другие параметры
• Предупреждает о критических ситуациях, если параметры электросети выходят за допустимые пределы
• Автоматически формирует и рассылает отчеты для энергосбытовых компаний
• Анализирует потребление и показывает, где можно оптимизировать затраты
• Выявляет ошибки в расчетах поставщиков электроэнергии

Экономический эффект внедрения системы в некоторых филиалах достигает 30% от первоначальных платежей за электроэнергию. При этом потребление не уменьшилось — наш клиент платит по оптимальным тарифам и за год экономит более 100 млн. руб.

Что особенного в этом проекте?
Для нас этот проект стал вызовом по нескольким причинам:

• Масштаб — 15 тысяч счетчиков, 32 региона, 10 разных систем
• Требования безопасности — каждое обновление проходило проверку в течение двух недель, и мы старались пройти проверку с первой попытки
• Сетевая инфраструктура — пришлось адаптировать нашу систему под сложную сетевую архитектуру Ростелекома
• Непрерывность сбора данных — нельзя было допустить сбоев в передаче показаний
• Работа с критической инфраструктурой — необходимость интеграции с системами, обеспечивающими безопасность сети

Масштабируемость решения — теперь наша система может расти практически без ограничений. При увеличении числа объектов достаточно добавить новые серверы-сборщики, что позволяет в перспективе обслуживать намного больше 15 тысяч точек учета без потери производительности.

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

И сделали это, просто правильно настроив учет электроэнергии и подобрав оптимальные тарифы.

Мораль этой истории
Даже если вы не можете снизить потребление электроэнергии (потому что оборудование должно работать 24/7), вы всё равно можете существенно сэкономить, если правильно выберете тариф и будете контролировать потребление.

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

Что ж, мы своё терпение проверили на практике — и оно не подвело. А наш клиент теперь экономит миллионы. Всем выгодно!

www.cloud.rt.ru

Хотите разобраться, как работает Docker и зачем он нужен?
Docker — это open source-платформа для создания контейнеров — окружений, где приложения работают независимо от ОС или среды. Технология упрощает перенос приложений между окружениями и ускоряет разработку.

В новом бесплатном курсе мы расскажем, с чего начать: как установить Docker, собрать образ, создать и запустить контейнер. Также познакомимся с Docker Compose и обсудим, чем Kubernetes отличается от Docker Swarm.

Несколько материалов для начала
Docker: что это такое и как работать с контейнерами
Объясняем, зачем нужен Docker, из чего состоит и как запустить свой первый контейнер.

Установка Docker Desktop на Windows, настройка WSL и Hyper-V
Показываем, как установить и настроить Docker на Windows 10/11. Рассказываем о требованиях к системе, настройке и запуске службы Docker.

Запуск контейнера Docker и команда docker run
Разбираемся, как запускать контейнеры и какие параметры важны при работе с docker run.

selectel.ru/blog/courses/docker-from-scratch/

Главный прикол с k8s: поднять базовый кластер займёт всего 15 минут. А вот чтобы он реально заработал, ответить на все вопросы перед установкой, всё спланировать — на это нужны дни, реально дни мозгового штурма и планирования. Ну или потом придётся разбирать и делать ещё раз. Несколько раз.

Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.

И вот про эти самые вопросы мы сейчас и поговорим, потому что там целое волшебное поле грабель.

Начнём с простых вещей, например, выбора дистрибутива, выбора способа хранения данных (и динамического выделения места), а также того, куда складывать пароли к критичным ресурсам. На этих трёх выборах ломается примерно 50 % админов.

Поехали в ад!



Архитектура

Kubernetes — это кластер. То есть много серверов, которые работают вместе. Эти серверы называются нодами, или узлами. Есть ноды управляющие (Control Plane). Раньше их звали Master, но сейчас это слово немодное, так что Control Plane. А есть ноды рабочие (Worker Nodes) — вот на них-то и крутятся ваши приложения в контейнерах (точнее, в подах).

Рядом с Control Plane живёт etcd. Это распределённая база данных (ключ-значение), где Кубер хранит всю инфу о себе и о том, что в нём запущено: какие поды, какие сервисы, какие конфиги — вот это всё. Она тоже обычно распределена по нескольким управляющим нодам для надёжности. Для полной надёжности её ставят отдельно.

Работает это так: вы пишете файл с конфигом, который описывает условия и состояния, например: «Хочу такой-то деплой из стольких-то подов, чтобы он при таких условиях вёл себя так, а при таких — вот так». Эти правила хранятся в etcd, а Control Plane следит за их исполнением. Если есть разница между тем, как надо, и тем, как есть, — всё приводится в нужное состояние. То есть что-то грохается или добавляется. Автоматически.

Казалось бы, всё просто, но тут огромная кроличья нора.

Дело — в условиях и работе приложений. Чтобы прописать нормальные условия для работы кластера, придётся вытащить наружу кучу метрик изнутри ваших приложений. Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий».

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

Вторая особенность — вам надо обеспечить правильное поведение приложения при добавлении-убавлении контейнеров. Это касается транзакций (надо корректно закрываться после обработки транзакции, а не терять её), записи на диск и так далее.

С диском — тоже отдельный сюрприз: мышление придётся изменить. Но давайте по порядку.

Если у вас планируется реально большой, нагруженный кластер, то Control Plane и особенно etcd лучше выносить на отдельные, выделенные ноды. Не надо на них вешать рабочую нагрузку, пусть они занимаются только управлением. У себя на деве или стейдже мы можем и совмещать, чтобы экономить ресурсы, но на проде лучше делить. В наших собственных продуктах на dev-части мы совмещаем узлы, а на прод-части создаём два отдельных контура.

Почему это проблема?



Потому что это унижает человеческое достоинство. Просто знайте: то, что у вас поначалу не всё получается, — это нормально. Это часть процесса. Так задумано. Вот как сталкивались с этим наши участники команды разработки:

• Начинаешь с Kubernetes — вроде всё понятно по верхам, курс прошёл, потыкал. Гугл и AI помогают. Но потом лезешь глубже: драйверы для хранилищ, autoprovisioning, сети… и это просто стена! Понять базово — это одно, а настроить под себя — совсем другое. Нужны или огромный опыт, или куча времени, чтобы просто сидеть и ковыряться. Настроить выход наружу? Тоже целая история с кучей нюансов: часто просто копируешь решения, не до конца понимая.
• Написать код — быстро. А вот развернуть его в Кубере первый раз — это дни мучений! Сертификаты, связь между сервисами, настройка Argo CD с ключами — всё совершенно неинтуитивно. Если рядом нет опытного DevOps, который проведёт за ручку, то это просто взрыв мозга и боль: не понимаешь, за что страдаешь! Но когда наконец всё настроишь, думаешь: «Боже, как же хорошо! Теперь только так и буду работать! Только, пожалуйста, пусть кто-нибудь другой развернёт сам Кубер, я этого больше не хочу!»
• Пытаешься соединить внутренние сервисы Кубера с внешним миром — и тут начинаются танцы с бубном. Куча технологий, и все — на разной стадии готовности.
• Самое сложное в начале — просто понять, как вообще работать с Kubernetes. У тебя не запускается простой сайт в Docker-контейнере, а DevOps объясняет проблему терминами Кубера, и ты даже не понимаешь, как это отладить, куда смотреть. Потом тебе дают конфиг для kubectl и говорят: «Разбирайся сам». Ощущение, будто тебя выкинули с лодки посреди озера: плыви!

Что ставить
Это классика жанра для новичка. Открываешь доку Кубера, а там бац — десяток способов установки! И хрен поймёшь, какой тебе нужен.

Дальше можно гуглить «Kubernetes Hard Way» и «Kubernetes Simple Way»: там статьи разной степени упоротости. Поскольку на дворе — XXI век, можно попросить помочь и LLM, но это будет step-by-step-воспроизведение одной из этих двух инструкций.

Третий путь — пойти к облачному провайдеру и там найти managed-service для k8s, обычно выглядящий для пользователя как волшебная кнопка «Создать кластер Kubernetes». Жмакнули, подождали минут 10–15, и вам вываливается файлик с конфигом. А дальше наступает ступор. Смотрите на этот файлик и думаете: «Ну зашибись, а дальше-то что?»

Мой личный совет: прежде чем лезть в облака или мучиться со своими серверами, поставьте себе на ноут Minikube. Это такая песочница, маленький Кубер на одной машине. Погоняйте его, потыкайте палочкой, разберитесь с базовыми понятиями: что такое Pod, Service, Deployment — вот это всё. Освойте kubectl — это главная команда для общения с кластером. Вот когда вы через это пройдёте, тогда и Managed Service в облаке станет в разы понятнее, и вы будете знать, что делать с этим загадочным admin.conf.

Итак, вариантов три с половиной:

• Managed Service в облаке (типа нашего H3LLO CLOUD) — это когда вы приходите к провайдеру, говорите: «Хочу Кубер», нажимаете пару кнопок (ну или не пару: всё зависит от упоротости провайдера), получая готовый кластер и kubeconfig. Плюсы: не надо париться с установкой и обновлением управляющих нод (Control Plane, etcd): всё это — головная боль провайдера. Масштабирование нод — часто «из коробки»: настроил правило, и если нагрузка растёт, то провайдер сам добавит виртуалок в ваш кластер. Автоматическое выделение persistent volume любого размера в любом количестве — тоже на провайдере, как и LoadBalancer для внешнего доступа. Минусы: зависимость от провайдера, его ограничений (про них ещё скажу) и его ценовой политики.
• На своих серверах (Bare Metal) или своих виртуалках. Полный контроль над железом, над софтом, над настройками. Делайте что хотите. Но на вас падает вся сложность установки, настройки, обновлений, бэкапов. Масштабировать кластер новыми серверами? Только ручками: пошёл, купил сервер, поставил в стойку, настроил, добавил в кластер. Никакой магии.
• Руками в облаке на виртуалках: можно, но зачем? Если очень хочется поковыряться в кишках, но своего железа нет. Или если Managed-сервис чем-то критично не устраивает (например, версией Кубера или доступными опциями). По сути, это то же самое, что и Bare Metal, только серверы арендованные. Вся сложность — ваша, но хотя бы серверы покупать не надо.

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

Как ставить

• Kubeadm — официальная утилита от создателей Кубера. Но это, как я говорю, «путь самурая». Все команды — ручками, все конфиги — ручками, бутстрэп каждой ноды — ручками. Если вы не мазохист и ставите Кубер первый раз — не советую категорически: намучаетесь и проклянёте всё на свете.
• Kubespray — это наш выбор для своих инсталляций на железе или виртуалках. Это, по сути, набор готовых Ansible-сценариев. Он автоматизирует 90 % рутины по развёртыванию кластера на куче нод. Есть неплохие статьи, как его подготовить и запустить. Очень рекомендую начинать именно с него, если вы решили ставить сами и уже выросли из Minikube. Очевидный плюс — в дальнейшем удачный конфиг можно многократно воспроизвести.
• Экзотика — есть и другие штуки, часто привязанные к специфичным ОС. Например, для Talos OS есть свои утилиты — Talos CTL (ручками) и talm (типа Helm, но для Талоса). Интересные вещи, но это уже для тех, кто в теме.

На какую ОС ставить ноды

• Есть обычные Linux — старая добрая Ubuntu, CentOS, Debian, и всё это прекрасно работает. Привычно, понятно, куча доков в сети.
• Специализированные ОС — есть дистрибутивы, заточенные специально под контейнеры и Кубер. Это Fedora CoreOS / Flatcar Container Linux: часто у них read-only — корневая файловая система для безопасности, атомарные обновления. Но есть нюансы: например, FCOS вместо привычного cloud-init использует свой формат конфигов — Ignition. Надо разбираться, как его готовить (там есть ещё утилита Butane). Talos — ещё более хардкорный вариант. Там вообще нет привычной ОС с shell! Всё управляется через API. Максимальная безопасность, минимализм. Но требует полного переосмысления подхода к управлению хостами.

Если нет особых требований к безопасности или специфике, то начинайте с обычной Ubuntu LTS — не ошибётесь.

Container Runtime

• Docker (точнее, dockershim) — до недавнего времени был стандартом де-факто. Сейчас его официально выпилили из Кубера, но многие дистрибутивы и инсталляторы по-прежнему его поддерживают через прослойку. Если у вас нет веских причин для другого — можно начать с него: он самый привычный.
• Containerd — а вот это стандарт де-факто сейчас, поддерживаемый Кубером напрямую через интерфейс Container Runtime Interface. Кстати, Docker сам под капотом использует containerd, так что переход на него обычно безболезненный. Большинство новых инсталляций использует именно его.
• CRI-O — ещё реализация CRI, разрабатываемая Red Hat. Тоже хороший вариант.
• Есть и совсем специфичные вещи типа Kata Containers (запускает контейнеры в легковесных виртуалках для изоляции) или Kubevirt (позволяет запускать полноценные ВМ внутри Кубера). Но это уже для особых случаев.

Рекомендация: начинайте с containerd. Это сейчас мейнстрим.

Хранение
Вот это критически важный вопрос, если у вас не только stateless-вебморды, но и базы данных, очереди, кэши — всё, что должно переживать перезапуск и падение подов.

Сразу забудьте про использование локальных дисков на нодах для хранения важных данных в продакшене! Нода умерла — данные пропали.

То есть данные должны быть размазаны по кластеру или храниться в выделенном отдельном хранилище.

Кубер для работы с хранилищами использует стандартный интерфейс Container Storage Interface. Это позволяет подключать к нему самые разные системы хранения данных — как локальные, так и сетевые.

Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище. Наш опыт показывает, что это отличный выбор. Его можно развернуть отдельно, а можно прямо внутри Кубера с помощью специального оператора Rook. Rook сам поднимает все компоненты Ceph (мониторы, OSD на дисках нод) в виде подов и делает его доступным для Кубера через CSI. Мы у себя часто используем именно связку Ceph + Rook.

Всё это работает так. У вас есть приложение, работающее в контейнере внутри Kubernetes K8s. Этому приложению, например, базе данных, нужно место для хранения данных — скажем, пять гигабайт. Создаётся PVC (Persistent Volume Claim). Это как заявка на диск. Кубер понимает запрос и обращается к системе хранения данных (например, Ceph) через autoprovisioning с командой: «Создай диск на пять гигабайт». В Ceph создаётся блочный диск (RBD) и выделяется Куберу в виде его сущности PV (Persistent Volume). И уже этот PV подключается к поду.

Ceph — это распределённая система хранения, которая обычно устанавливается на те же серверы (узлы), где работают и сами контейнеры (сейчас мы — про Bare Metal). Она объединяет диски этих серверов в единое большое хранилище.

Хотя компоненты Ceph (например, процессы, управляющие отдельными дисками — OSD) могут запускаться в своих управляющих контейнерах (часто — с помощью инструмента Rook), сама система хранения тесно связана с физическими дисками и серверами. Когда контейнер падает, диск в Ceph остаётся. Когда падает целый сервер, данные сохраняются. Система не хранит всех данных на одном диске или узле: при записи копии данных «размазываются» по разным дискам на разных серверах. Мы сами выбираем, какой уровень репликации установить. Ceph автоматически обнаружит потерю OSD и начнёт перераспределять данные по оставшимся рабочим дискам, чтобы восстановить нужный уровень избыточности.

Если контейнер поднимется на другой машине после перезапуска, то новый экземпляр контейнера просто подключится к тому же самому постоянному тому (Persistent Volume), который был создан для него в Ceph. Данные на диске никуда не делись. Управление самим кластером Ceph — тоже отказоустойчиво. Есть специальные процессы-мониторы и манагер с репликами в режиме standby. Если сервер с главным манагером выходит из строя, то управление автоматически переходит к другому манагеру на другом сервере.

Конечно, система не неуязвима. Если выйдет из строя слишком много серверов или дисков одновременно, так, что оставшегося места не хватит для хранения всех данных или их реплик, или если не останется достаточно узлов для поддержания кворума управления кластером, то Ceph может перестать работать или перейти в состояние «Только для чтения». Там лучше разбираться руками.

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

Ещё варианты:

• LinStor — ещё одно распределённое хранилище, и тоже с CSI-драйвером. Говорят, может быть производительнее Ceph в некоторых сценариях. Тоже достойный вариант.
• Если вы в облаке, то у провайдера есть свои CSI-драйверы для их блочных хранилищ (Amazon EBS, Google Persistent Disk, Azure Disk, etc.). Обычно это самый простой вариант в облаке. Причём их можно смешивать для разных условий и для разных типов данных.
• Более экзотичные GlusterFS, локальные диски через Local Persistent Volumes (только для специфичных задач!) и куча других вариантов.

Вы можете определить разные «классы» хранения (StorageClass), например, fast-ssd, slow-hdd, cloud-premium. А потом в манифесте для вашего приложения (в PersistentVolumeClaim) вы просто указываете имя нужного класса. Кубер через CSI-драйвер сам создаст диск нужного типа в соответствующем бэкенде (Ceph, облако, etc.). Это позволяет абстрагироваться от конкретной реализации хранилища.



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

Kubernetes создаёт свою собственную виртуальную сеть поверх вашей физической (или облачной) сети. Каждый под (контейнер) получает свой IP-адрес в этой виртуальной сети. И поды, запущенные на разных физических нодах, должны иметь возможность общаться друг с другом по этим виртуальным IP. Чтобы эта магия работала, нужно выбрать и установить CNI-плагин (Container Network Interface). Это такой софт, который и отвечает за настройку сети для подов. Наши фавориты:

• Cilium — очень мощный и быстрый плагин. Он использует новомодную eBPF прямо в ядре Linux, что даёт ему производительность и кучу фич (сетевые политики, шифрование, балансировка). У Cilium есть ещё крутой инструмент Hubble — это UI и CLI для визуализации сетевых потоков и зависимостей между сервисами. Супервещь для отладки, мы его любим.
• Calico — тоже очень популярный и зрелый плагин. Часто идёт по умолчанию во многих инсталляторах (например, в Kubespray). Умеет работать как с оверлейными сетями (VXLAN, IPIP), так и без оверлея, используя BGP-маршрутизацию, если ваша сеть это поддерживает. Тоже отличный выбор.
• Flannel (простой, для начала неплох).
• Weave Net, Antrea и куча других, в том числе специфичных для облаков (AWS VPC CNI, Azure CNI, GKE Netd).

В зависимости от выбранного CNI и вашей инфраструктуры вам может потребоваться разбираться с BGP, VXLAN, IPIP-туннелями, настройкой маршрутов и файрволов. Сеть — это то место, где можно застрять надолго. Как сказал один наш сетевик, когда разбирался с какой-то проблемой: «По идее должно быть так, но хрен его знает, иди копай». Эта фраза будет преследовать вас примерно везде по мере реализации.

«Я запустил Nginx в поде, как мне его открыть в браузере?»

В Кубере есть специальная штука — Service. Это абстракция, которая даёт постоянный IP-адрес и DNS-имя для группы подов (например, для всех реплик вашего веб-сервера) и умеет балансировать трафик между ними.

Типы сервисов:

• ClusterIP: сервис получает внутренний IP, доступный только изнутри кластера. Для внутренних бэкендов — самое то.
• NodePort: сервис открывает порт на каждой ноде кластера. Вы можете обратиться на IP_любой_ноды:NodePort и попасть на сервис. Неудобно, небезопасно, порты надо выбирать из определённого диапазона. Для продакшена — фу.
• LoadBalancer: вот это уже интереснее. Если вы в облаке, то при создании сервиса такого типа облачный провайдер автоматически создаёт вам внешний облачный балансировщик (ELB, Google LB, etc.), назначает ему публичный IP и направляет трафик на ваш сервис (точнее, на его NodePort на нодах). Очень удобно! А что делать, если у вас свой кластер на железе (Bare Metal)? Облачного балансировщика нет. Тут на помощь приходит MetalLB. Это такой специальный контроллер, который эмулирует облачный LoadBalancer. Вы выделяете ему пул IP-адресов из вашей локальной или публичной сети (если вы крутой и имеете свою публичную сеть), и когда создаёте сервис типа LoadBalancer, MetalLB берёт свободный IP из пула и «анонсирует» его в вашей сети (обычно через ARP или BGP), чтобы трафик на этот IP приходил на ноды вашего кластера. Обязательная штука для Bare Metal!
• Есть еще ExternalName, который использует DNS с кастомными параметрами, но даже в официальной доке предупреждают, что для некоторых протоколов типа http(s) могут быть проблемы. Мы его не используем.

Ingress — стандарт для публикации веб-приложений (HTTP/HTTPS) в продакшене. Ingress — это не тип сервиса, это отдельный ресурс в Кубере. Он работает как умный реверс-прокси или «входные ворота» для внешнего трафика. Он позволяет рулить трафиком на разные сервисы внутри кластера на основе хоста (например, api.mysite.com -> сервис API, blog.mysite.com -> сервис блога) или пути (mysite.com/app1 -> сервис App1, mysite.com/app2 -> сервис App2). Ingress также обычно отвечает за TLS-терминацию (SSL-сертификаты).

Чтобы Ingress заработал, вам нужно установить Ingress-контроллер. Это, по сути, и есть тот самый реверс-прокси, который читает Ingress-ресурсы и настраивает себя соответствующим образом. Самый популярный — Nginx Ingress Controller: знакомый многим Nginx, но специально заточенный под Кубер. Мощный, гибкий. Но! Будьте осторожны: недавно в нём находили неприятные уязвимости, позволяющие читать секреты из кластера. Это к важности своевременных апдейтов. Из других хороши HAProxy Ingress, Traefik (очень популярен, умеет сам получать Let's Encrypt-сертификаты), Contour и другие.

Настроить Ingress, сертификаты, DNS — это тоже задача не на пять минут. А если обратиться к официальной документации, то она рекомендует идти не в Ingress, а в Gateway API. Тут может показаться, что надо начать с него, и даже есть классные GUI для Gateway API, и хорошо бы ими воспользоваться! Но погодите )

Gateway API — это относительно новая спецификация в Кубере, которая со временем должна заменить или дополнить Ingress. Она более гибкая, позволяет разделять ответственность по маршрутам для разработчиков. Выглядит перспективно. Но я бы пока советовал не лезть в экзотику типа Kong Gateway. Да, у него есть красивый UI, что подкупает в мире консольного Кубера. Но он ломает саму идеологию Кубера с его декларативными манифестами в etcd и использует другую логику представлений. Лучше освоить стандартный Ingress с Nginx или Traefik, а к Gateway API присматриваться постепенно по мере накопления опыта. Есть реализации на базе того же Nginx, Envoy (Istio, Contour), HAProxy. Если разбираться с Gateway API, то лучше начать с них.

Кусок информационной безопасности
Пароли от баз данных, ключи к внешним API, всякие токены — ни в коем случае нельзя хардкодить в коде приложения (если кто-то ещё так делает и не был распят) или пихать прямо в YAML-манифесты! Этим вы создаёте огромную дыру в безопасности.

Для этого в Кубере есть специальные объекты:

• Secrets — для хранения чувствительных данных (пароли, токены, TLS-сертификаты). Они хранятся в etcd в base64 (что не шифрование!), но Кубер предоставляет механизмы для их шифрования «at rest» и контроля доступа к ним через RBAC.
• ConfigMaps — для хранения нечувствительной информации конфигурации (URL’ы, параметры, конфиг-файлы целиком).
• Продвинутый уровень: можно интегрировать Кубер с внешними системами управления секретами, например, HashiCorp Vault, с помощью специальных инструментов (Vault Agent Injector, External Secrets Operator). Это даёт централизованное управление, ротацию секретов и т.д.

Вы можете «подсунуть» данные из Secrets и ConfigMaps вашему приложению как переменные окружения для контейнера или как файлы, смонтированные в определённую директорию внутри контейнера.

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

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

Аутентификация и авторизация
В вашем кластере наверняка будут работать разные люди: DevOps/SRE, разработчики команды А, разработчики команды Б, может быть, QA-инженеры… Кто может деплоить приложения, кто может смотреть секреты, кто может удалять ноды?

• Аутентификация. Сертификаты X.509, токены (статичные, JWT, через OIDC-провайдера типа Keycloak или Dex), интеграция с LDAP/AD.
• Авторизация (RBAC — Role-Based Access Control). Вот это — самое главное. RBAC позволяет очень гибко настроить, что (какие действия: get, list, create, update, delete) с какими ресурсами (pods, services, secrets, nodes, etc.) в каких неймспейсах (или во всём кластере) и кто может делать (какой пользователь, группа или сервисный аккаунт). Вы создаёте Роли (Roles) или Кластерные Роли (ClusterRoles), где описываете набор разрешений. Затем вы создаёте Привязки Ролей (RoleBindings) или Кластерные Привязки (ClusterRoleBindings), чтобы связать роль с конкретным пользователем, группой или сервисным аккаунтом.
• Namespaces: используйте неймспейсы для логической изоляции ресурсов разных команд, проектов или окружений (dev, stage, prod). Это помогает упорядочить кластер и упрощает настройку RBAC (роли можно создавать внутри неймспейса). Хотя для окружений более правильно и эффективно использовать разные кластеры (опять же привет, облака).
• Золотое правило — минимальные привилегии. Давайте пользователям и сервисным аккаунтам только те права, которые им реально необходимы для выполнения их задач. Не надо всем раздавать cluster-admin: это прямой путь к катастрофе.

Observability
Вот мы и приехали к той самой волшебной части. Работать с кластером Kubernetes без настроенной системы мониторинга и логирования — это посадить админом слепого котёнка.

Метрики:

• Нужен Metrics Server — это базовый компонент (обычно ставится аддоном), который собирает основные метрики использования ресурсов (CPU, RAM) с нод и подов. Он нужен как минимум для работы kubectl top и базового HPA.
• Стек Prometheus + Grafana — это де-факто стандарт для сбора, хранения и визуализации метрик в мире Кубера. Prometheus — это база данных временных рядов, которая сама опрашивает метрики с разных источников (ноды, поды, сервисы). Grafana — инструмент для построения красивых дашбордов на основе данных из Prometheus (и не только).
• Приложения должны сами отдавать метрики в формате, понятном Prometheus (обычно это текстовый формат по HTTP-эндпоинту /metrics). Не только CPU/RAM, но и специфичные для приложения: количество запросов в секунду, время ответа, размер очереди, количество ошибок, бизнес-метрики. Без этого ваш мониторинг будет неполным.

А я предупреждал )

Логи:

• Контейнеры в Кубере обычно пишут логи просто в stdout и stderr. Эти логи собираются движком контейнеров (containerd/docker) и доступны через kubectl logs. Но смотреть логи каждого пода по отдельности — это ад.
• Нужен централизованный сбор логов. Необходимо настроить агентов (например, Fluentd, Fluent Bit, Promtail), которые будут бегать на каждой ноде, собирать логи из файлов или напрямую от движка контейнеров и отправлять их в центральное хранилище.
• Популярные варианты хранилищ логов — Elasticsearch (в составе стека ELK/EFK: Elasticsearch + Logstash/Fluentd + Kibana) или Loki (от создателей Grafana, хорошо интегрируется с Prometheus, обычно используется в стеке LGTM: Loki + Grafana + Promtail).

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

Трассировка. Если у вас микросервисная архитектура, то один запрос пользователя может проходить через десяток разных сервисов. Чтобы понять, где именно возникла задержка или ошибка, нужна распределённая трассировка. Инструменты: Jaeger, Zipkin, Tempo.

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

Масштабирование
Ну что, база есть, доступ настроен, всё видно. Теперь можно и фишками обмазаться.

Устали поднимать руками и настраивать PostgreSQL, Kafka, Redis, Elasticsearch в Кубере? Следить за их состоянием, бэкапами, обновлениями? Для этого придумали операторов. Оператор — это, по сути, ваш кастомный контроллер внутри Кубера, который знает, как управлять определённым типом сложного приложения. Он расширяет API Кубера с помощью Custom Resource Definitions.

Работает это так:

• Вы устанавливаете CRD для, скажем, PostgreSQL. Теперь Кубер знает о новом типе ресурса, например, PostgresCluster.
• Вы устанавливаете сам Оператор PostgreSQL (это обычное приложение, работающее в поде).
• Вы создаёте простой YAML-файл, где пишете — kind: PostgresCluster, name: my-db, spec: { replicas: 3, version: «15», storage: «fast-ssd» }.
• Применяете этот YAML (kubectl apply-f).
• Оператор видит, что вы создали новый ресурс PostgresCluster, и начинает действовать: создаёт нужные StatefulSets/Deployments, заказывает диски (PersistentVolumeClaims) нужного StorageClass, настраивает сервисы для доступа, конфигурирует репликацию, может настроить бэкапы и мониторинг — в общем, делает за вас всю грязную работу по развёртыванию и поддержке сложного stateful-приложения.

Существует огромное количество готовых операторов от сообщества и вендоров для баз данных, очередей, мониторинга, CI/CD — да чего угодно! Это очень мощный механизм расширения Кубера. Для совсем уж специфичных внутренних систем можно даже написать свой оператор (но это уже высший пилотаж).

Автомасштабирование — одна из главных фишек Кубера, ради которой его часто и внедряют.

• Горизонтальное автомасштабирование подов (HPA — Horizontal Pod Autoscaler) — самый частый и полезный вид. Вы создаёте HPA-ресурс и говорите: «Хочу, чтобы количество реплик моего приложения my-app было от двух до десяти, и чтобы оно масштабировалось, если средняя загрузка CPU по подам превысит 70 % (или RAM, или кастомная метрика из Prometheus, например, длина очереди)». Кубернейтс сам будет следить за метриками и автоматически добавлять или удалять поды my-app в указанных пределах.
• Вертикальное автомасштабирование подов (VPA — Vertical Pod Autoscaler). Менее популярный, но тоже бывает полезен. VPA анализирует реальное потребление ресурсов подами и может автоматически изменять requests и limits по CPU/RAM в манифесте пода. Чаще используется в режиме «рекомендаций», чтобы понять, сколько ресурсов реально нужно приложению. Использовать VPA вместе с HPA нужно осторожно: они могут конфликтовать.
• Масштабирование кластера (Cluster Autoscaler). Это уже про добавление и удаление целых серверов (нод) в кластер. Работает так: если в кластере появляются поды, которые не могут никуда запланироваться (состояние Pending) из-за нехватки ресурсов (CPU, RAM) на существующих нодах, то Cluster Autoscaler замечает это и автоматически заказывает у облачного провайдера новую ноду (или несколько), ждёт, пока она не поднимется, и добавляет её в кластер. Поды тут же планируются на неё. И наоборот: если Cluster Autoscaler видит, что какие-то ноды долгое время недозагружены и все их поды можно переместить на другие ноды, то он может автоматически удалить эти лишние ноды, чтобы сэкономить деньги. Это главная фишка облачных Managed Kubernetes. Там это обычно работает «из коробки». Если у вас свой кластер — на железе или виртуалках, то заставить Cluster Autoscaler работать можно, но сложнее. Нужно использовать Cluster API. Это такой проект, который позволяет управлять жизненным циклом кластеров Kubernetes (в том числе создавать и удалять ноды) с помощью самого Kubernetes. Cluster API имеет провайдеров для разных инфраструктур (vSphere, OpenStack, AWS, Azure, Bare Metal через Tinkerbell/MAAS). Но это отдельная большая тема.

Кстати, тут надо передать пламенный привет некоторым российским облакам. У них часто есть довольно смешные лимиты на максимальное количество нод в одном Managed-кластере: где-то — 100 (привет, ТаймВеб), где-то — вообще 32 (Яндекс). А Кубер, на минуточку, сам по себе спокойно тянет 5 000 нод в кластере и 150 тысяч подов и даже не поперхнётся (по официальным тестам). У ВК вроде лимит побольше — 500 нод, у Сбера — 249 (хотя в доке пишут, что 500). Всё равно не 5 000. У нас в H3LLO CLOUD мы постарались эту проблему решить и даём возможность строить реально большие кластеры, близкие к максимальным возможностям Кубера.


Думаете, это конец?
Нет, это начало.

Развернули кластер, настроили сеть, сторадж, мониторинг? Поздравляю! Вы прошли… ну, скажем, разминку.

• Короткий анонс. Приложения должны быть готовыми жить в динамичной эфемерной среде Кубера. Почитайте про 12-factor app — это мастхэв. Приложение должно:
• Читать конфиги и секреты из окружения или файлов (никаких локальных config.xml!).
• Писать логи в stdout/stderr (а не в файлы!).
• Быть максимально stateless (состояние хранить во внешних базах, кэшах, хранилищах).
• Быстро стартовать.
• Корректно обрабатывать сигналы SIGTERM для graceful shutdown.
• Уметь отдавать метрики для мониторинга (health checks, readiness/liveness probes).
• Быть упаковано в легковесный Docker-образ.

Вам нужны конвейеры, которые будут автоматически:

• Собирать Docker-образы вашего приложения при коммите в Git.
• Пушить образы в Docker Registry (типа Harbor, GitLab Registry, Docker Hub).
• Обновлять YAML-манифесты (Deployments, StatefulSets, Services, Ingresses) с новой версией образа.
• Деплоить эти манифесты в Kubernetes (например, с помощью kubectl apply, Helm, Argo CD, Flux).
• Проводить тесты после деплоя.
• Обеспечивать лёгкий откат на предыдущую версию.

Инструментов для этого — море: Jenkins, GitLab CI, GitHub Actions, Tekton, Argo CD, Flux…

В идеальном розовом мире единорогов ваши разработчики вообще не должны знать слова «Kubernetes». Они просто пишут код, коммитят в Git, а дальше некая «платформа» сама всё собирает, тестирует и выкатывает куда надо. Нажал кнопку — получил фичу в проде. Достичь такого уровня абстракции — это Грааль платформенного инжиниринга. Это требует не только зрелого Кубера со всеми обвесами, но и глубокого понимания ваших приложений, процессов разработки и кучи инструментов поверх Кубера (часто это называют Internal Developer Platform). Это долгий и сложный путь.

А оно вообще того стоит? Если у вас реально сложная, большая, динамичная система, которая должна быть отказоустойчивой, масштабироваться под нагрузкой, часто обновляться без простоя, то однозначно — ДА, стоит. Головной боли на старте будет много, но потом вы получите такие гибкость, скорость и надёжность, которых другими путями добиться очень сложно, если вообще возможно. Вы реально сможете выкатывать фичи быстрее и спать спокойнее (но это неточно).

Если вы прочитали всё это и подумали: «Мама дорогая, да я в этом никогда не разберусь!», но при этом фишки Кубера вам нужны — не отчаивайтесь. Есть решения, которые берут на себя большую часть этой боли:

• L1VESTACK или другой контейнерный хостинг — тут мы пошли по пути максимального упрощения: полностью спрятали оркестратор под капот. Вы просто даёте нам свой docker-compose.yaml (да-да, прямо его!) или используете наш простой CLI — и ваше приложение магическим образом разворачивается и работает на нашей инфраструктуре. Вообще не надо думать ни про ноды, ни про сети, ни про стораджи, ни про Ингрессы, ни про RBAC. Просто код и деплой. Идеально для тех, кто хочет «просто чтобы работало». Естественно, нет фишек инфраструктуры для продвинутых, потому что вы запустили контейнер, который работает.
• H3LLO.CLOUD — на нашей платформе есть Managed Kubernetes. Здесь мы не прячем Кубер полностью, но берём на себя самую нудную и сложную часть: бутстреппинг, Control Plane, etcd, обновления базовой системы, обеспечение работы сети и хранилища, предоставляем автомасштабирование нод «из коробки». Вам всё ещё нужно понимать основные концепции Кубера (поды, сервисы, деплойменты) и уметь пользоваться kubectl, но основную инфраструктурную рутину и сложность мы снимаем. Это хороший баланс между контролем и удобством.

Что почитать или посмотреть

• Для старта — Minikube.
• Запуск Кубера без заморочек — kubespray.
• Концепции Кубера из первоисточника — курим доку. Начать лучше с туториала, а потом читать Concepts и Tasks.
• Хорошая книга — Production Kubernetes. Есть на русском.
• Глубже по сетям — Networking and Kubernetes.
• Тоже есть на русском.
• GUI для Кубера — Lens
• The Twelve-Factor App

Жирнющие бесплтаные лимиты на облачные сервисы на целый год, включая Managed Kubernetes — H3LLO.CLOUD.

Не менее щедрые лимиты на платформу для запуска приложений в контейнере — L1veStack.

beta.h3llo.cloud
h3llo.cloud

В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.

Я откидываюсь в кресле, беру наушники и смотрю, как работает LLM. Можно сразу несколько, работающих над разными частями проекта:


Пример проекта с прикручиванием аналитики к инфраструктуре:

• Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
• Попросил превратить это в архитектурный план.
• Отревьюил, поправил тупые ошибки.
• Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
• Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
• Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
• Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
• Написал манифесты для Kubernetes и Docker Compose для локального запуска.
• Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

И всё.

А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами.
Качество LLM-кодинга сильно зависит от языка программирования
Главная проблема — объём блока (точнее, зависимостей) и нормальная обучающая выборка.

Scala
Попытки написать на Scala работающий микросервис по OpenAPI-спецификации провалились.

Модель генерирует код, он не компилируется. Скармливаешь ошибки компиляции — следующая итерация кода содержит ещё больше ошибок.

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

Попытки транслировать код с другого языка (например, с Go) в Scala тоже могут быть проблематичны, особенно если требуется сохранить функциональный стиль Scala — на понятиях PHP, например, такое просто не опишешь.

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

Golang
Совершенно другая история. Современные модели генерят на Go очень хороший, часто компилирующийся из коробки код. Скорее всего, работает комбинация факторов:

• Go — очень квадратно-гнездовой язык. Задачу чаще всего можно решить одним, максимум двумя способами. Нет такого разброса стилей и подходов, как в Scala или даже JS. Это упрощает обучение для LLM: меньше вариативность «правильных» ответов на один и тот же запрос. Эта прямолинейность отличается от C, который хотя и прост на первый взгляд, как автомат Калашникова, но позволяет легко «провалиться» на низкий уровень, иногда незаметно. Go тоже позволяет уйти в сторону ассемблера, но при решении стандартных задач он очень явно описывает путь.
• Строгая стандартизация. Встроенный форматер (gofmt), линтеры (golint), общепринятые конвенции — всё это делает кодовую базу на Go очень однородной. Это лучше, чем в Python, где тоже есть линтеры, но вариативности в написании больше. В Go сама идея языка была в том, чтобы код легко читался всей командой.
• Качественная и большая обучающая выборка. Огромное количество успешного Open Source написано на Go (Kubernetes и вся его экосистема, Docker, Prometheus, Terraform и т.д.). Вероятно, этот код использовался для обучения моделей с высоким весом, возможно, даже с усилением (как если бы Википедию добавили в базу 10 раз).
• Меньше «говнокода». Возможно, Go — язык более молодой, его чаще выбирают уже более опытные разработчики для серьёзных проектов (это сейчас слабое допущение). В отличие от Python или JS, куда порог входа ниже и больше новичков, генерирующих код не самого высокого качества, который тоже попадает в обучающие выборки. Плюс сам язык Go меньше прощает ошибок и не провоцирует написание «кривого» кода так, как это делает, например, JS. Сам язык как бы «не предусматривает» говнокода в той же мере.
• Почему мы сами выбрали Go — бинарники маленькие, памяти ест мало, работает быстро. Хотя и PHP последних версий тоже компилируется, но это отдельный спор. До сих пор, кстати, не утих другой холивар — можно ли считать PHP языком программирования или нет. Я придерживаюсь мнения, что можно. Но пишем мы преимущественно на Go.

Rust
Тоже хайповый современный язык. LLM генерят код, который проходит проверку синтаксиса в IDE. Но при попытке сборки (которая в Rust сложнее, чем в Go) вылезает куча ошибок. И вот с исправлением этих ошибок сборки LLM справляются хуже, чем с написанием изначального кода или исправлением ошибок в Go. Вероятно, дело опять же в сложности языка и, возможно, пока ещё менее репрезентативной выборке кода с решёнными проблемами сборки.
Экспериментировали мы не очень много.

Java
Самая интересная ситуация, показывающая принципы LLM-кодинга.
Проблема — в структуре типичного Java-проекта: там везде глубокая вложенность пакетов, сложные цепочки наследования. Чтобы понять, что происходит в одной функции, LLM нужно проанализировать много связанного кода.
Это требует огромного окна контекста: меньше 64к токенов — почти бесполезно для серьёзного Java-кодинга. К счастью, модели с большими окнами появились.
Ещё нужны агенты для исследования кодовой базы. Инструменты вроде Cursor, Cline позволяют LLM «ходить» по проекту. Но и тут проблема: системный промпт агента (который сам по себе может быть большим, на тысячи токенов), прочитанные файлы классов и интерфейсов, дерево проекта — всё это быстро забивает даже большое окно контекста, особенно учитывая, что в Java много мелких лексем (точки, скобки), каждая из которых — токен.
То есть сама структура проектов на Java такая, что нужно не только смотреть тот блок, где сейчас идёт редактирование, но и держать «в голове» вообще всё то, что происходит в зависимостях. Это, кстати, причина тех самых мемов про состояние потока программиста. Вот у LLM то же самое.

Идеальное решение (которого пока нет в массовом использовании) — агенты, способные хранить состояние проекта в долговременной памяти, а не только в текущем окне контекста. Тогда LLM сможет «помнить» всю структуру и историю изменений. Сейчас же каждый новый агент начинает почти с нуля.
Сравните с Go: там часто достаточно контекста одного файла + импортов, чтобы понять, что происходит. Добавьте нашему вымышленному программисту не только отвлекающие звонки, но и болезнь Альцгеймера, чтобы он забывал задачу каждые 15 минут, — и вы получите примерное представление о LLM-кодинге на Java.

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

Регулярные выражения
В целом LLM пишут их неплохо. Но из-за того, что регулярки состоят из очень маленьких лексем (часто одиночных символов), а модели часто работают с ненулевой «температурой» (параметр, отвечающий за креативность/случайность ответа), они могут быстро начать «галлюцинировать» и вставлять не те символы, ломая логику выражения. С математикой тоже бывают проблемы, хотя современные модели умеют подключать внешних «экспертов» или писать код для вычислений, это не всегда работает идеально.

Про Python рекомендую вот эту публикацию.
github.blog/news-insights/octoverse/octoverse-2024/



Что получается
Для Go-проектов и ряда других LLM уже применимы на уровне мидлов, которые хорошо кодят, но которым надо давать точное техническое задание.

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

Если это есть и он готов выступать тимлидом LLM-агентов, то эффективность растёт в разы.

Разработчик общается с LLM так же, как раньше с джунами — ставит задачу, проверяет, корректирует.

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

Код-ревью становится важнее: генерируемый код нужно внимательно читать.

Понимание архитектуры и умение читать чужой код становятся критически важными.

Меняется структура команд: потребность в джунах, которые в основном занимаются рутиной, снижается. Мидлы должны быстро расти до уровня Middle+, способных работать с архитектурой. Сильно растёт ценность Senior и лидов, способных грамотно ставить задачи и контролировать результат.

Результат: проект, который силами небольшой команды делался бы минимум месяц до начального рабочего состояния, у нас был собран за три дня. Ещё примерно столько же ушло на ревью (в том числе по ИБ), ручное тестирование крайних случаев и подготовку к продакшену. Затраты на токены — около 150 $.

Уверенность в коде? После моего ревью — высокая. Если сравнивать сгенерированный код до ревью с кодом джуна до ревью — уверенности в LLM-коде у меня больше. Он сразу пишет с учётом observability, тестов, лучших практик (если правильно попросить), даже с интеграцией токенов для защиты вызовов. Джуна этому ещё учить и учить.

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

Правильное техническое задание становится самой дорогой и важной частью.

Пайплайн «задача -> реализация» у нас уже радикально упростился. При обсуждении фич мы меньше зависим от опыта конкретного разработчика в конкретной технологии. Нужно интегрировать Cassandra? Не проблема, даже если у человека нет 5 лет опыта с ней. LLM выдаст «курс молодого бойца», поможет спланировать интеграцию, сгенерирует код. Разработчик контролирует процесс, вносит правки с учётом специфики нашего Go-кода. Стек стал гибче. Мы можем выбирать лучшие технологии под задачу, не ограничиваясь текущими знаниями команды. LLM помогает быстро вкатиться и интегрировать. Разработчик при этом получает реальный опыт с новыми инструментами.

Практическая скорость выросла, по нашим оценкам, примерно вдвое.

За один спринт (две недели) команда делает то, что раньше заняло бы месяц, и это при работе над новым проектом с нуля. Создать новый микросервис по образу и подобию существующих? Даёшь LLM пример, и он генерирует всю обвязку. Остаётся наполнить бизнес-логикой.

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

И давайте ещё раз: меньше совещаний. Это важно. Синки только по необходимости.

Освободившееся время уходит на ревью, продумывание сложной логики и тот самый «вайб-кодинг» — параллельную работу, где на одном экране код генерит LLM, на другом — правишь или пишешь сам, потом меняешься ролями для ревью. Работа становится более «дирижёрской». Даже DevOps-задачи частично можно переложить на LLM (генерация Dockerfile, K8s-манифестов).

Но есть и проблема контроля. Иногда тяжело ограничить место изменений. Просишь LLM поправить что-то в одном конкретном месте, пишешь «только здесь, только это», но нет гарантии, что он не затронет что-то ещё в другом файле или модуле.

Интересно, что даже размер микросервиса теперь может определяться не только бизнес-контекстом, но и размером контекста LLM — микросервисы стали де-факто стандартом, потому что с ними LLM справляются легче.

Как мы теперь нанимаем
Мы требуем уметь хорошо кодить руками на входе.

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

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

Этап джуна придётся проскакивать на тренировках, а не на реальных проектах.

Сам промпт-инжиниринг из области заученных лайфхаков превратился в умение сформулировать задачу. Модели достаточно развились, чтобы понимать свободные формулировки. Осталось только внести в них смысл — ради смысла и нужен профессионал. Нужно декомпозировать задачу, учесть все нюансы: версии библиотек и фреймворков (сказать: «Next.js», не уточнив App Router vs Pages Router — получить не то), протоколы взаимодействия (не указать gRPC — получить HTTP по умолчанию), конкретные требования к архитектуре, базам данных, безопасности.

Промптинг становится итерационным. Мы часто сначала генерируем верхнеуровневую архитектуру (например, в Markdown), правим её руками. Потом генерируем схемы взаимодействия между микросервисами (Protobuf, GraphQL, OpenAPI, SQL DDL) — это становится критически важным шагом, и только потом используем эту схему как часть промпта для генерации кода самих сервисов. Потом — документацию. Потом генерируем тесты (интеграционные тут особенно важны). Потом — структуру файлов и сигнатуры функций с комментариями. И только потом — сам код.

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

Ценность навыка написания кода снижается в пользу навыка чтения чужого кода. Однако и тут есть нюанс: после оперативного запуска нового кода ценность смещается в сторону знания кодовой базы. И именно этот фактор делает разработчиков незаменимыми (вспоминаем про bus factor, которого боятся все инвесторы).

Тим О'Райли недавно написал отличную статью о том, как меняется кодинг. Его мысль перекликается с нашими наблюдениями: LLM — это следующий уровень абстракции после фреймворков. Если раньше многие разработчики использовали фреймворк, не до конца понимая, как он работает «под капотом», то скоро появится целый класс специалистов, которые будут «просить LLM сделать», не зная деталей реализации. Программирование как навык и как бизнес ждут серьёзные трансформации в ближайшие 5–10 лет. Да, похожие вещи говорили с появлением BASIC и других высокоуровневых языков, и это нормально — каждая такая революция меняла ландшафт.

Как реагируют программисты? Похоже, сообщество разделилось на несколько групп, как отмечалось в Wired. Первая группа верит, что разработчики будут не нужны. Вторая считает LLM продвинутыми стажёрами, верит в рутину, но не верит в понимание. И реалисты — видят усилитель возможностей и личной эффективности. Мы скорее относим себя к реалистам. LLM не убьёт профессию, но сильно её изменит. Мир разработки переживает переломный момент, и важно адаптироваться. Работы не становится меньше, она становится другой.

beta.h3llo.cloud
h3llo.cloud

Давно думали о том, чтоб начать собственный бизнес? Теперь это сделать еще проще вместе со SpaceCore

Мы предоставляем все инструменты для старта вашего индивидуального хостинга по принципу White-Label (нигде не отображается название нашей компании)

Скидки до 20% на все виртуальные серверы для наших партнеров
Создайте свой уникальный продукт благодаря нашим специальным разработкам.
Предложите своим клиентам

• аукционные выделенные серверы
• VPS Contabo с автоматической установкой

• Подключиться к нам можно абсолютно бесплатно
• Круглосуточная поддержка в Telegram для наших партнеров
• Поможем с настройкой

Подробные условия spacecore.pro/reseller-program/
Полная инструкция по настройке собственного биллинга для продажи наших услуг
wiki.spacecore.pro/customer-service/setup-billmanager-6-for-reselling

• Все кто хочет открыть себе новую GEO точку.
• Или просто с нуля открыть хостинг компанию.

Обращайтесь к нам.
Оплачиваете покупку серверов под ваши «виды услуг», которые вы обговариваете с нами, что именно вы хотите запустить в наших стойках, которые будут только расти и увеличиваться по разным ДЦ.

1. Мы все настраиваем и сопровождаем ваш проект.
2. От вас только оплата серверов, интернета, электричества, IP адресов и лицензий ПО если такие требуются.

Мы не боимся конкуренции — поэтому помогаем ЛЮБОМУ ХОСТЕРУ. Даже если ты будешь оказывать аналогичные нашим услуги. Вдруг ты чему-то научишься или снимешь с нас нагрузку и неприятных клиентов будем отсылать именно тебе, если тебя они будут устраивать. Каждому по характеру, каждый работает только с теми с кем хочет работать. Чем больше хостеров с разными умениями и характерами — тем лучше для рынка и клиента, который ожидаемо идет туда где его примут, а не пошлют нахуй с возвратом денег.

Нам не жалко ©

Обращайтесь с вашим ТЗ, оплачиваете покупку серверов, а мы все настроим. Но будьте уверены что вам нужно работать 10 лет, нет смысла над чем-то работать 1 год и бросить, если уж вы создаете хостинг — то работайте «пока не сгорит первая партия» хотя бы, для начала.