chartpack: один Helm-чарт для всех Kubernetes-приложений

Один, opinionated Helm-чарт для деплоя любого Kubernetes application workload. Вместо поддержки отдельных чартов под каждое приложение, вы описываете весь деплой через values.yaml.

helm install my-app ./chartpack -f values.yaml

Зачем

Классический паттерн в больших компаниях: каждый микросервис тащит за собой собственный Helm-чарт. Получается:

  • 50 микросервисов = 50 почти-одинаковых чартов.

  • Каждый чарт — это Deployment, Service, Ingress, ConfigMap, Secret, HPA, PDB, иногда NetworkPolicy.

  • Когда выходит новая версия Kubernetes (или Helm), обновлять нужно во всех 50.

  • Когда вам нужно добавить sidecar (например, для metrics) — нужно добавить во все 50.

chartpack решает проблему один раз: один чарт, который умеет всё нужное, а отличия описываются в values.

Что в нём есть

Готовые шаблоны для:

  • Deployment / StatefulSet (по выбору).

  • Service (ClusterIP / NodePort / LoadBalancer).

  • Ingress с поддержкой нескольких контроллеров.

  • Gateway API (HTTPRoute) — для современных кластеров.

  • ConfigMap и Secret.

  • HorizontalPodAutoscaler и PodDisruptionBudget.

  • NetworkPolicy с дефолтным deny-all.

  • ServiceAccount с RBAC.

  • Sidecars: Envoy, OpenTelemetry collector, custom containers.

Пример values.yaml

containers:
  app:
    image:
      repository: nginx
      tag: "1.27"
    ports:
      http:
        port: 80

networking:
  services:
    http:
      ports:
        - name: http
          port: 80
          targetPort: http
  ingress:
    enabled: true
    host: my-app.example.com
    tls: true

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

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

networkPolicy:
  enabled: true
  ingressFrom:
    - namespace: gateway
  egressTo:
    - service: postgres.databases.svc.cluster.local
      port: 5432

Этого достаточно, чтобы развернуть production-ready приложение со всеми кубернетес-best-practices.

Sidecars

Добавление, например, OpenTelemetry-collector:

containers:
  app:
    image: { repository: nginx, tag: "1.27" }
  otel:
    image: { repository: otel/opentelemetry-collector, tag: "0.95.0" }
    args: ["--config=/etc/otel-config.yaml"]
    volumeMounts:
      - name: otel-config
        mountPath: /etc/otel-config.yaml
        subPath: config.yaml

volumes:
  - name: otel-config
    configMap: { name: otel-config }

Multi-environment

Для разных окружений — отдельные values:

helm upgrade --install my-app ./chartpack \
  -f values.yaml \
  -f values.production.yaml

Где values.production.yaml переопределяет только то, что отличается (replicas, ресурсы, имя кластера в Ingress).

Trade-offs

  • Opinionated — если вам нужны нестандартные ресурсы (например, кастомные CRD-ы Argo Rollouts), вы либо расширяете chart, либо живёте без них. Из коробки — стандарт K8s + Gateway API.

  • Vendor-neutral — не привязан к конкретному ingress-контроллеру или service mesh. Это и плюс, и минус: меньше «глубокой» интеграции.

  • Lock-in — переход на свои чарты после массового внедрения chartpack — задача на квартал минимум.

Кому подходит

  • Командам с 10+ микросервисами на одном Kubernetes.

  • Платформенным командам, которые предоставляют «golden path» для разработчиков.

  • Стартапам, у которых нет времени на собственный шаблонизатор.

Альтернативы

  • Kustomize-only — другой подход, без шаблонов. Сильнее для GitOps, слабее для параметризации.

  • Carvel ytt/kapp — мощнее, но крутая кривая обучения.

  • Bitnami common chart — старше, но менее opinionated; больше места для разнобоя в командах.

  • Argo CD ApplicationSet + Helm template — для GitOps-флоу с десятками одинаковых приложений.

GitHub: cotzo/chartpack. MIT-лицензия.