geographybuff opened a new pull request, #1031: URL: https://github.com/apache/apisix-helm-chart/pull/1031
Closes #977. The chart has `autoscaling` values and `pdb.yaml` reads them, but #837 removed `templates/hpa.yaml` during the v2 update, so `autoscaling.enabled=true` creates no HPA. The same PR dropped the check that stops the Deployment setting `replicas` under autoscaling. I found no reason recorded for either removal. Changes: - add `templates/hpa.yaml`, modelled on the `apisix` chart's template - leave `spec.replicas` out of the Deployment when autoscaling is on, so `helm upgrade` doesn't reset what the HPA has set - add `maxReplicas`, `targetCPUUtilizationPercentage` and `targetMemoryUtilizationPercentage` to the values, and regenerate the README with helm-docs v1.11.0 - bump the chart to 1.5.0 Decisions for review: - **What extra replicas do.** Only the leader reconciles. With 3 replicas, only the leader logged `Starting workers`, and a standby took over about 30 s after the leader pod was deleted. So this gives failover, not throughput, and the values comment says so. If you'd rather not offer an HPA for that reason, the alternative is to remove the `autoscaling` values and the matching branch in `pdb.yaml`. - **`autoscaling/v2` only.** I left out the `apisix` chart's `version` value and its `v2beta1` branch. `autoscaling/v2` needs Kubernetes 1.23, and CI's matrix also lists 1.22, where turning this on would fail. The default is off, and CI's `ct install` step doesn't install this chart. - **Defaults.** `maxReplicas` is 3, not the `apisix` chart's 100, because of the leader behavior above. The CPU target is 80 and memory is off, matching this chart's template before #837. If both targets are 0, Kubernetes falls back to 80% CPU. Behavior to expect: - Anyone already setting `autoscaling.enabled=true` gets an HPA after upgrading, and the chart stops setting `replicas` for them. - Without `deployment.resources.requests`, the HPA is created but can't compute utilization. It reports `missing request for cpu in container manager` and doesn't scale. The README says requests are needed. Testing on k3d with k3s v1.35.5, 1 server and 1 agent, controller 2.2.0, adc 0.27.1. Scaling was triggered with a 1m CPU request and a 50% target, without real load: | Check | Result | |---|---| | `autoscaling.enabled=true` on master | No HPA, `replicas` set | | Same on this branch | 1 HPA, no `replicas` | | Default values, master vs this branch | No new resources. Besides a comment-only `hpa.yaml` document, only `webhook.yaml` differs, and it also differs between two renders of master because of its generated certificates | | HPA with a CPU request | Scaled from 1 to 3 within about 60 s, `ScalingActive=True` | | Unrelated `helm upgrade`, Helm 3.16.4 and 4.3 | `spec.replicas` stayed at 3 | | Same upgrade with master's `deployment.yaml`, Helm 4.3 | `spec.replicas` dropped to 1 | | Upgrade from 1.4.1 with `replicas=2`, turning autoscaling on, Helm 3.16.4 | HPA created. `spec.replicas` dropped to 1 right after the upgrade, then the HPA raised it | | Turning autoscaling off with `replicas=2`, Helm 4.3 | HPA removed, `spec.replicas` is 2 | | PDB with autoscaling | Renders at `minReplicas=2`, not at 1 | | `helm lint`, `ct lint` v3.13.0 | Pass | Not tested: real traffic load, a connected APISIX data plane, the admission webhook with several replicas, and Kubernetes versions other than 1.35. AI disclosure: Claude Code wrote this change and this description, and ran the tests. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
