Быстрый совет по Kubernetes: Доступ к терминалу пода

Используйте команду exec, чтобы открыть шелл в запущенном контейнере внутри пода.

👉 DevOps Portal

С выходом Kubernetes 1.34 Mutating Admission Policy перешла в бета-стадию.

В честь этого принес подробный туториал про admission control в Kubernetes: тык

Загляните, если интересует глубокий разбор admission control в Kubernetes

👉 DevOps Portal

KubeHatch — это web-UI и CLI-инструмент, который позволяет поднимать виртуальные Kubernetes-кластеры (vCluster) по запросу внутри реального Kubernetes-кластера.

Забираем на GitHub

👉 DevOps Portal

Вертикальное масштабирование пода без перезапуска стало возможным начиная с Kubernetes v1.33.

Обычно, если вы хотели выдать приложению (Pod в Kubernetes) больше памяти или CPU, его приходилось перезапускать.

Это ок, если приложение спокойно относится к перезапускам, но есть такие, которым остановки/старты противопоказаны: базы данных, тяжёлые batch-задачи или штуки, которым нужна ровная непрерывная работа.

Бета

Новая фича «in-place Pod resize» позволяет менять объём памяти и CPU у Pod, пока он продолжает работать. Начиная с версии 1.33 она считается достаточно зрелой для обычного использования и включена по умолчанию. До этого нужно было включать фича-гейт InPlacePodVerticalScaling.

Как

Вместо обычного kubectl edit по Pod используется специальный подресурс /resize. Например, можно сделать patch так:

kubectl patch pod mypod --subresource=resize ....

Это похоже на то, как устроены другие возможности Kubernetes. Например:

🔹/status — подресурс, которым можно обновлять только поле status объекта, не трогая его spec.

🔹/scale — подресурс у Deployment или StatefulSet, позволяющий менять количество реплик без редактирования всего манифеста.

Аналогично, /resize — подресурс у Pod, который позволяет менять ресурсы на месте.

Важно: это применяется к отдельным Pod. Если запустить kubectl set resources на Deployment, StatefulSet или Job, это всё равно поменяет шаблон и породит новые Pod, а не сделает in-place изменение.

Увеличивать CPU просто, увеличение памяти обычно проходит, если на узле есть свободная ёмкость. Уменьшать CPU тоже легко, а вот уменьшение памяти — самый сложный кейс и может провалиться, быть отложено или потребовать перезапуск в зависимости от политики. Чтобы понимать, как идёт процесс, следите за полями status и conditions у Pod.

Политика ресайза

Каждый контейнер в спецификации Pod может задать resizePolicy. Внутри этого поля CPU и память перечисляются отдельно, и для каждого выбирается политика перезапуска. Доступны два значения:

🔹NotRequired: Kubernetes попытается изменить значения ресурсов на месте, пока контейнер работает. Это значение по умолчанию. Это best-effort: если рантайм не может безопасно применить изменение (особенно при уменьшении памяти), операция завершится ошибкой вместо принудительного перезапуска.

🔹RestartContainer: чтобы применить новые настройки ресурсов, Kubernetes обязан перезапустить контейнер. Полезно для приложений, которые читают лимиты ресурсов только при старте, например некоторые JVM-нагрузки.

Пример:

resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

Источник

👉 @GolangPortal

Логирование в Kubernetes с помощью EFK

kubectl logs подходит для маленьких сетапов, но сотни подов на множестве нод? Полный хаос. Здесь и выручает стек EFK (Elasticsearch + Fluent Bit/Fluentd + Kibana).

Как это работает:

- Поды генерируют логи → stdout/stderr
- Container runtime перехватывает логи → складывает их в /var/log/containers/
- Fluent Bit собирает, обрабатывает и эффективно форвардит логи
- Elasticsearch хранит и индексирует логи для поиска почти в реальном времени
- Kibana позволяет визуализировать, исследовать и строить дашборды

👉 DevOps Portal

Что такое Service Discovery и как его реализует Kubernetes? 🧐

Понимание того, что такое SD, — ключ к тому, чтобы разобраться в разных типах сервисов Kubernetes. Узнайте про server-side vs client-side service discovery и гибридный подход Kubernetes здесь:
https://iximiuz.com/en/posts/service-discovery-in-kubernetes/

👉 DevOps Portal

Kubeconform — это инструмент для валидации манифестов Kubernetes

Аналогичен Kubeval, но с рядом улучшений:

🔹Высокая производительность.

