Как быстрее и эффективнее расширять облачные ресурсы при пиковых нагрузках? Расскажем на бесплатном вебинаре.
📆 Когда: 13 мая в 11:00 мск
📍 Где: онлайн
Когда автомасштабирования кластера Kubernetes и масштабирования подов становится недостаточно, кластер необходимо расширять по событиям от внешних систем. На вебинаре вы узнаете, что делать, если триггер масштабирования кластера не утилизация, а события от внешних систем, например, сообщений Kafka или платформы CI/CD.
Эксперт покажет, как запустить приложение с учетом внешних систем, расскажет о классических подходах автомасштабирования, а также как масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler).
Вебинар будет полезен разработчикам, DevOps-инженерам и архитекторам облачных решений.
Приглашаем на второй Cloud․ru Tech Lab: DevOps — митап для DevOps- и SRE-инженеров 🎙️
📅 Дата: 22 мая в 18:00 📍 Место: Москва, Goelro Loft, Большая Почтовая улица, 40с4
Мы продолжаем серию технических митапов Cloud․ru Tech Lab — в этот раз обсудим сложности DevOps-процессов и разберем DevOps-практики на реальных кейсах.
Темы докладов:
ClusterAPI как цель, Terraform как мост: управляем жизненным циклом платформы — Олег Одинцов, Старший инженер платформы App.Farm, РСХБ-Интех.
Автомасштабирование K8s в ноль: от базы до хардкора — Илья Смирнов, Архитектор решений, Cloud․ru.
Calico CNI: жизнь после запуска — Александр Качмашев, Инженер, Точка.
Как организовать сетевую связность Bare C kubernetes — Антон Паус, DevOps-инженер, Cloud․ru.
Также в программе afterparty c нетворкингом, легкими напитками и закусками.
Мы предусмотрели два формата участия:
офлайн — для тех, кто планирует лично посетить площадку,
онлайн — для тех, кто хочет посмотреть доклады в записи.
Есть один отличный инструмент – это container-structure-test. Используется для функционального тестирования образов Docker и отлично интегрируется с container-tools, который я никогда не устану пиарить :).
То есть сначала собираем базовый образ, а затем сразу его тестируем.
Usage: make <target>
help - Display this help message
all - Build all Debian images
check-dependencies - Verify required tools are installed
clean - Remove all build artifacts and downloads
list-vars - List all Makefile variables and their origins
shellcheck - Validate all bash scripts
package - Create tar.gz archive of the directory
release - Create Git tag and GitHub release
archive - Create git archive of HEAD
bundle - Create git bundle of repository
test - Run structure tests on built container images
============================
** Debian Linux targets **
============================
|all|
|debian11|
|debian11-java|
|debian11-java-slim|
|debian11-corretto|
|debian11-graal|
|debian11-graal-slim|
|debian11-java-slim-maven|
|debian11-java-slim-gradle|
|debian11-graal-slim-maven|
|debian11-graal-slim-gradle|
|debian11-java-kafka|
|debian11-java-slim-kafka|
|debian11-nodejs-23.11.0|
|debian11-python-3.9.18|
Подписывать контейнеры с помощью GPG важно, потому что это гарантирует, что образ действительно создан вами или вашей командой и не был изменён после сборки. GPG — это проверенный инструмент, который уже давно используется для шифрования и подписи данных. Он не зависит от сторонних решений и является частью свободного ПО, поэтому ему можно доверять.
Когда вы подписываете контейнер, вы подтверждаете его целостность. Если кто-то заменит образ на поддельный с вредоносным кодом, подпись позволит это обнаружить. Без подписи вы рискуете запустить что-то небезопасное, даже не зная об этом.
Конечно, есть и другие инструменты, например cosign, которые тоже полезны, особенно в облачных средах. Но GPG остаётся надёжным базовым решением, которое работает везде и не требует дополнительной настройки. Проще говоря, это как печать на документе: если её нет, вы не можете быть уверены, что всё чисто.
container-tools % make
Usage: make <target>
help - Display this help message
all - Build all Debian images
check-dependencies - Verify required tools are installed
clean - Remove all build artifacts and downloads
list-vars - List all Makefile variables and their origins
shellcheck - Validate all bash scripts
package - Create tar.gz archive of the directory
release - Create Git tag and GitHub release
archive - Create git archive of HEAD
bundle - Create git bundle of repository
============================
** Debian Linux targets **
============================
|all|
|debian11|
|debian11-java|
|debian11-java-slim|
|debian11-corretto|
|debian11-graal|
|debian11-graal-slim|
|debian11-java-slim-maven|
|debian11-java-slim-gradle|
|debian11-graal-slim-maven|
|debian11-graal-slim-gradle|
|debian11-java-kafka|
|debian11-java-slim-kafka|
|debian11-nodejs-23.11.0|
|debian11-python-3.9.18|
Собираем базовый образ для NodeJS
make debian11-nodejs-23.11.0
После завершения сборки:
[Image was built successfully]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Artifact location: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
Artifact size: 93M
Для подписи используем gpg.py в составе container-tools:
./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB
2025-04-25 13:39:41,269 [INFO] Signing tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar -> Signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] Successfully signed tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:39:41,752 [INFO] Signature saved to: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] All tarballs have been processed successfully.
Подтверждаем:
./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB --verify
2025-04-25 13:40:19,734 [INFO] Verifying tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar against signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:40:20,192 [INFO] Verification successful: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:40:20,193 [INFO] All tarballs have bee
Вебинар: как устроена совместная работа виртуальных машин и контейнеров в Deckhouse
Завтра, 23 апреля, мы проведём вебинар о виртуализации в экосистеме Deckhouse. Расскажем, почему разрабатываем своё решение, и покажем, как запускать виртуальные машины рядом с контейнерами, чтобы управлять ими в рамках одной платформы оркестрации.
Будет полезно, если вы ищете альтернативу классической виртуализации или хотите начать использовать Kubernetes для оркестрации ВМ. Регистрируйтесь и подключайтесь с 12:00 по Москве. Ссылка для подключения придёт вам на почту.
Вы узнаете:
Какие возможности по управлению ВМ уже есть в Deckhouse.
Что мы вкладываем в понятие Cloud Native-виртуализации.
Для чего может быть нужна совместная работа ВМ и контейнеров.
На демо покажем возможности Deckhouse Kubernetes Platform по администрированию и мониторингу ВМ и контейнеров, конфигурации балансировщиков и микросегментации на основе сетевых политик.
Спикеры вебинара:
Георгий Дауман, менеджер продукта Deckhouse Virtualization Platform
Кирилл Салеев, архитектор инфраструктурных решений Deckhouse
Не можем не поделиться приятными апдейтами — SpaceWeb расширил линейку облачных сервисов и подключил Kubernetes. Новый продукт будет полезен для разработчиков и веб-студий для эффективного управления высоконагруженными приложениями, API-сервисами и проектами в облаке.
Kubernetes поможет с созданием и поддержкой микросервисных архитектур, управлением контейнерами и оркестрацией приложений. Сервис упрощает процесс развертывания, масштабирования и управления облачными инфраструктурами.
Можно выбрать следующие конфигурации: Control Plane и Worker Nodes — в зависимости от ваших задач и нагрузки. Стоимость Kubernetes начинается от 2 545 руб./месяц за стандартную мастер + 1 рабочую ноду 1 vCPU, 2 RAM, 40 Гб.
К чему это я все? DevOps инструментарий – это полный шлак. На попытку заставить на бэке работать эту чудо-поделку под названием GitLeaks, ушло больше времени чем на то, чтобы переписать ее с нуля, добавив еще и возможность кастомизировать паттерны для проверки.
Мы «завязываемся» на сторонние инструменты, которые легко заменить и готовим специалистов по установке Vault-of-Banks и Helm. А на реальные задачи ни укого не хватает времени и ресурсов.
Если необходимо заниматься дистрибуцией именно чартов Helm, то реализовать такую функциональность не составит особого труда.
С помощью директивы include в любой Makefile подключается еще один Makefile – helm.mk Оказывается variable scoping – это давно решенная проблема и для этого не нужен ни YAML ни cuelang.
Пишется скрипт на Python который генерирует чарт Helm:
define GENERATE_HELM_SCRIPT
import os
import yaml
import sys
from pathlib import Path
def make_helm_compatible(value):
"""Convert values to Helm template syntax where appropriate"""
if isinstance(value, dict):
return {k: make_helm_compatible(v) for k, v in value.items()}
elif isinstance(value, list):
return [make_helm_compatible(v) for v in value]
elif isinstance(value, str) and value.isdigit():
return f"{{{{ .Values.{value} }}}"
return value
И он может заодно сгенерировать еще и схему для values файла.
Теперь при создании нового кластера и в настройках текущего можно указать, когда устанавливать патчи и обновлять серты.
🚫 По дефолту в поле «Окно обслуживания» у всех кластеров стоит тег «Никогда», — то есть никаких им автообновлений.
Можно выбрать «В любое время» или задать конкретный интервал (например, с 2:00 до 5:00 по вашему часовому поясу). Минимальный интервал — 3 часа, обслуживание стартанет в этот период и продлится до двух часов.
Пример: допустим, у вас production-кластер для интернет-магазина (пиковый трафик с 9:00 до 21:00) и тестовый стенд. Вы можете:
😴 Для прода выставить окно с 3:00 до 6:00, когда трафик почти нулевой.
😊 Для тестового выбрать «В любое время», пусть обновляется сразу как выходит новая версия.
Веб-ресурсы, мобильные приложения и API ежедневно подвергаются DDoS- и бот-атакам. В 2024 году число заблокированных запросов ботов выросло на 30% по сравнению с предыдущим годом — об этом говорит отчет компании Curator «DDoS-атаки, боты и BGP-инциденты в 2024 году: статистика и тренды».
На вебинаре расскажем, почему защита от ботов — это отдельная задача, которая требует особых методов и которую не заменить решениями классов Anti-DDoS и WAF. Покажем методы эффективной защиты публичных веб-ресурсов и типовые схемы подключения для максимальной безопасности ресурса.
Управление уязвимостями (vulnerability management) — один из ключевых аспектов в поддержании информационной безопасности IT-инфраструктуры. На вебинаре обсудим базовые меры профилактики и защиты от киберрисков на уровне микросервисов, контейнеров и окружений под управлением Kubernetes.
Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в AvitoTech.
Недавно я рассказывал о новых подходах, которые мы использовали при создании дашбордов для диагностики. С тех пор дашборды такого типа обрели еще большую популярность, и мы решили выложить пример их реализации в галерею дашбордов Grafana.
За основу я взял наш дашборд Node Status, который показывал в предыдущей статье. Напомню, он служит для того, чтобы быстро понять, все ли в порядке с нодой в Kubernetes-кластере. В своей основе она содержит множество небольших панелек, которые единообразно подсвечиваются при возникновении аномалий: оранжевый значит «обрати внимание», красный - явно что-то не так. При необходимости по клику можно получить расширенную информацию по каждой метрике.
Я очистил наш внутренний вариант от специфики. Это позволяет использовать дашборд в любых окружениях, в которых развернуты нужные экспортеры:
node-exporter (лейбл «node» должен содержать имя Kubernetes-ноды);
kube-state-metrics;
node-problem-detector (опционально).
Несмотря на то, что все панельки должны в этом случае работать «из коробки», сам дашборд все же следует воспринимать как конструктор. У каждой инфраструктуры есть специфика, и вы можете легко отразить ее, опираясь на то, как реализованы уже имеющиеся панели.
Я полагаю, что ценность Node Status для комьюнити состоит не в том, какие именно метрики на ней собраны, а в том, на каких принципах она основана. Эти принципы зарекомендовали себя у нас, и вероятно будут также полезны и вам.
Если вы у вас возникнут сложности при использовании дашборда или предложения по его улучшению, пожалуйста, оставляйте свои комментарии!
Код с ИИ стал «дешевле», а вот архитектура дороже.
Генеративный ИИ позволяет быстрее проверять идеи и проводить эксперименты, но без умения задавать правильные вопросы и опыта в выстраивании SDLC, это всего лишь позволит вам генерировать больше кода низкого качества.
Вот например пришла идея посчитать косты и спрогнозировать расходы на K8s в облаке и on-prem. Конечно есть много (в основном платных) проектов типа Kubecost, но они не достаточно гибкие для решения такого рода задач.
Если об этом попросить ИИ то он поможет сгенерировать почти работающий скрипт, который нужно будет поправить. Но выберет самое наивное решение, забрать метрики через metrics API:
# Fetch pod metrics for a specific namespace
def get_pod_metrics(namespace):
try:
result = subprocess.run(
["kubectl", "get", "--raw", f"/apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods"],
capture_output=True,
text=True,
check=True
)
return json.loads(result.stdout)
except subprocess.CalledProcessError as e:
print(f"Error fetching pod metrics for namespace {namespace}: {e}")
return {}
В данном случае мы используем гипотетический AWS. python3 kost.py --plot Namespace Costs: Namespace: default Hourly Cost: $0.04 Daily Cost: $1.00 Monthly Cost: $30.00 6-Month Cost: $180.01 Namespace: kube-system Hourly Cost: $0.07 Daily Cost: $1.77 Monthly Cost: $53.17 6-Month Cost: $319.04
И получаем график с прогнозом расходов:
Plot
Но это слишком простое решение, для реальной инфры, нужна будет мультитенантность и гарантии доставки. Если ИИ попросить очень настойчего, то он может быть расскажет вам, что нужно забрать метрики из Prometheus, но он никогда не предложит использовать kubernetes API для передачи событий в NATS. Как показано в этом примере.
13 марта 16:00 CET (18:00 Мск) Андрей Квапил, более известный в инженерном сообществе как @kvaps будет травить байки о том, как правильно готовить LINSTOR и Talos Linux — на этот раз на комьюнити-мите LINBIT (создатели LINSTOR и DRBD). Основано на реальных событиях, приключившихся в Cozystack:)
Программа комьюнити-мита:
Andrei Kvapil: LINSTOR on Talos Linux: A robust base for Cozystack
На самом деле IaC или инфраструктура-как-код – это не оптимальный уровень абстракции. Эта концепция в конечном, счете создает больше проблем чем позволяет решить. На самом деле инфраструктура – это артефакт. Это может быть AMI, ISO, rpm, OVA\OVF, бинарный файл или, sqlite blob – любой атомарный объект который содержит код и метаданные необходимы для развертывания. Когда индустрия свернула не туда и ушла от этой концепции это стало ошибкой.
Это образцовая облачная архитектура для сайта на Wordpress, если верить Amazon. Я сначала подумал что это прикол, xkcd комикс, пародия, но нет – это реальные рекомендации и у Google, или Microsoft будет все примерно похоже.
Вы больше не думайте о серверах и дата-центрах, вместо этого нужно будет научится жонглировать облачными сервисами, которые у каждого провайдера отличаются ровно на столько, чтобы не возможно было просто мигрировать к конкуренту.
Большинству разработчиков от облака нужно ровно три вещи: объектное хранилище (s3), хостинг для ВМ (AMI) и DBaaS (RDS). Но облачным провайдерам важно, чтобы вы по максимуму использовали все сервисы и чем больше – тем лучше.
За каждый из этих сервисов естественно нужно будет платить, а биллинг сделан так, что ошибка, может пробить дыру в бюджете любой компании. Нужен будет архитектор с экспертным знанием экосистемы конкретного облачного провайдера.
Просто так развернуть что-то серьезное в облаке не получится. Для IaC есть – terraform, но кроме terraform у каждого провайдера есть еще свои инструменты. Но terraform не очень подходит для настройки приклада в VM, его обычно используют в связке с Packer, Ansible и скриптами. И здесь нужны будут cloud-инженеры с опытом работы на конкретном стеке.
Напоминаю все это необходимо, для приложения, которое лет десять назад, можно было развернуть используя LAMP несколько выделенных серверов. Причем разворачивали многие очень императивными скриптами на Perl и в умелых руках это было надежнее и быстрее, чем сегодняшний IaC-инструментарий.
А для Enterpise ни один из современных IaC инструментов не решает проблемы «Day2» – что делать с инфраструктурой, после того, как вы ее развернули. Terraform ничего знает об ITSM, CMDB, комплаенсе и лицензировании.
На самом деле все гораздо проще, те инструменты которые мы используем сейчас, просто недостаточно хороши. У меня есть для вас другие инструменты.
Камера медленно приближается к темному переулку, где в тумане маячит силуэт. Голос за кадром, с легким лондонским акцентом, начинает рассказ:
"Значит, слушай сюда, дружок. У тебя есть куча подонков — подонков, которые зовутся подами. Они все хотят своего кусочка ресурсов: CPU, память, сеть — всё, что угодно. Но тут, понимаешь, появляется Он. Планировщик. Хладнокровный, расчетливый, с алгоритмом, который знает, кто, где и когда получит свой удар. Он как тот парень в баре, который всегда знает, кто за кем стоит, и кто кому должен.
Он берет эти поды, смотрит на их запросы, на узлы, которые свободны, и решает, кто куда пойдет. Round Robin, Least Requested, Priority Queue — это всё его инструменты, как у Шерлока. Никаких эмоций, только холодная логика. И если ты думаешь, что можешь его обмануть, то, дружок, ты ошибаешься. Он всегда на шаг впереди.
Так что, если ты вдруг решишь запустить свой под в этом городе, помни: Планировщик уже знает, где ты будешь жить. И если ты не вписываешься в его план, то, увы, тебя ждет только одно — Eviction. И это, друг мой, не шутки."
Камера отъезжает, показывая огромный кластер узлов, где каждый под занимает свое место, как в идеально спланированной афере.
Возможно будут публиковаться более длинные видосы, статьи, обзоры и пошаговые инструкции.
Следить за быстрым циклом выпуска новых версий Kubernetes — это серьезная задача, особенно для разработчиков платформ, которые используют Kubernetes в качестве основы для своих систем. Kubernetes выпускает новую версию примерно каждые три месяца, и каждая версия привносит новые функции, улучшения, а иногда и критические изменения, которые могут нарушить обратную совместимость.
Чтобы решить эту проблему, я решил создать переиспользуемый шаблон для сборки Kubernetes, используя сам Kubernetes в качестве фермы для сборки. Этот шаблон, описанный в документации kube-buildx-farm.md, предоставляет структурированный способ настройки и управления фермой для сборки на основе Kubernetes.
Как всегда все лампово, модульно и удобно:
tool
Быстрые сборки ускоряют разработку и обратную связь, а герметичные — обеспечивают воспроизводимость и надежность, исключая ошибки из-за внешних зависимостей. Это один из ключевых моментов при конструировании CI/CD.
Bazel и Gradle используют Directed Acyclic Graph (DAG, направленный ациклический граф) для управления задачами сборки и зависимостями между ними. Вот краткое описание того, как каждый из этих инструментов использует DAG:
Bazel строит граф зависимостей, где узлы представляют собой цели (targets), такие как исходные файлы, библиотеки или бинарные файлы, а ребра обозначают зависимости между ними. Этот граф используется для:
Определения порядка выполнения задач: Bazel анализирует граф, чтобы понять, какие задачи могут быть выполнены параллельно, а какие должны ждать завершения других.
Инкрементальной сборки: Bazel использует граф для определения измененных частей кода и пересборки только тех компонентов, которые зависят от этих изменений.
Кэширования: Результаты выполнения задач кэшируются на основе их положения в графе, что позволяет избежать повторной сборки неизмененных частей.
Gradle
Gradle также использует DAG для управления задачами сборки. В Gradle:
Задачи (tasks) представляют собой узлы графа, а зависимости между задачами — ребра.
Планирование выполнения: Gradle анализирует граф, чтобы определить порядок выполнения задач, учитывая их зависимости.
Инкрементальная сборка: Gradle использует граф для отслеживания изменений и выполнения только тех задач, которые зависят от измененных входных данных.
Параллельное выполнение: Gradle может выполнять независимые задачи параллельно, основываясь на структуре графа.
Общее
Оба инструмента используют DAG для оптимизации процесса сборки, минимизации избыточных вычислений и обеспечения корректного порядка выполнения задач. Это позволяет эффективно управлять сложными проектами с большим количеством зависимостей.
Такие сложные инструменты как Bazel и Gradle можно как в биологии отнести к «инвазивным видам». Особенно если речь идет о Bazel.
То есть он решает несколько очень важных проблем, но при этом все проекты в которых он используется необходимо реструктуризовать под требования Bazel.
Если проводить аналогию с ERP, то Bazel это как SAP. Мощная система, которая позволяет решить большое количество проблем бизнеса, но при этом все бизнес-процессы в компании нужно будет адаптировать под требования SAP.
С Bazel не нужно покупать лицензии, но придется потратится на дорогих консультантов, потому что людей, которые разбираются в этом инструменты.
Главные фичи которые есть у Bazel это удаленное кэширование и распределенные сборки, можно реализовать своими силами и лучше чем это реализовано в Bazel.
Для Kubernetes есть несколько инструментов для непрерывного развертывания (Сontinuous Deployment): ArgoCD, FluxCD и Spinnaker. Все не будем перечислять, хотя проектов enterprise не так много. И есть, конечно DIYs
Spinnaker – это как дредноут из «Звездных Войн» – там есть все под любые use-кейсы требования. Для канареечных релизов ему не нужен service mesh или Flagger. Spinnaker работает с AWS, GCP, Azure, OpenStack, Kubernetes.
Spinnaker
ArgoCD – гораздо легче и маневренее, как легкий крейсер, который проще в установке и обслуживании, но при этом имеет ряд ограничений:
Ориентация на Kubernetes: Argo CD заточен исключительно под Kubernetes и не поддерживает развертывание ресурсов за его пределами (например, облачные сервисы AWS, GCP или базы данных). Для управления такими ресурсами требуется интеграция с дополнительными инструментами, такими как Terraform или Crossplane.
Отсутствие встроенных стратегий развертывания: Argo CD не предоставляет встроенных механизмов для сложных стратегий развертывания, таких как canary или blue/green. Для их реализации необходимо использовать сторонние инструменты, например, Istio или Flagger.
Сложность управления большим количеством приложений: При работе с сотнями или тысячами приложений управление через Argo CD может стать сложным. Хотя ApplicationSets помогают решить эту проблему, они требуют дополнительной настройки и могут усложнить конфигурацию.
То же самое касается Flagger:
Ориентация на Kubernetes: Flux CD, как и Argo CD, ориентирован исключительно на Kubernetes и не поддерживает управление ресурсами вне кластера (например, облачные сервисы AWS или базы данных). Для таких задач требуется интеграция с дополнительными инструментами, такими как Terraform или Crossplane. Отсутствие встроенного UI: Flux CD не предоставляет графического интерфейса (UI) для управления развертываниями, что может усложнить мониторинг и отладку для команд, привыкших к визуальным инструментам. В отличие от Argo CD, Flux CD полагается на CLI и логи. Ограниченная поддержка сложных стратегий развертывания: Flux CD не имеет встроенных механизмов для сложных стратегий развертывания, таких как canary или blue/green. Для их реализации требуется интеграция с дополнительными инструментами, например, Flagger или Istio.
Ну и есть еще конечно DIY – делаем все сами. Есть ряд крупных организаций с особенными требованиями, для которых этот подход является оптимальным. Не обязательно для этого быть Google или Meta – любая организация со сложной внутренней структурой требует особого подхода, плясать нужно от требований бизнеса, а не от возможностей продукта. Только делать DIY для решения таких сложных задач, нужно не на Ansible и Groovy – но об это как-нибудь в следующий раз.
Все актуальное в нашем managed Kubernetes. Обновили прошлые версии и добавили две новые — v1.32.1+k0s.0 и v1.31.5+k0s.0. Главное:
Kubernetes v1.32.1
Эта версия значительно апгрейднула управление ресурсами на уровне подов. Теперь там можно отправлять запросы и задавать лимиты ресурсов, что помогает динамически балансировать нагрузку во всем пуле. Полезно для проектов, где запросы мощностей постоянно меняются.
Также теперь в статусе подов можно отслеживать состояние аппаратных ресурсов. Мониторинг на раз-два + быстрое устранение неполадок.
Kubernetes v1.31.5
А тут у нас полезный патч-релиз, — с фиксом ошибок и улучшением стабильности.
Бонус-трек
Доработали Куб и выкатили еще несколько прикольных релизов. Во-первых, в список кластеров вшили ссылки на доку, а на виджет в дашборде вывели отображение лимита воркер-нод.
А еще — теперь можно скачивать файл с конфигом прямо со страницы со списком кластеров.
Через 10 минут, в 16:00 мск, начинаем воркшоп «Как развернуть приложение в кластере Managed Kubernetes на выделенном сервере». Узнайте, как повысить производительность сервиса и сократить расходы на IT-инфраструктуру до 40%.
Если использовать в CI/CD (Jenkins, GitLab), воркеры с GraalVM (Вместо JRE) и Maven/Gradle, то можно ускорить сборку и тестирование Java приложений, примерно на 40%.
Я написал «фреймворк» специально для автоматизации создания базовых образов Docker под различные рантаймы.
Добавили еще два новых приложения в маркетплейсе Kubernetes — Velero и Fluent Operator. Рассказываем о пользе каждого:
1. Velero — мощный инструмент для резервного копирования и восстановления кластеров Kubernetes. С этим допом можно легко создавать бэкапы и восстанавливать данные в случае сбоя или при миграции.
Кстати, у нас в доке описан отличный кейс связки Velero c бакетами S3 для хранения резервных копий. Вот, попробуйте настроить →
2. Fluent Operator, в свою очередь, упрощает сбор, обработку и отправку логов с помощью Fluent Bit и Fluentd. А это дает вашим проектам больше гибкости и масштабирования для работы с большими объемами данных.
А еще Fluent Operator упрощает интеграцию с Elasticsearch, Loki, Kafka, Prometheus и другими инструментами.
Все новые дополнения уже можно тестить в панели и загружать для них собственные конфиги.
Это задачка для DevOps-инженера: почему ArgoCD не расшифровывал секреты из Vault
Нашему DevOps-специалисту Антону нужно было развернуть helm-чарт для Airflow с использованием ArgoCD. Как известно, ArgoCD реализует концепцию GitOps и подразумевает хранение манифестов в репозитории. Но часть данных в values чувствительна, например пароль от базы данных PostgreSQL. Поэтому неплохо было бы вынести эти данные в хранилище секретов (в этом случае — HashiCorp Vault), чтобы скрыть информацию от лишних глаз.
Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительный по ряду причин — vault-injector. В обычной ситуации Антон бы воспользовался им, но в случае с helm-чартом Airflow задача показалась непростой. Поэтому он решил воспользоваться менее предпочтительным, но точно рабочим (как думал Антон) вариантом с ArgoCD Vault Plugin.
Какая вылезла проблема
Когда секреты были добавлены в хранилище, а ArgoCD Application написан, Антон попытался развернуть его для теста. Вот примерный Application, с которым это делалось (весомая часть пропущена для компактности):
Ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета. А еще — компонент webserver отказался запускаться, ссылаясь на невозможность подключиться к базе данных. Хотя данные были абсолютно точно правильными.
В чем итоге была проблем и как Антон с ней справился, читайте в статье →
Как сэкономить на IT-инфраструктуре? Дадим план действий на вебинаре
Привет, Хабр! 29 января в 12:00 проведем вебинар «Cloud или Bare Metal: где лучше запускать кластеры Kubernetes?». Обсудим, как сократить расходы на инфраструктуру до 40%. Присоединяйтесь!
Managed Kubernetes на выделенных серверах позволяет экономить на железе. На практическом вебинаре объясним и покажем, как это сделать. Познакомим вас с самыми популярными и выгодными конфигурациями серверов для развертывания кластеров Kubernetes и поделимся кейсами клиентов, которые уже используют решение.
«Что получится, если совместить мощность и безопасность выделенных серверов с гибкостью Kubernetes? Поговорим про производительность, эффективное управление ресурсами и снижение расходов у клиентов нового продукта Selectel Kubernetes on Bare Metal. До встречи!»
Сергей Ковалёв, спикер вебинара и менеджер выделенных серверов в Selectel
Кому будет особенно полезно?
DevOps-инженерам и SRE-инженерам;
Разработчикам и руководителям IT-проектов;
Системным администраторам и архитекторам;
Всем, кто работает с орекстраторами.
Ключевые темы
Managed Kubernetes на Bare Metal
Поговорим о преимуществах использования нового сервиса Selectel. Расскажем, для каких задач он подойдет.
Выделенные серверы, их особенности и преимущества
Раскроем карты и покажем самые популярные и выгодные конфигурации серверов для развертывания кластеров Kubernetes.
Пошаговое создание кластера Managed Kubernetes на выделенных серверах
Покажем весь процесс создания кластера с нуля и ответим на вопросы. Объясним, какие задачи возьмем на себя, а что останется сделать вам.
Задавайте вопросы — спикеры ответят на них в прямом эфире. За лучший вопрос подарим подарок от Selectel!
Ребята из UC Berkeley с 2009 года развивают фреймворк «Sky computing», который обеспечивает устойчивое и экономически эффективное обучение AI/ML в облачных средах и разных регионах.
Но на самом деле все это сводится к простой максиме:
Есть бюджет сложности и бюджет ошибок. Можно израсходовать ресурс на инфраструктуру, и тогда на разработку и продукт ничего не останется.
Современная облачная инфраструктура, зачастую непростительно расточительна на ресурсы (не только аппаратные, но и человеческие) и , совершенно, без нужды переусложнена.
Для обычного веб-приложения или AI/ML пайплайна, может понадобится стек технологий состоящий из тысяч различных компонентов, которые постоянно меняются и обновляются.
На месте этой подпорки мог бы быть xz или OpenSSL...
Skypilot это прослойка (облачный брокер как называют его авторы) которая абстрагирует разницу между API различных облачных провайдеров, Kubernetes, VMware vSphere API.
На самом деле, достаточно простое приложение написанное на Python, которое позволяет быстро разворачивать и мигрировать AI/ML пайплайны на различных платформах.
Можно без лишних хлопот развернуть одну из последних моделей на своей инфраструктуре.
x3 Control Plane
Процессор
Intel Core i3-12100
3.3 ГГц, 4 ядра
Память
32 ГБ DDR4 ECC
x3 Worker
Процессор
Intel Core i9-14900KS
3.2 ГГц, 24 ядра
Видеокарта
RTX 4090 24 ГБ VRAM
Память
128 ГБ DDR5 non-ECC
Qwen2.5-72b-instruct это одна из лучших открытых моделей для генерации кода. Для нормальной работы понадобится по крайней мере 96Gb VRAM.
Для работы skypilot необходим socat:
sudo apt install socat
Skypilot так же прост в установке и настройке, как и в использовании:
git clone https://github.com/skypilot-org/skypilot.git
cd skypilot
pip install -e ".[kubernetes]"
Skypilot далек от идеала, но он построен на правильных принципах:
Простой CLI интерфейс и DSL скрывают от инженеров сложность позволяя быстро вводить в работу ML команды.
Разработчики не должны знать ничего о Helm чартах, модулях Terraform, плейбуках Ansible. Deploy должен происходить «по кнопке», причем не имеет значения будет это «merge» в SCM или «ручка» в CI, потому что GitOps не является целью, главное – это результат. А если это необходимо можно заменить любой из этих инструментов кастомной автоматизацией.
Приглашаем на бесплатные вебинары, посвященные K8s🎓
1. «Быстрое погружение в основы Kubernetes» — для тех, кто хочет понять технологию контейнерных приложений и начать с ней работать. На встрече разберемся с теорией: что такое контейнеры, какие основные компоненты есть у Kubernetes и для чего они нужны. Знаний будет достаточно, чтобы начать развиваться в направлении DevOps.
Программа вебинара:
чем микросервисная архитектура отличается от монолитной;
контейнеры — основа микросервисной архитектуры;
зачем нужен Kubernetes;
как устроен кластер Kubernetes.
Будет полезно тем, кто задумывается о переезде в облако и планирует узнать о нем больше. А также тем, кто планирует начать погружаться в DevOps в общем или в Kubernetes в частности.
2. «Как развернуть кластер Kubernetes за несколько кликов» — в прямом эфире покажем, как развернуть простое приложение в кластере Kubernetes в облаке Cloud.ru Evolution и сэкономить ресурсы, используя K8s как PaaS-сервис.
Программа вебинара:
обзор сервиса Evolution Managed Kubernetes;
демо развертывания кластера;
подключение к кластеру с помощью kubectl;
развертывание WordPress в кластере;
разбор нюансов управления кластером, развернутым как PaaS-сервис.
Будет интересно разработчикам, DevOps-инженерам, архитекторам облачных решений и всем, кто работает с Kubernetes (K8s).
Если у вас есть вопросы по теме, их можно оставить в комментариях под этим постом или задать в процессе встречи. Спикер вебинаров Илья Смирнов — архитектор решений, ответит на них в прямом эфире.
Всем привет! Мы начинаем подводить итоги 2024 года 🎄.
В этом году в Cloud.ru прошло целых 40 бесплатных вебинаров про эффективную миграцию в облако, создание облачной инфраструктуры, настройку сервисов, работу с данными и снижение затрат на обслуживание. Дальше — больше!
Все вебинары в любой момент можно посмотреть в записи и познакомиться с интересующей вас темой. А одна из самых популярных тем уходящего года — Kubernetes, поэтому ей мы посвящаем предновогоднюю подборку. Смотрите от простых тем к более сложным:
🛍️ Добавили универсальные решения для мониторинга и визуализации данных на Маркетплейсе Cloud.ru: Grafana, Kibana и Prometheus. Их совместное использование поможет быстро реагировать на любые изменения и неполадки в IT-инфраструктуре.
💸 Предлагаем зарабатывать вместе с Cloud.ru: присоединяйтесь к реферальной программе, рекомендуйте наши облачные сервисы клиентам, коллегам или друзьям и получайте вознаграждение 15%. Участвовать могут не только юридические лица и ИП, но и физические лица, а также самозанятые.
🖖Привет, Хабр! Наша команда готовит видео о развёртывании Kubernetes на базе физического сервера. Стремимся выжать из темы максимум пользы, поэтому нам нужна ваша помощь: хотим узнать, что вам было бы интересно послушать по этой теме.
Будем рады, если вы напишите свои вопросы либо в комментариях под этим постом, либо в этой гугл-форме.
Вопросы могут быть любыми, от рентабельности решения до технических нюансов. Принимаем вопросы до пятницы. На те, что будут написаны позже, ответим текстом.
Подключайтесь к вебинару «Автомасштабирование K8s в ноль: от базы до хардкора».
📅 Когда: 12 декабря в 11:00 мск
📍 Где: онлайн
Автомасштабирование кластера Kubernetes и масштабирование подов помогают быстро расширить облачные ресурсы при пиковых нагрузках. Но иногда классических подходов недостаточно, и кластер необходимо масштабировать по событиям от внешних систем.
На вебинаре вы узнаете, что делать, если триггер масштабирования кластера не утилизация, а события от внешних систем, например, сообщений Kafka или платформы CI/CD. Архитектор решений Илья Смирнов покажет, как запустить приложение с учетом внешних систем, расскажет о классических подходах автомасштабирования, а также, как масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler).
Будет интересно разработчикам, DevOps-инженерам и архитекторам облачных решений.
Чем больше знаний о Kubernetes — тем громче оркестр: Orion soft запустил спецпроект с ИИ-генерацией музыки
Привет! Наша команда Nova Container Platform запустила спецпроект, в котором можно проверить свои знания о Kubernetes. Мы создали виртуальный оркестр, который играет разные мелодии в зависимости от вашего количества правильных ответов.
Уникальные композиции нам помог сгенерировать ИИ. Музыкальные партии можно услышать в разных комбинациях — от соло до совместной игры всех «участников» оркестра. Каждый правильный ответ о Kubernetes открывает новый инструмент и дает возможность получить звание «гуру дирижирования ИТ-инфраструктурой».
Услышать виртуальный оркестр могут все, кто участвует в проекте Nova Container Platform по проверке знаний. Все участники получат полезные чек-листы по работе с кубером. А победителей ждут крутые призы: электрогитара, эксклюзивный мерч и книга «Внедрять нельзя откладывать. Карта рынка ИТ-инфраструктуры».
Мы обновили KaaS от Рег.ру и добавили поддержку Kubernetes 1.31. Публикуем мини-обзор ключевых преимуществ новой версии.
Собственные профили в kubectl debug
Теперь пользователи могут создавать собственные профили для дебага. Это ускоряет процесс отладки и делает его более удобным.
Случайный выбор подов при даунскейлинге ReplicaSet’а
В этом релизе добавили алгоритм случайного выбора Pod’а при уменьшении количества реплик в ReplicaSet. Это способствует более равномерному распределению нагрузки.
VolumeAttributesClass ModifyVolume
API VolumeAttributesClass даёт возможность изменять динамические параметры томов — например, I/O. Это позволяет приложениям увеличивать размеры томов онлайн, что помогает лучше сбалансировать затраты и производительность.
Поддержка использования образов в качестве вольюмов
Внедрили поддержку образов и артефактов, совместимых с Open Container Initiative (OCI), в качестве источников для вольюмов. Пользователи могут указывать ссылку на образ в Pod и монтировать его как том в контейнерах.
Более точное управление SupplementalGroups
Добавлено новое поле SupplementalGroupsPolicy в API для контроля дополнительных групп, назначаемых первому процессу в контейнере. Это позволит администраторам точнее настраивать политики безопасности и избежать неожиданного обхода SupplementalGroups, а пользователи смогут определять фактические группы, назначенные процессам в контейнерах.
Протестировать KaaS от Рег.ру и заказать услугу можно на сайте.
Ежемесячный дайджест: главные новости за октябрь☂️
🦾 Провели хардкорную IT-конференцию про внутрянку облачных решений и русского AI — GoCloud Tech. Как это было и что говорили участники читайте в статье и смотрите доклады в записи.
🌾 Развернули IT-инфраструктуру в полях… в нашем новом ролике! Как широки просторы для ваших идей в Сloud.ru смотрите на YouTube, на RuTube или в VK.
⚙️ Увеличили бесплатный объем хранилища Evolution Object Storage — его хватит, чтобы загрузить медиафайлы, бэкапы или архивы. А про опыт тех, кто уже запустил проект в облаке с помощью бесплатных ресурсов Evolution free tier, читайте в статье.
🎓 На вебинаре рассказали про новые бесплатные курсы по основам облачных технологий и сертификацию. Обсудили, зачем изучать облачные сервисы, как устроено обучение на курсах Cloud.ru, что дает электронный бейдж и как может помочь в построении карьеры.
Подключайтесь к вебинару «Быстрое погружение в основы Kubernetes на практике».
📅 Когда: 12 ноября в 11:00 мск
📍 Где: онлайн
Вебинар для тех, кто хочет понять технологию микросервисных приложений и начать с ней работать. На встрече разберемся, из каких компонентов состоит Kubernetes и для чего нужен каждый из них. В ходе вебинара покажем, какие ресурсы можно создать в кластере и как это сделать своими руками. Знаний будет достаточно, чтобы начать развиваться в направлении DevOps.
Программа вебинара:
зачем нужен Kubernetes;
как устроен кластер Kubernetes;
развернем приложение в кластере.
Будет полезно тем, кто задумывается о переезде в облако и планирует узнать о нем больше. А также тем, кто планирует начать погружаться в DevOps в общем или в Kubernetes в частности или уже использует облачные технологии и хочет задать вопрос эксперту по своей задаче.
