Все используют балансировщик нагрузки, но немногие понимают алгоритмы балансировки

Вот несколько популярных:

🔹Round Robin — распределяет входящие запросы по серверам по очереди в фиксированном циклическом порядке.

🔹IP Hash — использует хеш-функцию от IP-адреса клиента, чтобы стабильно направлять его на один и тот же сервер.

🔹Least Connections — перенаправляет новые запросы на сервер с наименьшим количеством активных соединений.

🔹Weighted Round Robin — распределяет запросы с учётом веса (веса или производительности) каждого сервера, передавая больше трафика более мощным узлам.

🔹Least Response Time — направляет запросы на сервер с наименьшей средней задержкой или временем отклика.

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

👉 DevOps Portal

Как собрать продакшн-готовый образ контейнера для Go-приложения

Достаточно ли тебе FROM scratch? Посмотри эти практические задания, чтобы разобраться с типичными проблемами контейнеризации Go:

- Cтатическая линковка: https://labs.iximiuz.com/challenges/dockerize-golang-application-static-linking

- Динамическая линковка https://labs.iximiuz.com/challenges/dockerize-golang-application-dynamic-linking

👉 DevOps Portal

Podman — альтернатива Docker без демона

Podman – это container runtime, который имитирует Docker на уровне основных команд (run, exec, kill и т.д.), но при этом под капотом использует daemonless-архитектуру. У такого подхода есть свои плюсы (например, меньше moving parts, более простой rootless-сетап) и минусы (например, без демона некоторые операции с контейнерами требуют дополнительной интеграции с systemd).

Вот несколько практических челленджей, если хотите попробовать Podman и сравнить его с Docker:

- Запуск и инспектирование контейнера в Podman
https://labs.iximiuz.com/challenges/start-container-with-podman
- Автоматический рестарт контейнера Podman после перезагрузки хоста
https://labs.iximiuz.com/challenges/podman-101-container-restart-on-host-reboot
- Запуск и инспектирование контейнера в Docker (для сравнения)
https://labs.iximiuz.com/challenges/start-container-with-docker

👉 DevOps Portal

Настройка Kubernetes-кластера на Kubeadm 1.36 (пошагово)

Вот почему стоит развернуть собственный self-hosted Kubernetes-кластер.

Когда вы поднимаете кластер с нуля,

вы начинаете гораздо лучше понимать, как устроены control plane-компоненты и worker-ноды Kubernetes.

Кроме того, если вы готовитесь к экзаменам CKA или CKS, управление кластером через Kubeadm входит в официальный syllabus этих сертификаций.

Вот обновлённый гайд по настройке Kubeadm 1.36, где весь процесс разобран пошагово.

https://devopscube.com/setup-kubernetes-cluster-kubeadm/

Для DevOps-инженера крайне важно глубоко понимать все компоненты, из которых состоит Kubernetes-кластер.

Рекомендую в процессе обучения использовать именно self-hosted Kubernetes-кластер, а не готовые managed-решения, которые легко доступны "из коробки".

👉 DevOps Portal

Stakpak — это опенсос AI-агент для терминала, заточенный под DevOps: генерирует инфраструктурный код, дебажит Kubernetes и автоматизирует деплои. При этом использует подстановку секретов, чтобы LLM никогда не получала доступ к вашим реальным данным

https://github.com/stakpak/agent

👉 DevOps Portal

Apache Airflow на Kubernetes (MLOps)

Если вы хотите работать с проектами в области MLOps, Data Engineering или AI-инфраструктуры,
знание Apache Airflow может дать вам серьёзное преимущество.

Apache Airflow — это open-source платформа для построения и управления сложными воркфлоу и пайплайнами.

В этом блоге разобрали:

- Что такое Apache Airflow
- Как работают DAG’и
- Как устроены executors в Airflow
- Развёртывание Airflow в Kubernetes
- Настройку GitSync для управления DAG’ами
- Важные Day 2 operational insights и многое другое...

Читайте здесь: https://devopscube.com/apache-airflow-on-kubernetes/

Изучение Airflow значительно упрощает понимание таких платформ, как Kubeflow, потому что их ключевые концепции очень похожи:
- DAG’и
- Оркестрация задач
- Выполнение пайплайнов и т.д.

👉 DevOps Portal

Когда FROM scratch-образа уже недостаточно 🤔

Тебе дали падающий контейнер – простой Go-сервер, который при получении запроса ходит в HTTPS API и проксирует ответ обратно клиенту.

Сможешь починить?
https://labs.iximiuz.com/challenges/when-from-scratch-image-is-not-good-enough

👉 DevOps Portal

