💡 Лучшие практики работы с Helm: что нужно знать

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

📦 1. Структура директорий чарта
Соблюдайте стандартную структуру чарта Helm:

mychart/
  charts/
  templates/
  values.yaml
  Chart.yaml
  README.md

Избегайте добавления нестандартных файлов и директорий. Это сделает чарты переносимыми и читаемыми.

🧩 2. Разделяйте общие шаблоны
Используйте _helpers.tpl для определения общих шаблонов, таких как аннотации, метки и имена ресурсов. Это снижает дублирование и упрощает сопровождение:

{{/* Генерация полного имени */}}
{{- define "mychart.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

⚙️ 3. Используйте параметры в values.yaml
Делайте чарты гибкими, передавая конфигурации через values.yaml. Никогда не хардкодьте значения в шаблонах.

🧪 4. Валидация values.yaml
Добавляйте проверку обязательных значений с помощью required:

{{ required "Variable mychart.image.repository is required" .Values.image.repository }}

🔍 5. Используйте шаблоны if/else разумно
Старайтесь не перегружать шаблоны логикой. Разделяйте шаблоны на несколько файлов, если они становятся слишком сложными.

🗃️ 6. Не добавляйте чарт в шаблон напрямую
Вместо включения зависимостей в директорию charts/, указывайте их в Chart.yaml и используйте helm dependency update.

🛑 7. Не хардкодьте версии образов
Передавайте версию через values.yaml. Это повышает гибкость CI/CD:

image:
  repository: nginx
  tag: "1.21.1"

🔒 8. Управление чувствительными данными
Не храните пароли и токены в values.yaml. Используйте секреты Kubernetes или инструменты типа Sealed Secrets или External Secrets.

🔁 9. Helm hooks
Helm предоставляет хуки для выполнения задач до/после установки. Используйте их, например, для миграций БД. Пример:

annotations:
  "helm.sh/hook": pre-install

🧹 10. Чистка старых релизов
Используйте helm uninstall и регулярно проверяйте статус релизов с помощью helm list. Это помогает избегать конфликта имён и мусора.

🧪 11. Тестирование чарта
Добавляйте unit-тесты с помощью helm unittest и не забывайте про проверку синтаксиса:

helm lint .

🔄 12. Автоматизация через CI/CD
Интегрируйте Helm в пайплайны CI/CD для установки и обновления чартов — например, с помощью GitLab CI, GitHub Actions, ArgoCD или Flux.


Придерживайтесь этих рекомендаций — и работа с Helm станет надёжной, устойчивой и более предсказуемой. Это особенно важно при масштабировании инфраструктуры и работе в команде.

📲 Мы в MAX

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

Блокировка состояния Terraform с использованием S3 (без DynamoDB)

В этом посте мы рассмотрим:

- Зачем нужна блокировка состояния Terraform
- Блокировка состояния с помощью DynamoDB
- Блокировка состояния только с использованием S3, без DynamoDB
- Когда стоит использовать DynamoDB
- Когда можно обойтись только S3
- Лучшие практики хранения state-файлов в S3

https://devopscube.com/terraform-state-locking-with-s3/

📲 Мы в MAX

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

Addon Controller

Sveltos Addon Controller позволяет пользователям применять Kubernetes-манифесты к любым кластерам, управляемым Sveltos. Это может быть сделано следующими способами:

- Добавляя YAML-файлы с Kubernetes-ресурсами в ConfigMap или Secret.
- Указывая URL с YAML-ресурсами.
- Указывая Helm-чарт.

Addon Controller – это контроллер Kubernetes, который работает в управляющем кластере (management cluster). Он следит за созданием и обновлением объектов Addon, а также применяет соответствующие манифесты в целевых (managed) кластерах, на которые ссылается Addon.

Возможности

- Поддержка ConfigMap, Secret, URL и Helm-чартов.
- Поддержка переменных через ClusterProfile и ClusterSummary.
- Возможность динамически применять или удалять аддоны при изменении кластера или его свойств.
- Возможность настройки приоритетов применения ресурсов.
- Поддержка зависимостей между ресурсами.
- Поддержка dry-run и прерывания применения при ошибке.

Архитектура

1. Пользователь создает объект ClusterProfile, в котором указывает критерии выбора кластеров.
2. Для каждого подходящего кластера создается объект ClusterSummary, который содержит список Addon объектов.
3. Addon Controller применяет ресурсы, указанные в Addon, к каждому целевому кластеру.


https://github.com/projectsveltos/addon-controller?tab=readme-ov-file

📲 Мы в MAX

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

🔥 Как ускорить docker build и сократить размер образа

Иногда docker build тянется вечность, а итоговый образ весит больше, чем база данных 🐘. Разбираемся, как ускорить сборку и оптимизировать размер образа без потери функциональности.


1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):

# Стадия 1: билд
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o app

# Стадия 2: минимальный runtime
FROM alpine:latest
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["app"]

Образ получается меньше 10 МБ!


2. Минимизируй base image
Используй alpine, distroless, scratch, если не нужен полноценный дистрибутив:

FROM python:3.12-slim

Или вообще:

FROM scratch

3. Правильно расставляй COPY и RUN
Кешируй слои — сначала зависимости, потом исходники:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Так pip install не будет повторяться при каждом изменении исходников.


4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:

RUN apt-get update && apt-get install -y ... \
 && rm -rf /var/lib/apt/lists/*

5. Используй .dockerignore
Иначе в билд попадут node_modules, .git, логи и прочее:

.git
node_modules
*.log

Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай — docker build тоже надо профилировать.

#devops #docker #ci #optimization

📲 Мы в MAX

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

🚀 Ищем Kubernetes Platform Engineer (Middle+/ Senior) в 2ГИС

В команде Infrastructure & Operations мы строим внутреннюю PaaS-платформу для Data Services: PostgreSQL, Redis, Kafka, ClickHouse.

Наша цель — сделать DBaaS и DS self-service, надёжной и стандартизированной частью платформы для десятков продуктовых команд.
Что будешь делать:

• Развивать PaaS на базе Kubernetes

• Автоматизировать lifecycle DS (deploy, scale, backup, restore)

• Строить DBaaS (начинаем с PostgreSQL)

• Внедрять GitOps, IaC и платформенные стандарты

Наш стек

Kubernetes, GitLab CI/CD, Terraform, Ansible, ELK, Vault, S3.
Ищем инженера, который понимает Kubernetes как платформу, работал со stateful-нагрузками и тюнил PostgreSQL.

Удалёнка или офис. Белая зарплата, ДМС, обучение и конференции — всё по-взрослому.

👉Откликайся

Другие инженерные инсайты от 2ГИС →в Telegram-канале RnD

🚀 Kubernetes под ML-нагрузки на bare metal + H100: пошагово и без прикрас

Если вы строите ML-платформу в корпоративной среде (RBAC, изоляция, безопасность) и при этом хотите нормально утилизировать GPU - в Совкомбанк Технологии поделились реальным опытом: что пробовали, где «сломалось», и к какой архитектуре в итоге пришли.

Что внутри:

• почему идея держать две ML-платформы в одном кластере (taints/labels) упирается в конфликты компонентов и риски ИБ;

• как разнесли всё на два независимых кластера, чтобы обновления и безопасность не превращались в боль;

• практический гайд по установке драйверов NVIDIA и типовым ошибкам (DKMS, модуль ядра, container runtime и т.д.);

• деплой GPU Operator;

• самое вкусное - MIG на H100: как включать профили через label’ы нод, какие профили выбирать под inference/training и что делать, когда MIG-инстанс недоступен (Pending, failover/retry и т.п.);

• в конце - базовые шаги по деплою Kubeflow 1.10 и что ожидать в дебаге.

🧩 Это тот редкий материал, где есть и «как сделать», и «почему так делать не стоит», и конкретные команды.

Читать: https://habr.com/ru/companies/sovcombank_technologies/articles/994534/

📲 Мы в MAX

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

🔥 Ускоряем сборку Docker-образов: слои и кэш - наши друзья

Когда сборка Dockerfile занимает минуты - это мешает dev-loop'у. А ведь можно сильно ускориться с парой простых правил 👇


🧠 Основные принципы ускорения:

1. Максимально используем кэш
Docker кэширует каждый слой. Если слой не изменился - пересобирать не будет.

➤ Сначала COPY зависимости, потом остальной код:

   COPY requirements.txt .
   RUN pip install -r requirements.txt  # кэшируется

   COPY . .  # некэшируемо при любом изменении в коде
   

2. Объединяем RUN-команды
Меньше слоёв - быстрее сборка и push:

   RUN apt update && apt install -y curl git \
       && rm -rf /var/lib/apt/lists/*
   

3. .dockerignore
Убедись, что не копируешь лишние файлы (например, .git/, tests/, node_modules/):

   .git
   node_modules
   *.log
   __pycache__/
   

4. Меньше COPY, больше multi-stage
Разделяй сборку и runtime - не таскай компиляторы в прод:

   FROM golang:1.20 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o app

   FROM debian:bullseye-slim
   COPY --from=builder /app/app /usr/bin/app
   CMD ["app"]
   

5. Кэшируй pip/npm/go-пакеты
→ в Dockerfile сначала копируй файл зависимостей, ставь пакеты, только потом - весь код проекта.


📌 Используй эти практики, чтобы ускорить CI/CD, локальную сборку и деплой. Чем меньше слоёв изменяется - тем быстрее весь процесс.


📲 Мы в MAX

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

⚡️Платите меньше за хранение логов и бэкапов

Выберите подходящий класс хранилища в Selectel S3 и сократите расходы на хранение до 30%.

Первый месяц по акции «миграционные каникулы» — бесплатно.

👉 Оставьте заявку и перенесите данные в Selectel: https://slc.tl/2devp

Реклама. АО "Селектел". erid:2W5zFGL2WQ1

🔥 Как ускорить GitHub Actions на 40% и платить меньше

CI - это не место для медлительности. Особенно когда билд идёт 15 минут, а запусков в день сотни. Сейчас разберём, как оптимизировать GitHub Actions: быстрее, дешевле, эффективнее.


🔹 1. Используйте actions/cache правильно
Загрузка и компиляция зависимостей одно из самых дорогих мест. Добавьте кэширование для npm, pip, go mod, docker layers. Пример для Node.js:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

⚠️ Не кэшируйте build-артефакты, которые зависят от среды (OS, runner version) - это приведёт к нестабильности.


🔹 2. Job matrix + fail-fast: false = контроль над параллелизмом
Matrix позволяет запускать тесты параллельно (например, разные версии Python), а fail-fast: false не останавливает все джобы при первом фейле.

strategy:
  fail-fast: false
  matrix:
    python-version: [3.8, 3.9, 3.10]

🔹 3. Разделяйте пайплайн на reusable workflows
Выносите повторяющуюся логику в .github/workflows/reusable.yml и вызывайте с параметрами. Это уменьшает дублирование и ускоряет поддержку.

- uses: ./.github/workflows/reusable.yml
  with:
    env: staging

🔹 4. Используйте self-hosted runners, если билд тяжёлый
Если у вас сборка Docker-образов весит десятки минут - дешевле и быстрее поднять свои раннеры в EC2 или Kubernetes (особенно с GPU или кастомной средой).

📌 Попробуйте actions-runner-controller для Kubernetes:
https://github.com/actions/actions-runner-controller


🔹 5. Откажитесь от setup-* при каждом запуске
setup-node, setup-go, setup-java - удобны, но каждый раз качают и устанавливают SDK. Замените на preinstalled версии в раннерах или кэшируйте вручную.


✅ Вывод:
Оптимизация GitHub Actions - это про кэш, параллельность и минимизацию накладных расходов. Даже простые изменения могут ускорить пайплайн в 2–3 раза. А главное - вы перестаёте платить за простой.


🔥 Ресурсы:
- Официальная дока по кэшу https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

📲 Мы в MAX

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

CI/CD пайплайны на стероидах: 5 фишек для ускорения сборок 🚀

⏱ Устали ждать, пока пройдут все джобы в CI? Время — деньги, особенно на продакшене. Вот 5 проверенных способов прокачать скорость и стабильность пайплайнов.


1. Кэширование зависимостей — must have
Кэшируйте node_modules, .m2, Docker-слои или Python virtualenv.
В GitHub Actions:

   - uses: actions/cache@v3
     with:
       path: ~/.npm
       key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
   

2. Matrix strategy для параллельных задач
Разбейте тесты по окружениям, версиям или компонентам:

   strategy:
     matrix:
       python: [3.9, 3.10]
   

3. Docker Layer Caching (DLC)
В GitLab CI включайте DLC:

   variables:
     DOCKER_DRIVER: overlay2
     DOCKER_TLS_CERTDIR: ""
   services:
     - docker:dind
   

4. Пропускайте джобы при отсутствии изменений
Нет изменений в директории — не триггери билд. В GitHub Actions:

   on:
     push:
       paths:
         - 'src/**'
         - '!docs/**'
   

5. Self-hosted runners для тяжёлых задач
Сильная машина с нужными зависимостями сэкономит десятки минут. Плюс — контроль среды и логирования.


Вывод:
Оптимизация CI/CD — это не про магию, а про дисциплину: кэш, параллелизм, условные шаги и правильные раннеры. Регулярно профилируйте пайплайны и фиксируйте bottlenecks.

#devops #девопс

📲 Мы в MAX

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

Kubernetes: секреты быстрого rollback без боли и даунтайма

🔄 Rollback — неотъемлемая часть стабильного продакшена. Но сколько раз он превращался в хаос? Рассмотрим, как грамотно настроить откат в Kubernetes, чтобы не терять трафик, не ловить панику и не тратить часы на ручное восстановление.


🔹 1. Стратегия деплоя имеет значение

По умолчанию Deployment использует стратегию RollingUpdate. Это безопасно, но не всегда быстро. Убедись, что параметры maxUnavailable и maxSurge оптимальны:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

➡️ Это даст zero downtime, но при большом количестве реплик откат будет медленным. Подстрой под нагрузку.


🔹 2. Используй kubectl rollout undo

Kubernetes хранит предыдущие ReplicaSets, так что простой rollback — дело одной команды:

kubectl rollout undo deployment my-app

Проверь текущую ревизию:

kubectl rollout history deployment my-app

📝 Храни истории изменений в git — манифесты должны быть version-controlled.


🔹 3. Хелм под капотом? Настрой helm rollback

Если ты используешь Helm, rollback проще:

helm rollback my-release 1

❗️Важно: иногда rollback не возвращает ConfigMap или Secret, если они были изменены. Используй флаг --recreate-pods или закладывай изменения в values.yaml через hash-аннотации.


🔹 4. Прогревай rollback заранее

На preprod окружении сделай dry-run откатов. Проверь:

- есть ли живая предыдущая ревизия
- не изменились ли зависимости (например, база данных)
- как себя ведёт app после downgrade


🔹 5. Автоматизируй возврат

Сценарий: новая версия падает по хелсчекам. Вместо ручного вмешательства — automation:

- Настрой alertmanager на провал readiness/liveness
- Свяжи с Argo Rollouts или Spinnaker, чтобы триггерить rollback автоматически


✅ Вывод: грамотный rollback — это не кнопка “назад”, а часть CI/CD культуры.

Обеспечь:

- контроль версий манифестов
- мониторинг после деплоя
- rollback как часть стратегии, а не костыль


#devops #девопс

📲 Мы в MAX

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

HULL - Helm Uniform Layer Library

Этот репозиторий содержит библиотечную диаграмму Helm под названием HULL. Она предназначена для упрощения создания, поддержки и настройки объектов Kubernetes в Helm-диаграммах и может быть добавлена к любой Helm-диаграмме в качестве дополнения для расширения функциональности без риска нарушения существующих конфигураций Helm.

Сама диаграмма и вся связанная с ней документация находятся в папке hull, которая является корневой директорией библиотечной Helm-диаграммы HULL.

https://github.com/vidispine/hull

#devops #девопс

📲 Мы в MAX

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

Kubernetes: правильный подход к ресурсным лимитам и requests

🔧 Часто недооценённая, но критичная тема для стабильности и производительности кластеров.


Неверные значения requests и limits приводят либо к перерасходу ресурсов, либо к OOM, Throttling и подам, которые бесконечно перезапускаются. Особенно больно это бьёт по продакшену.


🚀 Как правильно настраивать ресурсы:

1. Понимай разницу между requests и limits:
- requests — это гарантированный минимум, который получит контейнер.
- limits — это максимум, выше которого контейнер не сможет использовать (CPU throttling или OOMKill для памяти).

2. CPU — без жестких лимитов:
- Лучше не указывать limits.cpu, чтобы избежать throttling.
- Но обязательно ставь requests.cpu, чтобы kube-scheduler мог правильно распланировать нагрузку.

3. Memory — всегда с лимитом:
- Память не отбирается — контейнер либо получает всю, либо OOM.
- Обязательно ставь и requests.memory, и limits.memory.

4. Используй VPA (Vertical Pod Autoscaler):
- Он поможет подобрать адекватные значения ресурсов на основе истории.
- ⚠️ На проде использовать осторожно — часто в "recommendation only" режиме.

5. Метрики в помощь:
- Используй kubectl top, metrics-server, Prometheus/Grafana для анализа потребления.
- Наблюдай за container_cpu_usage_seconds_total, container_memory_usage_bytes.

6. Профилируй и оптимизируй:
- Легковесный nginx или sidecar не должен просить 500Mi памяти.
- Java-приложение без указанных лимитов съест весь узел.


🧠 Вывод:
Грамотно выставленные ресурсы — это баланс между надёжностью и эффективным использованием нод. Не копируй requests/limits вслепую из интернета — мерь, анализируй, настраивай под свой ворклоад.

📲 Мы в MAX

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

Cilicon - это приложение для macOS, использующее фреймворк виртуализации Apple для создания, предоставления и запуска эфемерных виртуальных машин CI с производительностью, близкой к нативной. В настоящее время оно поддерживает Github Actions, Buildkite Agent, GitLab Runner и произвольные скрипты.

В зависимости от ваших настроек, вы сможете запустить свой собственный CI в считанные минуты 🚀.


https://github.com/traderepublic/Cilicon

#devops #девопс

📲 Мы в MAX

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

CI/CD в 3 раза быстрее: секреты оптимизации GitHub Actions

GitHub Actions - мощный инструмент, но даже продвинутые пайплайны часто работают медленнее, чем могли бы. Потери времени = потери денег и developer experience. Вот как ускорить ваши воркфлоу без потери функциональности.

1. Используйте concurrency и cancel-in-progress

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true

Это позволит отменять старые запуски одного и того же воркфлоу на той же ветке — особенно полезно при пушах в PR. Экономим минуты на каждом коммите.

2. Кешируйте всё, что можно

- name: Cache pip packages
uses: actions/cache@v3
with:
path: ~/.cache/pip
key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-

То же касается node_modules, cargo, .m2, gradle — любые зависимости можно кэшировать, особенно если они скачиваются каждый раз.

3. Не бойтесь matrix + fail-fast: false

Запускайте параллельно всё, что можно: тесты на разных версиях языка, разных ОС, разных архитектурах.

strategy:
matrix:
python-version: [3.10, 3.11]
os: [ubuntu-latest, macos-latest]
fail-fast: false


4. Reusable workflows > копипаста

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

5. Запускайте воркфлоу только при нужных событиях

on:
push:
branches: [main]
paths:
- 'src/**'
- '.github/workflows/**'

Зачем триггерить CI, если изменился только README?


Оптимизация CI/CD - это не про «поиграться с YAML». Это способ сэкономить время команды, ускорить релизы и избежать выгорания из-за бесконечного ожидания. Чем быстрее обратная связь - тем лучше продукт.

#devops #девопс

📲 Мы в MAX

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

🚀 Разворачиваем Kubernetes-кластер за 5 минут с помощью Proxmox и k3s!

Автор статьи показывает, как быстро поднять кластер с помощью Proxmox и лёгкого дистрибутива K3s. Всё максимально просто:
- Устанавливаем Proxmox VE
- Создаём шаблон VM с Ubuntu
- Автоматизируем деплой через cloud-init
- Настраиваем кластер K3s в пару кликов

🔥 Идеально для домашней лаборатории или быстрой отладки!

00:04 Introduction
00:18 Why Use Mini PCs Over Cloud Computing for Personal / Hobby Projects
01:13 Installing Proxmox and Setting Up Cluster
02:12 Creating a VM for Kubernetes Worker Node
03:38 Installing Kubernetes on Ubuntu Server
04:14 Joining the New Node to the Kubernetes Cluster
05:19 Potential Applications of Your New Setup
05:30 Upcoming Projects and Channel Focus
06:02 Measuring Power Consumption with a Smart Plug
06:07 Conclusion and Farewell

https://dev.to/mihailtd/set-up-a-kubernetes-cluster-in-under-5-minutes-with-proxmox-and-k3s-2987

#devops #девопс

📲 Мы в MAX

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

🆕 Bun Shell - кроссплатформенный shell прямо в JavaScript

Bun Shell - это встроенный интерпретатор shell-команд в Bun, позволяющий писать скрипты на JavaScript/TypeScript с лаконичным синтаксисом:

import { $ } from "bun";
await $`ls *.js`;

Основные возможности:
• Кроссплатформенность: работает на Windows, macOS и Linux.
• Поддержка переменных, редиректов, пайпов и шаблонов.
• Безопасность: автоматическое экранирование переменных.
• Взаимодействие с объектами JavaScript: Response, ArrayBuffer, Blob.
• Встроенные команды: cd, rm, echo и другие.

Пример использования с переменной:

const filename = "example.txt";
await $`cat ${filename}`;

https://bun.sh/blog/the-bun-shell

#devops #девопс

📲 Мы в MAX

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

Kubernetes в проде: 7 ошибок, которые совершают даже опытные

Если ты деплоишь сервисы в Kubernetes, скорее всего, ты уже наступал на эти грабли. А если нет — вот чеклист, чтобы не наступить.


1. Не включён livenessProbe и readinessProbe
Без этих пробы Kubernetes не понимает, когда перезапустить контейнер или исключить под из сервисов. В итоге — трафик идёт в мёртвые инстансы, а ты ловишь 500-е.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 10

2. resources.requests и limits не заданы
Если не выставить ресурсы, поды будут жрать всё подряд, а kube-scheduler может завалить ноды. Определи baseline и поставь лимиты с запасом:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

3. Один replica на под в проде
Если у тебя только один реплика, ты не в HA. Любая перезагрузка = даунтайм. Минимум две — лучше три.

4. latest тег образа
image: myapp:latest — это лотерея. K8s не знает, что образ поменялся, и не перезапускает поды. Используй versioned теги (`v1.2.3`) или внедри CI, который автоматически делает новый тег и rollout.

5. Нет ограничений по PodDisruptionBudget
Без PDB можно случайно прибить все поды при drain'е ноды или апдейте. Добавь минимум 1 живой под:

minAvailable: 1

6. Логи в /var/log или вообще stdout игнорируется
Всё, что не идёт в stdout/stderr, теряется. Используй sidecar'ы или shipper'ы типа Fluent Bit, если хочешь нормальный логинг.

7. Секреты хранятся в plaintext в Git
Kubernetes Secret — это base64, а не шифрование. Либо используй sealed-secrets, либо интеграцию с HashiCorp Vault, SOPS или AWS KMS.


Вывод:
Даже базовые настройки могут сыграть злую шутку, если их игнорировать. Сделай себе шаблон Helm-чарта или Kustomize-паттерн, в котором всё это будет по умолчанию. И не забудь периодически пересматривать best practices — K8s развивается 🔄

#devops #девопс

📲 Мы в MAX

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

Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON.

Возможности

- Прослушивание изменений в PostgreSQL в режиме реального времени.
- Поддержка нескольких слотов репликации.
- Удобный вывод в формате JSON.
- Готов к использованию в качестве сервиса.

Пример использования

1. Создаём слот репликации:

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   

2. Запускаем wal-listener:

   wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
   

3. Получаем JSON-объекты при изменениях в базе данных.

https://github.com/ihippik/wal-listener

#devops #девопс

📲 Мы в MAX

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

🚀 Подборка полезных IT каналов в Max


Системное администрирование, DevOps 📌

https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.

1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С

Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика

Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика

Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика

GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных

Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков

Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов

Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻

Шутки программистов 📌
https://max.ru/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free

Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров

Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике

Вакансии 📌
https://max.ru/progjob Вакансии в IT

Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных


Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы

Kubernetes: как не угробить прод с неправильными Liveness/Readiness пробыми 🧟‍♂️

Если ваши поды «умирают» слишком рано или слишком долго не проходят readiness, возможно, вы не до конца понимаете, как работают пробы в Kubernetes. А между тем, это критично для uptime и стабильности продакшена.


📌 Пробы - не «просто пинги»

- livenessProbe отвечает за "жив ли под". Если не проходит - kubelet убивает контейнер.
- readinessProbe - "готов ли под принимать трафик". Пока не готов - не пускается в сервис.

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


🛠 Типичные ошибки

1. Тот же эндпоинт для обеих проб
Readiness может требовать больше инициализации. Разделяйте эндпоинты:
/healthz/live и /healthz/ready - хорошая практика.

2. Слишком агрессивные тайминги
initialDelaySeconds, timeoutSeconds, failureThreshold - не забывайте учитывать холодный старт (особенно при Java, .NET, DB init).

3. Тестирование только на dev/stage
На проде нагрузка выше, сеть может вести себя иначе. Профиль подов должен учитывать real-world сценарии.

4. Liveness вместо retries
Liveness не замена retry-логике в приложении. Используйте circuit breakers, retries и grace periods на уровне сервиса.


✅ Как делать правильно

- Используйте простые GET-запросы, без heavy логики.
- Не тестируйте зависимости (БД, внешние API) в liveness - пусть это останется за readiness.
- Применяйте terminationGracePeriodSeconds и preStop hook, чтобы избежать резкого отключения.


🧩 Стартовый шаблон для readiness/liveness

livenessProbe:
  httpGet:
    path: /healthz/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

Вывод: Настройка prob - это не ритуал ради YAML-а. Это инструмент стабильности и доступности. Подходите к ним осознанно, валидируйте на нагрузке и помните, что "здоровый" под ≠ "готовый к трафику".

#devops #девопс

📲 Мы в MAX

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