chart: add api-server rollout restart cronjob

[henry3260]

Why

The new ‎gunicorn server type provides rolling worker restarts, but for users who continue to use the default ‎uvicorn mode on Kubernetes, it’s useful to have a first‑class mechanism in the Helm chart to periodically restart the API server pods.

What

Add an optional CronJob (runs ‎kubectl rollout restart deployment/airflow-api-server )that runs for the API server deployment, with configurable schedule, target name, and RBAC.

closes: #61432

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Copilot

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jscheffl]

Mhm, I am not so for this.

Can you give a reason why a periodic restart is needed? Is there a memory leak in the software? Then we should rather fix the root cause and not compensate with a preriodic restart feature.

[henry3260]

Mhm, I am not so for this.

Can you give a reason why a periodic restart is needed? Is there a memory leak in the software? Then we should rather fix the root cause and not compensate with a preriodic restart feature.

Thanks for your feedback!! This isn’t meant to mask a known memory leak.
I think the motivation is operational parity: gunicorn provides a built-in rolling worker refresh, but the default uvicorn does not. Many users running uvicorn on
Kubernetes already schedule periodic rollouts externally to keep long‑running API
server processes fresh.
It’s opt‑in and off by default. IMO, Users who want built‑in rolling restarts should prefer
gunicorn; this option is for those who stay on uvicorn. FYI, #60940 (comment)

[jscheffl]

Mhm, I am not so for this.
Can you give a reason why a periodic restart is needed? Is there a memory leak in the software? Then we should rather fix the root cause and not compensate with a preriodic restart feature.

Thanks for your feedback!! This isn’t meant to mask a known memory leak. I think the motivation is operational parity: gunicorn provides a built-in rolling worker refresh, but the default uvicorn does not. Many users running uvicorn on Kubernetes already schedule periodic rollouts externally to keep long‑running API server processes fresh. It’s opt‑in and off by default. IMO, Users who want built‑in rolling restarts should prefer gunicorn; this option is for those who stay on uvicorn. FYI, #60940 (comment)

Mhm, still not fully convincing. This adds really a lot of complexity for a operational shortcoming that in my view should be fixed in other places.

We are planning to carve-out complexity of the chart and this here adds a whole lot of additional complexity. Maybe this is one of the first candidates where we offer a structure to add custom stuff on top via Kustomize?

[henry3260]

Mhm, I am not so for this.
Can you give a reason why a periodic restart is needed? Is there a memory leak in the software? Then we should rather fix the root cause and not compensate with a preriodic restart feature.

Thanks for your feedback!! This isn’t meant to mask a known memory leak. I think the motivation is operational parity: gunicorn provides a built-in rolling worker refresh, but the default uvicorn does not. Many users running uvicorn on Kubernetes already schedule periodic rollouts externally to keep long‑running API server processes fresh. It’s opt‑in and off by default. IMO, Users who want built‑in rolling restarts should prefer gunicorn; this option is for those who stay on uvicorn. FYI, #60940 (comment)

Mhm, still not fully convincing. This adds really a lot of complexity for a operational shortcoming that in my view should be fixed in other places.

We are planning to carve-out complexity of the chart and this here adds a whole lot of additional complexity. Maybe this is one of the first candidates where we offer a structure to add custom stuff on top via Kustomize?

Makes sense to me. @jason810496 WDYT?

[jason810496]

Thanks Jens for the review!

Makes sense to me. @jason810496 WDYT?

Do we need to raise discussion in Dev mailing list or Slack channel?

Maybe this is one of the first candidates where we offer a structure to add custom stuff on top via Kustomize?

Or if introducing Kustomize had already been decided, then yes, I think it makes sense to me.

[henry3260]

Thanks Jens for the review!

Makes sense to me. @jason810496 WDYT?

Do we need to raise discussion in Dev mailing list or Slack channel?

Maybe this is one of the first candidates where we offer a structure to add custom stuff on top via Kustomize?

Or if introducing Kustomize had already been decided, then yes, I think it makes sense to me.

Thanks Jason!
If we want to raise discussion, I will happy to do that :)

[jason810496]

If we want to raise discussion, I will happy to do that :)

Maybe we could start a discussion in ‎#helm-chart-official to bring more awareness to this.