Этот туториал показывает, как добавить observability в EKS-кластер: перейти на паттерн App of Apps в ArgoCD и развернуть kube-prometheus-stack с корректно настроенным EBS CSI driver и конфигурацией kubelet cAdvisor

Читайте тут

👉 DevOps Portal

Helm _helpers.tpl file – что это такое?

Если вы работаете с Helm чартами, то наверняка видели файл _helpers.tpl внутри директории /templates.

Многие просто игнорируют его, не понимая, зачем он нужен при деплое чарта.

В этом гайде разобрали:
- что такое _helpers.tpl и как он работает;
- что такое named templates / partial templates;
- практический пример использования;
- в каких случаях его лучше не использовать.

Читайте здесь: https://devopscube.com/_helpers-tpl-file-in-helm-charts/

👉 DevOps Portal

Чеклист готовности Kubernetes к продакшену для команд, которые подготавливают workloads к запуску в production.

В него входят: интерактивный чеклист, подробные пояснения к каждому пункту проверки и PDF-воркшит для скачивания.

https://learnkube.com/production-best-practices

👉 DevOps Portal

Развёртывание Kubernetes-кластера с помощью kubeadm

Этот туториал от Márk Sági-Kazár не просто пошагово объясняет процесс, но и даёт возможность выполнить каждую команду в изолированной песочнице, чтобы убедиться в её корректности.

Изучай Kubernetes на практике:
https://labs.iximiuz.com/tutorials/provision-k8s-kubeadm-900d1e53

👉 DevOps Portal

Новая серия практических челленджей от Kaloyan Preslavski, полностью сфокусированная на том, как работает планирование подов в Kubernetes

- Kubernetes Pod Scheduling: Requests ресурсов
https://labs.iximiuz.com/challenges/resource-requests-scheduling-e607f0d4
- Kubernetes Pod Scheduling: QoS-классы (Quality of Service Classes)
https://labs.iximiuz.com/challenges/qos-classes-ed21d34c
- Kubernetes Pod Scheduling: Priority и Preemption
https://labs.iximiuz.com/challenges/priority-preemption-9c62482f
- Kubernetes Pod Scheduling: LimitRange и ResourceQuota
https://labs.iximiuz.com/challenges/limitrange-resourcequota-7d992c42
- Kubernetes Pod Scheduling: Pod Affinity и Anti-Affinity
https://labs.iximiuz.com/challenges/pod-scheduling-affinity-8733a9e2
- Kubernetes Pod Scheduling: nodeSelector и Node Affinity
https://labs.iximiuz.com/challenges/nodeselector-node-affinity-e80db96a
- Kubernetes Pod Scheduling: Topology Spread Constraints
https://labs.iximiuz.com/challenges/topology-spread-constraints-a806af86
- Kubernetes Pod Scheduling: Taints, Tolerations и Node Affinity — почему иногда нужны сразу оба механизма
https://labs.iximiuz.com/challenges/taints-tolerations-node-affinity-3cd4d1de
- Kubernetes Pod Scaling: Horizontal Pod Autoscaler (HPA)
https://labs.iximiuz.com/challenges/hpa-scaling-5f978f78

Приятного хаккинга! 🤝

👉 DevOps Portal

Этот инструмент предоставляет доступ к операциям Kubernetes-кластера через Model Context Protocol, позволяя AI-агентам и инструментам безопасно читать состояние кластера и выполнять контролируемые действия, такие как команды kubectl

https://github.com/containers/kubernetes-mcp-server

👉 DevOps Portal

Kubernetes начинался как слой планировщика поверх набора однохостовых Docker-демонов. Это значит, что долгое время Kubernetes-поды были всего лишь "полусклеенными" группами Docker-контейнеров.

Со временем появился Container Runtime Interface (CRI), который дал возможность подменять и настраивать container runtime’ы. Большинство кластеров перешло с тяжеловесного Docker на более специализированный containerd в качестве «высокоуровневого» runtime’а, при этом низкоуровневый OCI runtime (runc) остался без изменений.

Однако потребность в более изолированных подах продолжала расти, и вслед за этим появились "альтернативные" реализации – альтернативные по отношению к Docker-style контейнерам. Самые заметные из них – gVisor и Kata Containers.

gVisor запускает контейнеры поверх урезанного user-land kernel, написанного на Go, а Kata Containers оборачивает обычные Linux-контейнеры в microVM’ы для дополнительной изоляции.

Естественно, возникла необходимость указывать container runtime на уровне пода. Так и появился ресурс RuntimeClass.

С помощью RuntimeClass можно сообщить Kubernetes, какие container runtime’ы поддерживают ноды кластера. Это позволяет кластеру запускать как традиционные поды на базе Linux-контейнеров, так и более изолированные поды на gVisor или Kata Containers.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx-kata-qemu
spec:
  runtimeClassName: kata-qemu
  containers:
    - name: nginx
      image: nginx:alpine
