kubectl-ai выступает как интеллектуальный интерфейс, преобразующий намерения пользователя в точные операции Kubernetes

GitHub: kubectl-ai

👉 DevOps Portal

Пойми Rate Limiting за 40 секунд

👉 DevOps Portal

Архитектура Kubernetes Kubelet – объяснение простыми словами

Эта схема показывает, что на самом деле происходит внутри Kubernetes Node.

Поток:

1️⃣ API Server
→ Отправляет PodSpec (желаемое состояние)

2️⃣ Главный цикл Kubelet (Kubelet Main Loop)
→ Непрерывно сверяет и приводит в соответствие желаемое и фактическое состояние

3️⃣ Pod Workers (параллельно)
→ Независимо обрабатывают жизненный цикл каждого пода

4️⃣ Слой CRI
→ Kubelet → CRI → Container Runtime (containerd / CRI-O)

5️⃣ Image Manager
→ Пуллит образы и выполняет их garbage collection (очистку/удаление неиспользуемых)

6️⃣ Volume Manager
→ Монтирует / размонтирует тома

7️⃣ PLEG
→ Отслеживает изменения состояния контейнеров

8️⃣ Status Manager
→ Отправляет статус пода обратно в API Server
(IP, Phase, Conditions)

Ключевая идея:
Kubelet – это reconciliation-движок.

Он постоянно гарантирует:

Desired State = Actual State

Именно за счёт этого Kubernetes обеспечивает self-healing (самовосстановление кластера).

👉 DevOps Portal

Если ты регулярно работаешь с Kubernetes, без kubectl никуда. В статье – компактный референс по ключевым командам: поды, деплои, сервисы, секреты и дебаг.

Есть всё базовое: переключение контекстов, scaling, rollout’ы, resource limits и типовые кейсы отладки (краш подов, недоступные сервисы). Удобная шпаргалка, когда нужен быстрый ответ прямо в кластере.

https://dev.to/code_cursor/kubernetes-cheat-sheet-essential-kubectl-commands-for-developers-43mn

👉 DevOps Portal

Terraform Actions – фича, которую нужно знать

Terraform отлично справляется с CRUD-операциями – созданием, чтением, обновлением и удалением инфраструктуры.

Но что насчёт всего, что происходит после того, как инфраструктура уже развернута?

Например, вызов Lambda-функции при необходимости.

До версии v1.14 приходилось использовать обходные решения – provisioner’ы (local-exec или remote-exec) либо внешние скрипты.

С появлением Actions в v1.14 теперь такие операции можно выполнять с помощью нативных action-блоков Terraform, встроенных непосредственно в провайдеры (например, AWS Provider).

В этой статье:
- что такое Terraform Actions и зачем их добавили
- типовые use case’ы и стандартный workflow
- практический пример, чтобы посмотреть, как это работает на практике

Читать здесь: https://newsletter.devopscube.com/p/terraform-actions-explained

Примечание: это новая фича, и поддержка со стороны провайдеров всё ещё постепенно появляется. Например, у AWS сейчас доступно только три actions.

👉 DevOps Portal

Как защититься от зараженных PDF и документов? 🤓

Если вы сомневаетесь в безопасности файла, обратите внимание на тулзу Dangerzone

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

Dangerzone имеет как Windows версию, так и на Mac и Linux

👉 DevOps Portal

IP-адреса за 6 минут

👉 DevOps Portal

Пойми, как работает firewall, за 45 секунд

👉 DevOps Portal

Почему важно менять версии Helm Chart?

Когда вы пакуете и публикуете Helm chart, именно версия чарта отслеживается репозиториями.

Не теги образов.
Не версия вашего приложения.

Если вы изменили шаблоны, но не увеличили версию чарта:

- Репозиторий будет считать это тем же самым релизом.
- Ваш CI/CD-пайплайн будет использовать закэшированные артефакты.
- Кластер не обнаружит изменений при выполнении upgrade.

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

Поле appVersion — это всего лишь метаданные о версии вашего приложения. Оно не влияет на упаковку чарта и индексацию в репозитории.

Поэтому если вы просто обновили тег образа в values.yaml и забыли увеличить версию чарта, инструменты, которые на неё опираются, не распознают новый релиз.

Всегда увеличивайте поле version в Chart.yaml, когда меняете любой файл внутри чарта.

Подробный блог:
https://devopscube.com/create-helm-chart/

👉 DevOps Portal

Один из ключевых трюков, лежащих в основе Service Mesh — это прозрачный перехват трафика. Такой прокси, как Envoy, можно разместить на сетевом пути между двумя сервисами, даже не давая им понять, что он вообще существует.

eBPF — одна из тех "магических" технологий, с помощью которых можно реализовать такой прозрачный перехват трафика.

Узнайте, как реализовать перехват исходящего трафика, а заодно прокачать навыки программирования на eBPF, в свежем туториале Теодора Подобника:
https://labs.iximiuz.com/tutorials/ebpf-envoy-egress-dc77ccd7

👉 DevOps Portal

Узнайте, как с помощью GPT и Claude построить полноценную мульти-средовую платформу Kubernetes.

От k3s до продакшн-кластеров, с использованием GitHub Actions, Traefik, Helm и PostgreSQL – полностью автоматизированная DevOps-архитектура, собранная с помощью AI.

Читайте тут

👉 DevOps Portal

Уменьшил Docker-образ с 1.37 GB → 168 MB.

Всего лишь за счёт использования multi-stage сборок, slim-базовых образов и очистки неиспользуемых зависимостей.

Небольшие оптимизации = более быстрый CI/CD и более безопасные контейнеры 👍

👉 DevOps Portal