🔹Поддержка схем как из удалённых, так и из локальных источников.

🔹Актуальные схемы для всех последних версий Kubernetes.

Подробнее: https://github.com/yannh/kubeconform

👉 DevOps Portal

Docker 101: создание, запуск, остановка и удаление контейнеров

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

Исследуйте двойственную природу контейнеров (практика):
https://labs.iximiuz.com/challenges/docker-101-container-stop-and-restart

👉 DevOps Portal

Grogg — GUI-клиент для Kubernetes, который работает локально или как расширение для VSCode.

Он помогает выполнять действия вроде масштабирования или триггера Cron Job’ов, а также смотреть агрегированные логи подов без CLI и облачных дашбордов.

➜ https://grogg.app/

👉 DevOps Portal

Практика по Docker: остановка и перезапуск контейнеризированного приложения с сохранением данных

Задумывались, куда пропали записи вашей БД после выполнения docker compose down? Если да, этот челлендж для вас

Разберитесь во всех нюансах персистентности rootfs здесь

👉 DevOps Portal

Стратегии деплоя в Kubernetes, не такие уж сложные для понимания. Вот упрощенная инфографика

👉 DevOps Portal

OpenObserve — cloud-native платформа наблюдаемости, специально созданная для логов, метрик, трейсов, аналитики и RUM (Real User Monitoring — производительность, ошибки, воспроизведение сессий), спроектированная для работы в петабайтном масштабе

https://github.com/openobserve/openobserve

👉 DevOps Portal

В сети поделились секретом, как правильно обновить Kubernetes: без падения прода

👉 DevOps Portal

На YouTube вышел свежий англоязычный курс по DevOps. Собираем и деплоим масштабируемый продакшен-готовый API

Быстро освоите базу DevOps в этом крэш-курсе, охватывающем Git и GitHub, CI/CD-пайплайны, Docker, Kubernetes, IaC и деплой API. Всё, что нужно, чтобы автоматизировать разработку и деплой

5 часов контента здесь

👉 DevOps Portal

Создаём контейнер наподобие Docker с нуля

Освойте ключевые пространства имён Linux, собрав небольшой, но реалистичный контейнер, используя только штатные команды Linux: unshare, mount и pivot_root. Никакой магии рантайма и (почти) никаких упрощений.

Изучаем здесь

👉 DevOps Portal

Что будет с вашими данными, если система упадёт до того, как они будут сохранены?

Здесь и появляется концепция Write-Ahead Log (WAL).

Это простой принцип проектирования систем.

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

- Как только запись надёжно зафиксирована в логе, система обновляет реальную базу данных или хранилище.

- Если система падает, вы можете воспроизвести лог (система читает сохранённые шаги), чтобы вернуть данные в корректное состояние.

Вот короткое руководство, которое охватывает несколько реальных кейсов:
https://newsletter.devopscube.com/p/write-ahead-log-wal

👉 DevOps Portal

Как работают Kubernetes Services?

Вероятно, вы знаете, что где-то там замешаны iptables, но знаете ли вы точную последовательность цепочек, задействованных при маршрутизации трафика к ClusterIP? А как насчёт NodePort - там по-другому?

Вот очень подробная статья, разбирающая всю «магию» за сервисами Kubernetes, простыми словами объясняя базовые вещи и продвинутые темы, такие как сохранение исходных IP, обработка завершающихся endpoints и интеграция с облачными балансировщиками нагрузки.

Читайте здесь

👉 DevOps Portal

CLI-утилита Kubernetes Resource Recommender помогает оптимизировать выделение ресурсов в кластерах Kubernetes.

Она собирает метрики использования подов из Prometheus и рекомендует значения requests и limits для CPU и памяти.

Это снижает расходы и повышает производительность.

Забираем на GitHub

👉 DevOps Portal

Годная шпаргалка по cron в Linux с примерами

👉 DevOps Portal

Быстрый совет по Linux

При просмотре файла через less можно вывести краткий статус, нажав клавишу =.

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

👉 DevOps Portal

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

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

Однако иногда может потребоваться использовать тома, чтобы сделать некоторые части файловой системы контейнера более долговечными, чем остальные. С томами, даже если вы полностью удалите контейнер (а не просто перезапустите его), вы сможете продолжить использовать данные приложения в контейнере-преемнике (например, то же приложение, но на более новом образе).

Попрактикуйтесь в использовании томов Docker в этом практическом задании здесь

👉 DevOps Portal