Welcome!

• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What do you want to achieve with this Chart ?

My goal is to manage the Traefik Deployment using Argo Rollouts for progressive delivery.

To do this effectively, the Argo Rollouts controller must have exclusive control over the pod replicas. The ideal practice for this is to completely delegate replica management to the Rollout resource. This means the replicas field should not be present in the original Deployment manifest, allowing the Rollout controller to manage it without any conflicting instructions.

However, the Traefik Helm chart currently always renders the replicas field in the Deployment manifest. This can lead to conflicts or unpredictable behavior when an external controller like Argo Rollouts tries to manage the same field.

This feature request is to add a switch to optionally disable the rendering of the replicas field, providing a cleaner integration path.

The Context: The Problem in Detail

The core issue is that the replicas field is always rendered, due to this line in traefik/templates/deployment.yaml:

Even if we could set the value to 0, the presence of the replicas: 0 field itself is an explicit instruction. A cleaner approach is to omit the field entirely when its management is delegated.

The Idea: Proposed Solution

I propose introducing a new boolean value in the chart's values.yaml, for example deployment.manageReplicas.

• deployment.manageReplicas (default: true): When true or unset, the chart behaves exactly as it does now, maintaining backward compatibility.
• deployment.manageReplicas: false: When set to false, the replicas field is completely omitted from the rendered Deployment manifest.

This could be implemented with a simple conditional block in the template:

# proposed change in deployment.yaml
{{- if not .Values.autoscaling.enabled }}
{{- if .Values.deployment.manageReplicas | default true }}
replicas: {{ default 1 .Values.deployment.replicas }}
{{- end }}
{{- end }}

This approach provides the necessary flexibility for GitOps and progressive delivery tools without affecting existing users.

How to Reproduce (Example Use Case)

With the proposed change, the following Argo CD Application manifest would work as intended. By setting deployment.manageReplicas: false, we signal that Argo Rollouts is now in charge of the replica count.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: traefik
  namespace: argocd
spec:
  destination:
    namespace: traefik
    server: https://kubernetes.default.svc
  source:
    repoURL: https://traefik.github.io/charts
    targetRevision: 36.1.0
    chart: traefik
    helm:
      parameters:
        - name: deployment.manageReplicas # New parameter
          value: "false"
      values: |-
        extraObjects:
          - apiVersion: argoproj.io/v1alpha1
            kind: Rollout
            metadata:
              name: traefik-rollout
            spec:
              workloadRef:
                apiVersion: apps/v1
                kind: Deployment
                name: traefik
              strategy:
                canary:
                  steps:
                  - setWeight: 10
                  - pause:
                      duration: 5m
          - apiVersion: autoscaling/v2
            kind: HorizontalPodAutoscaler
            metadata:
              name: traefik-rollout-hpa
            spec:
              scaleTargetRef:
                apiVersion: argoproj.io/v1alpha1
                kind: Rollout
                name: traefik-rollout
              minReplicas: 5
              maxReplicas: 50
              metrics:
              - type: Resource
                resource:
                  name: cpu
                  target:
                    type: Utilization
                    averageUtilization: 80
  project: traefik
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Thank you for considering this enhancement. This flexibility would be a great help for users adopting modern GitOps and progressive delivery patterns.