thejoeejoee opened a new issue, #63186:
URL: https://github.com/apache/airflow/issues/63186
### Official Helm Chart version
1.19.0 (latest released)
### Apache Airflow version
3.1
### Kubernetes Version
1.35
### Helm Chart configuration
```yaml
apiServer:
replicas: 1
hpa:
enabled: true
minReplicaCount: 1
maxReplicaCount: 5
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80
```
### Docker Image customizations
None — using the official image.
### What happened
When `apiServer.hpa.enabled: true`, the Deployment manifest still contains
`spec.replicas: 1`.
HPA modifies this field at runtime to scale the api-server. GitOps tooling
continuously detects
a diff between the desired state in Git (`replicas: 1`) and the live cluster
state (replicas
managed by HPA), causing a permanent out-of-sync condition that cannot be
resolved without
disabling HPA or ignoring the field via a custom diff strategy.
### What you think should happen instead
When HPA is enabled, `spec.replicas` should be omitted from the Deployment
entirely.
This allows HPA to be the sole owner of the replica count and eliminates the
spurious diff.
### How to reproduce
1. Deploy the chart with `apiServer.hpa.enabled: true` and
`apiServer.replicas: 1` (defaults).
2. Observe the live Deployment — HPA immediately takes ownership and mutates
`spec.replicas`.
3. Any GitOps reconciliation loop will report a permanent diff on
`spec.replicas`.
Set `apiServer.replicas: ~` in `values.yaml` as a workaround — the field is
then omitted
from the rendered Deployment and HPA can manage replicas without conflict.
### Anything else
The same pattern (`kindIs "invalid"` guard on `spec.replicas`) is the
standard fix used by
other Helm charts to support HPA without GitOps drift.
### Are you willing to submit PR?
- [x] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
