etcd в Kubernetes: разбираемся с задержками

Эта статья будет полезна DevOps-инженерам, SRE-специалистам и всем, кто работает с Kubernetes и хочет глубже понять его внутренние механизмы. Если вы настраиваете, масштабируете или устраняете неполадки в кластере K8s, важно разобраться в etcd — распределенном key-value-хранилище, которое лежит в основе отказоустойчивости Kubernetes.

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

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

https://habr.com/ru/companies/chislitellab/articles/934526/

original https://www.redhat.com/en/blog/a-guide-to-etcd

#devops #девопс

Подпишись 👉@i_DevOps

Успех секрета: как доставлять секреты в приложения безопасно и без головной боли

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

https://habr.com/ru/companies/flant/articles/932862/

#devops #девопс

Подпишись 👉@i_DevOps

Как работает Docker

#devops #девопс

Подпишись 👉@i_DevOps

Docker изнутри: исчерпывающее руководство. Механизмы контейнеризации + примеры, эксперименты и реализация

Docker — не магия, а грамотное применение механизмов Linux. Разбираем инструмент, который пугает своей сложностью не меньше блокчейна. Показываем на пальцах как работают: Namespaces, Cgroups, OverlayFS – основные компоненты любого контейнера, и как стандарт OCI объединяет их в единую экосистему. Об этом и не только в статье.

https://habr.com/ru/articles/935178/

#devops #девопс

Подпишись 👉@i_DevOps

Как динамически рассчитывать CPU для контейнеров в Kubernetes

Включена возможность динамического изменения CPU для контейнеров в Kubernetes с помощью фичи InPlacePodVerticalScaling.

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

Стратегия 1: всегда использовать 80% CPU

Если приложение загружено на 50%, увеличиваем до 80% — оставляем запас в 20 % для безопасности.

Работает отлично при уменьшении, но при увеличении — вопрос: если используем 100 %, стоит ли удвоить CPU или немного прибавить? Ответ неизвестен.

Стратегия 2: всегда использовать 80%, плюс экспоненциальный рост

Как и в стратегии 1 при уменьшении. При увеличении (при нагрузке между 80 и 100 %) используется формула:

new_cpu = average_cpu / 0.8 + (average_cpu / 0.8 * coeff)²

Экспоненциальное увеличение: сильно растем, если нагрузка 100 %, и умеренно — если 90 %. Эту стратегию легко применять: она используется в инструменте Kondense для подбора ресурсов в Kubernetes.

Стратегия 3: целевое использование 100% с учетом CPU-pressure

При уменьшении — устанавливаем на 100%, чтобы не терять ресурсы. При увеличении — смотрим на CPU pressure в микросекундах (время, которое контейнер не мог получить CPU). Чем выше давление, тем сильнее нужно увеличить CPU.

Теоретически это оптимально. Но на практике не всегда работает: порой CPU pressure высок, но увеличение CPU не помогает — зависит от характера приложения. Потребуется доработка формулы под конкретные кейсы.


Итог:
Динамическое изменение CPU — значительный шаг для Kubernetes. В будущем это позволит экономить ресурсы и развязывать руки администраторам. Уже сейчас стоит ознакомиться с инструментом Kondense, если планируете автоматизацию подбора ресурсов.


https://medium.com/@mathieuces/how-to-calculate-cpu-for-containers-in-k8s-dynamically-47a89e3886eb

#devops #девопс

Подпишись 👉@i_DevOps

#devops #девопс

Подпишись 👉@i_DevOps

GitButler

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

В двух словах, это более гибкая версия git add -p и git rebase -i, позволяющая эффективно работать в нескольких ветках.

https://github.com/gitbutlerapp/gitbutler

#devops #девопс

Подпишись 👉@i_DevOps

В Ansible роли есть директории file и templates. Что они содержат и чем отличаются?

files — содержит файлы, которые будут скопированы на настраиваемые хосты; так же — может содержать скрипты, которые позже будут запускаться на хостах.

templates — содержит шаблоны файлов с переменными.

#devops #девопс

Подпишись 👉@i_DevOps

Как работает докер🐳

#devops #девопс

Подпишись 👉@i_DevOps

🚀 GitHub Actions + Terraform: автоматизация деплоя с ревью плана изменений

Terraform стал стандартом для управления инфраструктурой как кодом (IaC). Но просто запускать terraform apply в CI/CD — не лучший вариант. Важно видеть план изменений до деплоя, чтобы избежать неожиданных последствий.

В статье показано, как интегрировать Terraform с GitHub Actions так, чтобы каждый pull request автоматически запускал terraform plan. Результаты работы добавляются прямо в PR, где команда может просмотреть и обсудить изменения до их применения.

Таким образом:

- при открытии PR → генерируется план, прикрепляется к обсуждению;
- после ревью и мержа → автоматически выполняется terraform apply.

Это позволяет:
✅ повысить прозрачность изменений в инфраструктуре
✅ избежать ошибок при деплое
✅ упростить командную работу с IaC

Отличный пример того, как CI/CD можно использовать не только для приложений, но и для инфраструктуры.

https://itnext.io/github-actions-terraform-deployments-with-a-review-of-planned-changes-30143358bb5c

#devops #девопс

Подпишись 👉@i_DevOps

SSO через Keycloak для инфраструктурных сервисов: часть 1, теория

Если вы хоть раз настраивали доступ к Grafana, Argo CD, Vault или Prometheus и сталкивались с аутентификацией «на костылях», значит, тоже задавались вопросом: почему бы не сделать это один раз и правильно — через SSO?

Эта первая часть разбора мастер-класса с DevOpsConf 2025 от Алексея Цыкунова, CTO Hilbert Team.

https://habr.com/ru/companies/oleg-bunin/articles/936338/

#devops #девопс

Подпишись 👉@i_DevOps

SSO через Keycloak для инфраструктурных сервисов: часть 2, практика

В первой части мы разобрали, как устроен Keycloak, какие у него сущности и зачем вообще нужен SSO в DevOps-инфраструктуре. Теперь — к делу. Во второй части переходим от теории к практике. Разворачиваем Keycloak в Kubernetes, настраиваем Terraform-провайдер, подключаем к нему Grafana, Argo CD и другие сервисы. Разбираемся, как выглядят реальные конфигурации клиентов, scopes и mappings, чтобы SSO действительно работал — с нужными токенами, ролями и группами.

https://habr.com/ru/companies/oleg-bunin/articles/936866/

#devops #девопс

Подпишись 👉@i_DevOps

Что такое пейджинг по требованию?

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

#devops #девопс

Подпишись 👉@i_DevOps

#devops #девопс

Подпишись 👉@i_DevOps

Шпаргалка по командам GitHub

#devops #девопс

Подпишись 👉@i_DevOps

ContainerSSH

SSH-сервер, который запускает контейнеры в Kubernetes и Docker

https://github.com/ContainerSSH/ContainerSSH

#devops #девопс

Подпишись 👉@i_DevOps