EOF

Узнайте, как регистрировать новые RuntimeClass’ы и запускать поды с произвольными именами runtime class, в практическом туториале от Márk Sági-Kazár: https://labs.iximiuz.com/tutorials/kubernetes-runtime-class-61506808

👉 DevOps Portal

Новая фича Kubernetes 1.36: Image Volumes

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

Но чтобы использовать такой image-артефакт, раньше приходилось сначала pull’ить образ, а затем распаковывать его содержимое в директорию, доступную приложению. В Kubernetes это обычно означало дополнительный init container с набором кастомных скриптов.

К счастью, в Kubernetes v1.36 появился более чистый подход — image volumes. Теперь можно напрямую монтировать файловую систему OCI-образа в Pod как read-only volume.

Небольшой hands-on челлендж, чтобы попробовать это в деле: https://labs.iximiuz.com/challenges/kubernetes-pod-image-volume

👉 DevOps Portal

DevOps-инструмент недели: Kafbat UI

Запускать Kafka в проде – это здорово, ровно до того момента, когда нужно залезть внутрь и посмотреть, что там происходит

Kafbat UI — бесплатный open-source веб-интерфейс для мониторинга и управления кластерами Apache Kafka.
Он даёт единое окно управления всеми вашими Kafka-кластерами.

Брокеры, топики, партиции, consumer groups, schema registry, Kafka Connect – всё собрано в одном дашборде.

Можно просматривать сообщения в форматах JSON, Avro и Protobuf, фильтровать live-потоки через CEL-выражения, смотреть consumer lag по каждой партиции, а также создавать и перенастраивать топики без необходимости лезть в CLI.

GitHub-репозиторий:
Kafbat UI GitHub Repository

👉 DevOps Portal

Эта фича Kubernetes меняет то, как контейнеры работают с root-привилегиями

User Namespaces — это механизм безопасности, который сопоставляет ID пользователей и групп внутри контейнера с другим набором ID на хосте. По сути, это rootless-изоляция.

Ключевая идея такая.

Процесс, который запускается от root внутри контейнера, на хосте выполняется от имени непривилегированного пользователя, например с UID 100000.

Без User Namespaces контейнер, запущенный от root, использует ту же root-идентичность, что и хост.

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

Вот практический гайд, в котором разобрали следующее:
- что такое User Namespaces;
- как ядро выполняет маппинг root-пользователя на non-root пользователя;
- что меняется при установке hostUsers: false;
- как ограничивать диапазоны UID на хосте с помощью файла /etc/subuid;
- практический деплоймент для понимания User Namespace;
- ограничения User Namespace.

Читать здесь: https://newsletter.devopscube.com/p/kubernetes-user-namespaces

👉 DevOps Portal

Это руководство показывает, как построить локальную data platform с использованием KinD для Kubernetes и Terraform для провижининга инфраструктуры, а также Argo CD в качестве GitOps-движка для деплоя и управления приложениями.

➤ Ссылка на руководство

👉 DevOps Portal

Наглядное руководство по основам Systemd

Статья подробно и наглядно раскрывает внутреннее устройство systemd, делая акцент на ключевых компонентах D-Bus и cgroups, и объясняет, как устроена их архитектура и взаимодействие на примерах и схемах

https://medium.com/@sebastiancarlos/systemds-nuts-and-bolts-0ae7995e45d3

👉 DevOps Portal

GitHub Actions + AWS без долгоживущих секретов?

Современные DevOps-пайплайны не должны зависеть от захардкоженных AWS access keys.

Потому что утекшие CI/CD-учётные данные всё ещё остаются одним из самых серьёзных рисков для безопасности в облаке.

Именно здесь помогает OIDC.

Вместо того чтобы хранить AWS-секреты в GitHub, ваш workflow во время выполнения получает краткоживущие временные credentials напрямую от AWS.

- Никаких статических ключей.
- Никакой головной боли с ротацией секретов.
- Меньший blast radius, если что-то пойдёт не так.

В этом блоге разберем интеграцию GitHub Actions OIDC с AWS на пошаговом примере, который помогает безопасно настроить доступ к AWS cloud.

К концу этого гайда вы поймёте:
- Почему OIDC — это безопасный способ подключить GitHub Actions к AWS
- Как интеграция GitHub OIDC работает с AWS
- Как пошагово настроить OIDC через IAM roles
- Как протестировать настройку через AWS CLI и задеплоить в EKS с помощью GitHub Actions workflows

Подробный блог: https://devopscube.com/github-actions-oidc-aws/

👉 DevOps Portal