Почему вы использовали именно Helm Charts для управления приложениями в Kubernetes?

Мы выбрали Helm как стандартный инструмент управления приложениями в Kubernetes из-за его способности решать ключевые проблемы "сырых" YAML-манифестов:

• Шаблонизация и избегание дублирования: Без Helm для 10 микросервисов пришлось бы поддерживать 10 почти идентичных наборов манифестов (Deployment, Service, ConfigMap и т.д.). Helm позволяет создать один параметризованный шаблон (deployment.yaml с плейсхолдерами вроде {{ .Values.image.repository }}) и переиспользовать его.
• Конфигурируемость через values.yaml: Это разделяет код (шаблоны) и конфигурацию. Для разных окружений (dev, staging, prod) мы создаем отдельные файлы values-dev.yaml, где задаем количество реплик, образы, лимиты ресурсов. Деплой сводится к команде helm upgrade --install -f values-prod.yaml.
• Версионирование и легкий откат: Каждый Chart имеет версию. Мы можем легко откатиться на предыдущую стабильную версию приложения вместе со всей его конфигурацией командой helm rollback <release>. Без Helm пришлось бы вручную искать и применять старые манифесты.
• Управление зависимостями: Если наше приложение зависит от Redis или PostgreSQL, мы можем описать это в Chart.yaml, и Helm автоматически установит и сконфигурирует эти зависимости.

Пример структуры values.yaml для продакшена:

replicaCount: 5
image:
  repository: my-registry/app-backend
  tag: v1.5.0
  pullPolicy: IfNotPresent
resources:
  limits:
    cpu: 500m
    memory: 512Mi
service:
  type: ClusterIP
  port: 8080

Это делает процесс CI/CD предсказуемым и управляемым.