https://szymonkocur.com/tags/hpa/Recent content in HPA on Szymon KocurHugoen-usSun, 29 Mar 2026 00:00:00 +0000https://szymonkocur.com/posts/three-hpa-pitfalls-gke-flux-linkerd/Sun, 29 Mar 2026 00:00:00 +0000https://szymonkocur.com/posts/three-hpa-pitfalls-gke-flux-linkerd/I added Horizontal Pod Autoscalers to a production GKE cluster running Flux CD for GitOps and Linkerd as a service mesh. The HPA configuration itself was straightforward — the problems came from how these three systems interact. Here are three pitfalls I hit, each requiring a separate fix. 1. Flux keeps resetting the replica count Link to heading The first HPA I deployed looked like this: apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: frontend spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: frontend minReplicas: 5 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 Within minutes, the HPA scaled the frontend from 5 to 7 replicas based on CPU load.https://szymonkocur.com/posts/flux-ignore-differences-hpa-replica-count/Sat, 28 Mar 2026 00:00:00 +0000https://szymonkocur.com/posts/flux-ignore-differences-hpa-replica-count/I added a Horizontal Pod Autoscaler to a Flux-managed Deployment and watched the replica count bounce between what the HPA wanted and what Git said. Every 5 minutes, Flux would reconcile, see that spec.replicas had drifted from the Git state, and reset it. The HPA would immediately scale it back. Repeat forever. This is a fundamental tension in GitOps: Flux’s job is to make the cluster match Git. The HPA’s job is to set the replica count based on metrics.