{"id":1721,"date":"2026-02-17T12:53:48","date_gmt":"2026-02-17T12:53:48","guid":{"rendered":"https:\/\/aiopsschool.com\/blog\/horizontal-pod-autoscaler\/"},"modified":"2026-02-17T15:13:12","modified_gmt":"2026-02-17T15:13:12","slug":"horizontal-pod-autoscaler","status":"publish","type":"post","link":"https:\/\/aiopsschool.com\/blog\/horizontal-pod-autoscaler\/","title":{"rendered":"What is horizontal pod autoscaler? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition (30\u201360 words)<\/h2>\n\n\n\n<p>Horizontal Pod Autoscaler (HPA) is a Kubernetes controller that automatically scales the number of pod replicas for a Deployment, ReplicaSet, or StatefulSet based on observed metrics. Analogy: HPA is like an automatic thermostat adding or removing heaters to maintain temperature. Formal: it maps metrics to replica counts via scaling rules.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is horizontal pod autoscaler?<\/h2>\n\n\n\n<p>Horizontal Pod Autoscaler (HPA) is a controller in Kubernetes that adjusts the number of pod replicas to match demand using observed metrics. It is NOT a replacement for vertical scaling, node autoscaling, or application-level capacity planning. HPA controls pod count; it does not change resource limits of existing pods or manage nodes directly.<\/p>\n\n\n\n<p>Key properties and constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Works at the controller level for supported workload types.<\/li>\n<li>Can scale based on CPU, memory, custom metrics, or external metrics.<\/li>\n<li>Subject to stabilization windows and scale up\/down behaviors.<\/li>\n<li>Dependent on metrics pipeline reliability and API server connectivity.<\/li>\n<li>Reacts to observed metrics with configurable tolerance and cooldown.<\/li>\n<li>Requires correct resource requests to make CPU-based scaling meaningful.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>First line of reactive capacity for stateless service layers.<\/li>\n<li>Used alongside Cluster Autoscaler and Vertical Pod Autoscaler for multi-dimensional scaling.<\/li>\n<li>Part of SRE incident mitigation for load surges and capacity shortages.<\/li>\n<li>Integrated into CI\/CD and can be tuned via automated configuration pipelines.<\/li>\n<li>Security considerations: metrics access and admission controls must be scoped.<\/li>\n<\/ul>\n\n\n\n<p>Diagram description (text-only):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Metrics sources (kubelet, cAdvisor, Prometheus adapter, external API) flow into Metrics API.<\/li>\n<li>HPA reads metrics from Metrics API and current replica count from controller.<\/li>\n<li>HPA computes desiredReplicas using scaling policy and target metrics.<\/li>\n<li>HPA writes desired replica changes to the workload controller.<\/li>\n<li>Controller creates or deletes pods; scheduler and kubelet place and run pods on nodes.<\/li>\n<li>Cluster Autoscaler may add nodes if pods are pending due to insufficient capacity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">horizontal pod autoscaler in one sentence<\/h3>\n\n\n\n<p>HPA is a Kubernetes control loop that adjusts the replica count of workloads to meet target metrics and maintain performance while optimizing resource usage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">horizontal pod autoscaler vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from horizontal pod autoscaler<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Vertical Pod Autoscaler<\/td>\n<td>Adjusts resource requests not replica count<\/td>\n<td>People think VPA and HPA are interchangeable<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Cluster Autoscaler<\/td>\n<td>Scales nodes not pods<\/td>\n<td>Assumed to protect pods from eviction automatically<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>Pod Disruption Budget<\/td>\n<td>Controls voluntary evictions not capacity<\/td>\n<td>Mistaken for autoscaling policy<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>KEDA<\/td>\n<td>Event driven scaling including external triggers<\/td>\n<td>Assumed to be same as HPA in all cases<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>HPA v2\/v2beta<\/td>\n<td>HPA versions with custom metrics support<\/td>\n<td>Confusion over which API is stable<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>StatefulSet scaling<\/td>\n<td>Scaling stateful apps with ordered semantics<\/td>\n<td>People expect instant stateless scale behavior<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>ReplicaSet<\/td>\n<td>Kubernetes primitive HPA controls via higher objects<\/td>\n<td>Confusion over controller ownership<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>Deployment<\/td>\n<td>Common target for HPA vs other controllers<\/td>\n<td>Mistaking HPA for deployment strategy<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>Horizontal Pod Autoscaler UI<\/td>\n<td>Visual tools that show scaling not control<\/td>\n<td>Thought to be source of truth for config<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does horizontal pod autoscaler matter?<\/h2>\n\n\n\n<p>Business impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Revenue: prevents lost sales from underprovisioned services during demand spikes by maintaining throughput.<\/li>\n<li>Trust: consistent user experience reduces churn and preserves brand reputation.<\/li>\n<li>Risk: reduces risk of outages but can amplify misconfigured applications leading to runaway costs.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Incident reduction: automatic scaling reduces load-related incidents if configured correctly.<\/li>\n<li>Velocity: developers can iterate without always sizing for peak manually.<\/li>\n<li>Complexity: introduces new failure modes tied to metrics and control planes.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs\/SLOs: HPA can keep latency and error-rate SLIs within SLOs by adding capacity.<\/li>\n<li>Error budgets: HPA adjustments affect error budget burn when capacity lags or overscales.<\/li>\n<li>Toil: Correct automation reduces toil; misconfigurations create more on-call work.<\/li>\n<li>On-call: Teams need runbooks for scaling failures and capacity thrashing; HPA events should be part of incident channels.<\/li>\n<\/ul>\n\n\n\n<p>What breaks in production (realistic examples):<\/p>\n\n\n\n<p>1) Metric pipeline outage: HPA sees stale metrics and scales incorrectly causing overload.\n2) Poor resource requests: CPU-based HPA fails to scale because pods hit CPU limits before requests.\n3) Pod startup latency: HPA scales but pods are slow to become ready, causing transient errors.\n4) Negative feedback loop: autoscaling triggers load balancer rebalancing causing more churn.\n5) Cost runaway: HPA misconfigured with no upper bound causes spiraling costs during traffic anomalies.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is horizontal pod autoscaler used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How horizontal pod autoscaler appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Edge<\/td>\n<td>Scales ingress and edge proxies<\/td>\n<td>Request rate latency errors<\/td>\n<td>Nginx, Envoy, Traefik<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Network<\/td>\n<td>Scales API gateways and proxies<\/td>\n<td>Connection count error rate<\/td>\n<td>Istio, Linkerd, Gateway API<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Service<\/td>\n<td>Scales stateless microservices<\/td>\n<td>RPS latency CPU memory<\/td>\n<td>Kubernetes HPA, Prometheus<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Application<\/td>\n<td>Scales frontend and API pods<\/td>\n<td>User latency 5xx rates<\/td>\n<td>Prometheus, Grafana<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>Data<\/td>\n<td>Scales workers or ingestion tasks<\/td>\n<td>Queue length lag processing time<\/td>\n<td>Kafka consumers, KEDA<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>IaaS\/PaaS<\/td>\n<td>Appears in managed Kubernetes offerings<\/td>\n<td>Node pressure pod pending<\/td>\n<td>EKS GKE AKS managed HPA<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>Serverless<\/td>\n<td>Replaces or complements serverless scaling<\/td>\n<td>Invocation rate cold starts<\/td>\n<td>KEDA, Knative, func frameworks<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>CI\/CD<\/td>\n<td>Used in test environments with synthetic load<\/td>\n<td>Build time test failures<\/td>\n<td>Argo CD, Jenkins<\/td>\n<\/tr>\n<tr>\n<td>L9<\/td>\n<td>Incident response<\/td>\n<td>Auto-remediation to add capacity<\/td>\n<td>Scaling events error budget<\/td>\n<td>PagerDuty, ChatOps<\/td>\n<\/tr>\n<tr>\n<td>L10<\/td>\n<td>Observability<\/td>\n<td>Feeds metrics to dashboards<\/td>\n<td>Metric cardinality anomalies<\/td>\n<td>Prometheus, Datadog<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use horizontal pod autoscaler?<\/h2>\n\n\n\n<p>When necessary:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stateless workloads with variable request rates.<\/li>\n<li>Services handling unpredictable or spiky traffic.<\/li>\n<li>When latency SLIs must be preserved under varying load.<\/li>\n<li>For worker queues where concurrency can be parallelized.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stable low-traffic services with predictable load.<\/li>\n<li>Non-critical batch jobs scheduled via cron where manual scale is OK.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stateful systems with strong ordering or affinity requirements.<\/li>\n<li>Very short-lived pods where scale churn costs more than benefit.<\/li>\n<li>Where scaling horizontally causes correctness issues (consistent hashing constraints).<\/li>\n<li>As the only control for cost optimization without guardrails.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If service is stateless and CPU\/memory or queue metrics correlate with load -&gt; use HPA.<\/li>\n<li>If stateful and scaling changes ordering -&gt; alternative patterns like sharding or VPA.<\/li>\n<li>If startup time &gt; SLA window -&gt; combine HPA with pre-warmed pools or node autoscaler.<\/li>\n<li>If metrics are unreliable -&gt; fix observability before relying on HPA.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: CPU-based HPA with basic targets and safe max replicas.<\/li>\n<li>Intermediate: Custom metrics via Prometheus adapter and scale policies.<\/li>\n<li>Advanced: Multi-metric scaling, predictive\/autoscaling with ML, KEDA for event-driven, automated tuning pipelines, cost-aware scaling tied to budgets.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does horizontal pod autoscaler work?<\/h2>\n\n\n\n<p>Components and workflow:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Metric sources: kube-metrics-server, Prometheus adapter, external APIs or custom metrics.<\/li>\n<li>Metrics API: HPA queries the Kubernetes Metrics API or custom metrics endpoints.<\/li>\n<li>Controller loop: HPA controller runs periodically reading current metrics and desired targets.<\/li>\n<li>Calculation: desiredReplicas computed from formula or algorithm depending on metric type.<\/li>\n<li>Stabilization and policy: apply scale up\/down policies, stabilization windows, and bounds.<\/li>\n<li>Update: HPA updates the target controller&#8217;s replica count.<\/li>\n<li>Reconciliation: controller reconciles desired replicas creating or deleting pods.<\/li>\n<li>Feedback: new pods change metrics; loop continues.<\/li>\n<\/ol>\n\n\n\n<p>Data flow and lifecycle:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Metrics generated -&gt; scraped or pushed -&gt; metrics adapter exposes to Metrics API -&gt; HPA reads -&gt; computes desired -&gt; writes replica change -&gt; controller acts -&gt; pods change state -&gt; metrics reflect new state.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Metrics lag causing oscillation.<\/li>\n<li>Adapter misconfiguration preventing metric retrieval.<\/li>\n<li>API server rate limits or authentication errors.<\/li>\n<li>Cluster resource constraints causing pending pods.<\/li>\n<li>Pod deletion grace periods causing slow scale down.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for horizontal pod autoscaler<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Basic HPA: CPU target for web service. Use when simple load correlates with CPU.<\/li>\n<li>Custom metric HPA: Use Prometheus adapter and latency or QPS metrics. Use when CPU is not a good proxy.<\/li>\n<li>HPA + Cluster Autoscaler: Combine to scale nodes when pods remain pending. Use for unpredictable capacity needs.<\/li>\n<li>HPA + VPA hybrid: VPA adjusts requests, HPA adjusts replicas. Use for mixed workloads needing both dimensions.<\/li>\n<li>Event-driven scaling with KEDA: HPA-like behavior triggered by queue lengths, Kafka or cloud events.<\/li>\n<li>Predictive autoscaling: ML-based predictions set desiredReplicas ahead of traffic spikes, used for predictable diurnal patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Oscillation<\/td>\n<td>Pods scale up and down repeatedly<\/td>\n<td>Aggressive policies or noisy metrics<\/td>\n<td>Add stabilization and buffer<\/td>\n<td>High event rate in audit logs<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>No scale<\/td>\n<td>Latency rises but replicas unchanged<\/td>\n<td>Metrics unavailable or wrong metric target<\/td>\n<td>Validate adapters and targets<\/td>\n<td>Metrics API errors<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Scale but pending pods<\/td>\n<td>Replicas increased but pods pending<\/td>\n<td>Node resource exhaustion<\/td>\n<td>Use Cluster Autoscaler and resource requests<\/td>\n<td>Pending pod count<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Overscale cost<\/td>\n<td>Unbounded replicas during anomaly<\/td>\n<td>Missing maxReplicas or faulty metric<\/td>\n<td>Add upper bounds and anomaly detection<\/td>\n<td>Billing spike with scale events<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Slow recovery<\/td>\n<td>Pods take long to become ready<\/td>\n<td>Heavy init or image pull latencies<\/td>\n<td>Use pre-warmed pools or image caching<\/td>\n<td>Pod startup time metric<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>Throttled API<\/td>\n<td>HPA updates denied<\/td>\n<td>API server rate limits or RBAC<\/td>\n<td>Backoff, RBAC tuning, reduce reconciliation frequency<\/td>\n<td>API server 429s<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>Wrong metric semantics<\/td>\n<td>Scale reacts to gauge not rate<\/td>\n<td>Using instantaneous metric for cumulative target<\/td>\n<td>Use rate metrics or correct adapter<\/td>\n<td>Metric trend mismatch<\/td>\n<\/tr>\n<tr>\n<td>F8<\/td>\n<td>Pod disruption<\/td>\n<td>Stateful failure on scale down<\/td>\n<td>Scale down deletes required instance<\/td>\n<td>Use PodDisruptionBudget and graceful drains<\/td>\n<td>Eviction and termination logs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for horizontal pod autoscaler<\/h2>\n\n\n\n<p>(List of 40+ terms; each entry: Term \u2014 1\u20132 line definition \u2014 why it matters \u2014 common pitfall)<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>HPA \u2014 Kubernetes controller that scales pods \u2014 central orchestration point \u2014 assuming it manages nodes<\/li>\n<li>Metrics API \u2014 Kubernetes interface for metrics \u2014 HPA reads metrics here \u2014 adapter misconfigurations<\/li>\n<li>kube-metrics-server \u2014 basic metrics provider \u2014 enables CPU\/memory autoscaling \u2014 doesn&#8217;t provide custom metrics<\/li>\n<li>Custom Metrics \u2014 metrics defined by apps \u2014 enables fine-grained scaling \u2014 adapter complexity<\/li>\n<li>External Metrics \u2014 metrics from non-Kubernetes sources \u2014 use for cloud or business signals \u2014 latency and auth issues<\/li>\n<li>Prometheus Adapter \u2014 exposes Prometheus metrics to Metrics API \u2014 common bridge \u2014 cardinality problems<\/li>\n<li>Target CPU Utilization \u2014 percentage target used by CPU HPA \u2014 simple starting point \u2014 wrong requests distort it<\/li>\n<li>Target Memory Utilization \u2014 similar for memory \u2014 memory is less ideal due to OOMs \u2014 eviction risk<\/li>\n<li>ReplicaSet \u2014 K8s controller that manages pods \u2014 HPA instructs higher-level controllers \u2014 ownership confusion<\/li>\n<li>Deployment \u2014 common HPA target \u2014 holds rollout and strategy \u2014 scaling interacts with rollout<\/li>\n<li>StatefulSet \u2014 ordered set of pods \u2014 scaling is ordered not instantaneous \u2014 can break assumptions<\/li>\n<li>VPA \u2014 adjusts pod resource requests \u2014 complements HPA \u2014 conflicting actions if not coordinated<\/li>\n<li>Cluster Autoscaler \u2014 scales nodes \u2014 needed when pods pending \u2014 misaligned policies cause thrash<\/li>\n<li>KEDA \u2014 event driven autoscaler for K8s \u2014 supports external event sources \u2014 different semantics than HPA<\/li>\n<li>Scale Targets \u2014 object types HPA can control \u2014 must be supported \u2014 incompatible objects cause errors<\/li>\n<li>Stabilization Window \u2014 time to prevent rapid fluctuations \u2014 reduces oscillation \u2014 increases reaction time<\/li>\n<li>Scale Policy \u2014 rules for scaling speed \u2014 prevents runaway scaling \u2014 overly strict slows recovery<\/li>\n<li>Reconciliation Loop \u2014 HPA periodic process \u2014 ensures desired state \u2014 loop frequency affects reactivity<\/li>\n<li>Cooldown \u2014 wait period after scaling \u2014 prevents immediate reverse scaling \u2014 may delay fixing issues<\/li>\n<li>Horizontal Scaling \u2014 adding replicas \u2014 key method for parallelizable workloads \u2014 not for single-threaded bottlenecks<\/li>\n<li>Vertical Scaling \u2014 adjusting resources per pod \u2014 handles per-instance capacity \u2014 can cause restarts<\/li>\n<li>Pod Readiness \u2014 pod state for traffic \u2014 affects effective capacity \u2014 readiness probe misconfig breaks scaling expectations<\/li>\n<li>Pod Startup Time \u2014 time until pod ready \u2014 must be considered to set policies \u2014 long starts reduce effectiveness<\/li>\n<li>Init Containers \u2014 perform setup before app starts \u2014 increase startup time \u2014 can block scaling benefits<\/li>\n<li>Pod Disruption Budget \u2014 protects minimum available pods \u2014 can block scale down \u2014 misconfigured PDBs block upgrades<\/li>\n<li>Burstable QoS \u2014 Kubernetes QoS class \u2014 influences eviction and scheduling \u2014 poor QoS can lead to eviction under pressure<\/li>\n<li>Requests vs Limits \u2014 scheduling vs runtime limit \u2014 HPA relies on requests for CPU-based scaling \u2014 wrong request values break scaling<\/li>\n<li>Metric Cardinality \u2014 number of unique metric labels \u2014 high cardinality increases costs \u2014 adapters struggle at scale<\/li>\n<li>Throttling \u2014 API server or adapter throttles \u2014 stalls scaling operations \u2014 monitor 429\/5xx<\/li>\n<li>Rate vs Gauge \u2014 rate measures per second, gauge measures current value \u2014 choose correct type for desired behavior<\/li>\n<li>Annotation \u2014 metadata on K8s objects \u2014 used to tune HPA behavior \u2014 sprawling annotations hinder manageability<\/li>\n<li>Replica Target \u2014 desired replica count \u2014 direct HPA output \u2014 sudden changes cause downstream effects<\/li>\n<li>Overprovisioning \u2014 adding buffer capacity \u2014 reduces risk of cold starts \u2014 increases cost<\/li>\n<li>Underprovisioning \u2014 insufficient replicas \u2014 increases errors \u2014 leads to KPIs failures<\/li>\n<li>Cost-aware scaling \u2014 factor cost into scaling decisions \u2014 reduces spend \u2014 requires integration with billing<\/li>\n<li>Predictive Scaling \u2014 anticipatory scaling using forecasts \u2014 smooths reactions \u2014 requires historical data and models<\/li>\n<li>Autoscaling Events \u2014 audit trail entries for scaling actions \u2014 essential for postmortem \u2014 often ignored<\/li>\n<li>Horizontal Pod Autoscaler v2 \u2014 supports multiple metrics and behaviors \u2014 provides flexibility \u2014 API stability varies<\/li>\n<li>Scale Subresource \u2014 Kubernetes API endpoint for scaling \u2014 used for programmatic changes \u2014 RBAC needed<\/li>\n<li>Eviction \u2014 pod termination due to pressure \u2014 impacts availability \u2014 should be monitored<\/li>\n<li>Graceful Termination \u2014 controlled shutdown of pod \u2014 important for safe scale down \u2014 missing hooks cause errors<\/li>\n<li>Convergence \u2014 time to reach steady state after scaling \u2014 affects SLA \u2014 depends on startup and scheduling<\/li>\n<li>Canary \u2014 targeted rollout technique \u2014 HPA must be coordinated with canary traffic split \u2014 otherwise skewed metrics<\/li>\n<li>Multi-metric scaling \u2014 combining metrics for decisions \u2014 reduces false positives \u2014 complexity increases<\/li>\n<li>Telemetry pipeline \u2014 ingestion, storage, and exposure of metrics \u2014 reliability is critical \u2014 data loss hides real load<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure horizontal pod autoscaler (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Replica count<\/td>\n<td>Current scaling level<\/td>\n<td>kubectl get hpa or metrics API<\/td>\n<td>N A aim for stability<\/td>\n<td>Watch desired vs actual diff<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Desired replicas<\/td>\n<td>HPA computed target<\/td>\n<td>HPA status.desiredReplicas<\/td>\n<td>N A should follow load<\/td>\n<td>Stale metrics cause mismatch<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>CPU utilization<\/td>\n<td>Load proxy for compute need<\/td>\n<td>node kubelet or Prometheus query<\/td>\n<td>50 60% per pod typical<\/td>\n<td>Wrong requests invalidate result<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Request rate RPS<\/td>\n<td>Traffic driving scaling<\/td>\n<td>Ingress or app metrics<\/td>\n<td>Baseline from historical percentiles<\/td>\n<td>Sudden spikes may be anomalous<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Request latency P99<\/td>\n<td>User experience under scale<\/td>\n<td>App traces or metrics<\/td>\n<td>SLO dependent e g 200ms<\/td>\n<td>Tail latency sensitive to startup<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Pod startup time<\/td>\n<td>Time to readiness<\/td>\n<td>Histogram from kube events or app<\/td>\n<td>Prefer &lt;10s for web tiers<\/td>\n<td>Image pulls and init containers increase it<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>Pending pods<\/td>\n<td>Scheduling failures<\/td>\n<td>kube API pending pod count<\/td>\n<td>0 ideally<\/td>\n<td>Indicates node capacity problems<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>Scale events rate<\/td>\n<td>How often HPA changes replicas<\/td>\n<td>Audit or event stream<\/td>\n<td>Less than 1 per 5 min typical<\/td>\n<td>High rate indicates oscillation<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>API server errors<\/td>\n<td>HPA interactions with API<\/td>\n<td>API server metrics 4xx 5xx<\/td>\n<td>Near zero<\/td>\n<td>Throttling causes missed actions<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Cost per replica<\/td>\n<td>Financial impact<\/td>\n<td>Cloud billing divided by replicas<\/td>\n<td>Use budget constraints<\/td>\n<td>Billing granularity lag<\/td>\n<\/tr>\n<tr>\n<td>M11<\/td>\n<td>Queue length<\/td>\n<td>Work backlog for workers<\/td>\n<td>Consumer group lag or queue metrics<\/td>\n<td>Keep below target threshold<\/td>\n<td>Incorrect consumer concurrency breaks metric<\/td>\n<\/tr>\n<tr>\n<td>M12<\/td>\n<td>Pod readiness failures<\/td>\n<td>Failed readiness probes<\/td>\n<td>Kube events and probe metrics<\/td>\n<td>Near zero<\/td>\n<td>Misconfigured probes hide health<\/td>\n<\/tr>\n<tr>\n<td>M13<\/td>\n<td>Evictions<\/td>\n<td>Resource pressure incidents<\/td>\n<td>Kube eviction events<\/td>\n<td>Zero is goal<\/td>\n<td>Evictions indicate resource starvation<\/td>\n<\/tr>\n<tr>\n<td>M14<\/td>\n<td>Autoscaler latency<\/td>\n<td>Time from metric to change<\/td>\n<td>Timestamp diffs of events<\/td>\n<td>&lt;seconds to tens of seconds<\/td>\n<td>Depends on reconciliation interval<\/td>\n<\/tr>\n<tr>\n<td>M15<\/td>\n<td>Anomaly rate<\/td>\n<td>Fraction of scaling anomalies<\/td>\n<td>Post-facto evaluation<\/td>\n<td>Minimal<\/td>\n<td>Requires labeled incidents<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure horizontal pod autoscaler<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Prometheus<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for horizontal pod autoscaler: Metrics ingestion for CPU, memory, custom app metrics, HPA desired vs current.<\/li>\n<li>Best-fit environment: Kubernetes clusters with self-managed observability.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy Prometheus with node and kube-state exporters.<\/li>\n<li>Configure scraping for app metrics and HPA objects.<\/li>\n<li>Install Prometheus adapter for custom metrics.<\/li>\n<li>Define recording rules for rate metrics.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible queries and alerting.<\/li>\n<li>Wide ecosystem and adapters.<\/li>\n<li>Limitations:<\/li>\n<li>Operational overhead at scale.<\/li>\n<li>Requires tuning for retention and cardinality.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Metrics Server<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for horizontal pod autoscaler: CPU and memory usage used by HPA v1 targets.<\/li>\n<li>Best-fit environment: Small to medium clusters needing basic autoscaling.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy metrics-server in-cluster.<\/li>\n<li>Ensure kubelet metric endpoints are reachable.<\/li>\n<li>Verify HPA can query metrics API.<\/li>\n<li>Strengths:<\/li>\n<li>Lightweight, low overhead.<\/li>\n<li>Built-in compatibility with HPA.<\/li>\n<li>Limitations:<\/li>\n<li>No custom metrics support.<\/li>\n<li>Limited historical data.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Datadog<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for horizontal pod autoscaler: HPA events, pod metrics, traces, and cost-related dashboards.<\/li>\n<li>Best-fit environment: Enterprises using managed observability.<\/li>\n<li>Setup outline:<\/li>\n<li>Install Datadog agent with Kubernetes integration.<\/li>\n<li>Configure custom metric collection and dashboards.<\/li>\n<li>Link events to deployments and services.<\/li>\n<li>Strengths:<\/li>\n<li>Integrated APM and logs.<\/li>\n<li>Rich dashboards and alerts.<\/li>\n<li>Limitations:<\/li>\n<li>Cost and vendor lock-in concerns.<\/li>\n<li>Metric cardinality limits.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 KEDA<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for horizontal pod autoscaler: Event sources and scaler triggers metrics like queue length, lag.<\/li>\n<li>Best-fit environment: Event-driven workloads and serverless patterns on Kubernetes.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy KEDA operator.<\/li>\n<li>Configure ScaledObject pointing to trigger source.<\/li>\n<li>Ensure RBAC and adapter permissions.<\/li>\n<li>Strengths:<\/li>\n<li>Supports many event sources out of box.<\/li>\n<li>Scales based on external triggers.<\/li>\n<li>Limitations:<\/li>\n<li>Adds another controller and complexity.<\/li>\n<li>Behavior differs from native HPA in some cases.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Cloud provider managed metrics (EKS\/GKE\/AKS)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for horizontal pod autoscaler: Node and cluster level signals and managed HPA integrations.<\/li>\n<li>Best-fit environment: Managed Kubernetes service users.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable provider monitoring addons.<\/li>\n<li>Link metrics to HPA via provider adapters.<\/li>\n<li>Configure IAM permissions for metric access.<\/li>\n<li>Strengths:<\/li>\n<li>Lower operational overhead.<\/li>\n<li>Integrated with billing and cloud metrics.<\/li>\n<li>Limitations:<\/li>\n<li>Less flexible for custom metrics.<\/li>\n<li>Varies by provider.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for horizontal pod autoscaler<\/h3>\n\n\n\n<p>Executive dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Aggregate replica counts across services and change rate.<\/li>\n<li>Cost impact of autoscaling over last 30 days.<\/li>\n<li>SLO compliance and top services over threshold.<\/li>\n<li>High level pending pod counts and node pressure.<\/li>\n<li>Why: For executives to see cost vs reliability tradeoffs and risks.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Per-service desired vs actual replicas.<\/li>\n<li>Pending pods and scheduling failures.<\/li>\n<li>Pod startup latencies and readiness failure rates.<\/li>\n<li>Recent HPA events with timestamps and actor.<\/li>\n<li>Why: Rapid identification of scaling failures and immediate remediation.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>HPA status object details and metric values used for computation.<\/li>\n<li>Raw metric timeseries feeding HPA.<\/li>\n<li>Pod lifecycle events and image pull durations.<\/li>\n<li>API server error rates and adapter health.<\/li>\n<li>Why: Deep troubleshooting for scaling logic and metric integrity.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Page vs ticket:<\/li>\n<li>Page (P1\/P0) for sustained SLA breaches or cluster-wide scheduling failures.<\/li>\n<li>Ticket for transient scaling hiccups or single-service misconfigurations.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>If error budget burn exceeds 2x expected rate in 1 hour, trigger paging.<\/li>\n<li>For progressive escalation use 1 hour and 6 hour windows.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Dedupe similar alerts by service and cluster.<\/li>\n<li>Group by deployment and responsible team.<\/li>\n<li>Suppress alerts during planned maintenance windows.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Kubernetes cluster with version supporting HPA v2+ for custom metrics.\n&#8211; Metrics Server or Prometheus adapter deployed.\n&#8211; Resource requests set for pods.\n&#8211; RBAC configured for metric adapters.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Expose relevant application metrics: RPS, latency histograms, queue lag.\n&#8211; Ensure unique labels are controlled to avoid cardinality explosion.\n&#8211; Add readiness and liveness probes to pods.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Deploy Prometheus or use managed metrics.\n&#8211; Configure scraping frequency and retention aligned with HPA reaction needs.\n&#8211; Expose metrics via Prometheus adapter to Kubernetes metrics API if using custom metrics.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLIs (latency P95\/P99, error rate).\n&#8211; Create SLO targets and calculate error budgets.\n&#8211; Tie HPA behavior to SLOs: more aggressive scaling for high-priority SLOs.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Create executive, on-call, and debug dashboards as above.\n&#8211; Add historical trend panels to evaluate scaling over time.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Alert on missed SLOs, persistent pending pods, and metric pipeline failures.\n&#8211; Route paging alerts to service owner; route info alerts to platform team.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Runbooks for common HPA problems: adapter failures, API throttling, scale overrun.\n&#8211; Automations: auto-pause scaling during deployments, automated upper bound enforcement.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Load tests that mimic traffic patterns and measure reaction.\n&#8211; Chaos tests that simulate metrics server outage and node failures.\n&#8211; Game days to exercise runbooks with realistic team workflows.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Periodic tuning of targets and stabilization windows.\n&#8211; Postmortems for scaling-related incidents and update SLOs accordingly.\n&#8211; Automate analysis of HPA events and cost tradeoffs.<\/p>\n\n\n\n<p>Checklists<\/p>\n\n\n\n<p>Pre-production checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Metrics available and validated.<\/li>\n<li>Resource requests set across pods.<\/li>\n<li>Max and min replicas configured.<\/li>\n<li>Readiness probes in place.<\/li>\n<li>Alerts configured for pending pods and startup latency.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Integration with Cluster Autoscaler tested.<\/li>\n<li>RBAC policies for metrics adapter validated.<\/li>\n<li>Runbook reviewed and owners assigned.<\/li>\n<li>Cost guardrails and budget alerts configured.<\/li>\n<li>Canary traffic tested with HPA active.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to horizontal pod autoscaler:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Verify metric pipeline health.<\/li>\n<li>Check HPA status.desiredReplicas vs current.<\/li>\n<li>Inspect pod startup times and image pull errors.<\/li>\n<li>Confirm Cluster Autoscaler status if pods pending.<\/li>\n<li>Temporarily set maxReplicas or pause scaling if runaway.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of horizontal pod autoscaler<\/h2>\n\n\n\n<p>1) Web frontend autoscaling\n&#8211; Context: Public web app with diurnal traffic.\n&#8211; Problem: Manual scaling leads to overprovisioning.\n&#8211; Why HPA helps: Scales replicas with demand to meet latency SLIs.\n&#8211; What to measure: RPS, latency P95, replica count.\n&#8211; Typical tools: Prometheus, HPA v2.<\/p>\n\n\n\n<p>2) API service with unpredictable spikes\n&#8211; Context: Payment API with occasional bursts.\n&#8211; Problem: Latency spikes during bursts.\n&#8211; Why HPA helps: Adds capacity fast to reduce tail latency.\n&#8211; What to measure: P99 latency, error rate, CPU.\n&#8211; Typical tools: Metrics Server, Horizontal Pod Autoscaler.<\/p>\n\n\n\n<p>3) Background worker pool for message processing\n&#8211; Context: Queue consumers processing backlog.\n&#8211; Problem: Backlog increases under load.\n&#8211; Why HPA helps: Scale based on queue depth to process backlog.\n&#8211; What to measure: Queue length, consumer lag, processing time.\n&#8211; Typical tools: KEDA or Prometheus adapter.<\/p>\n\n\n\n<p>4) Batch jobs converted to parallel tasks\n&#8211; Context: ETL jobs that can run concurrently.\n&#8211; Problem: Long job durations causing delays.\n&#8211; Why HPA helps: Temporarily scale workers during batch window.\n&#8211; What to measure: Job completion time, worker concurrency.\n&#8211; Typical tools: Kubernetes Jobs, HPA, Prometheus.<\/p>\n\n\n\n<p>5) Canary deployments under load\n&#8211; Context: Staged rollout with partial traffic.\n&#8211; Problem: Canary misbehaves under scale.\n&#8211; Why HPA helps: Ensures canary is tested at realistic load.\n&#8211; What to measure: Canary latency and error rate vs baseline.\n&#8211; Typical tools: Istio\/traffic routers with HPA.<\/p>\n\n\n\n<p>6) Autoscaling for ephemeral services in CI\n&#8211; Context: Test environments created per PR.\n&#8211; Problem: Resource usage spikes during parallel tests.\n&#8211; Why HPA helps: Scale test runners to match concurrency.\n&#8211; What to measure: Job queue, pod startup time.\n&#8211; Typical tools: Argo, HPA.<\/p>\n\n\n\n<p>7) Serverless-like workloads on Kubernetes\n&#8211; Context: Ingress-triggered short-lived pods.\n&#8211; Problem: Need per-event scaling without overprovisioning.\n&#8211; Why HPA helps: Combine with KEDA to scale to zero or low counts.\n&#8211; What to measure: Invocation rate and cold start metrics.\n&#8211; Typical tools: KEDA, Knative, HPA.<\/p>\n\n\n\n<p>8) Multi-tenant platform services\n&#8211; Context: Shared API gateway serving many tenants.\n&#8211; Problem: Multi-tenant spikes affecting others.\n&#8211; Why HPA helps: Scale gateway while applying QoS and limits.\n&#8211; What to measure: Connection count, error rate, per-tenant usage.\n&#8211; Typical tools: Envoy, Prometheus, HPA.<\/p>\n\n\n\n<p>9) Autoscaling data ingestion pipelines\n&#8211; Context: Ingests intermittent large datasets.\n&#8211; Problem: Sudden ingestion bursts overwhelm consumers.\n&#8211; Why HPA helps: Increase workers on ingestion events.\n&#8211; What to measure: Ingest throughput, queue length.\n&#8211; Typical tools: Kafka metrics, KEDA, HPA.<\/p>\n\n\n\n<p>10) Cost containment experiments\n&#8211; Context: Need to reduce cloud spend for dev envs.\n&#8211; Problem: Idle services kept at high replica counts.\n&#8211; Why HPA helps: Scale down in low-usage windows.\n&#8211; What to measure: Replica uptime, cost per replica.\n&#8211; Typical tools: HPA, cluster autoscaler, billing alerts.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes public API service autoscaling<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Public REST API deployed as a Deployment on Kubernetes with variable traffic spikes.\n<strong>Goal:<\/strong> Maintain P95 latency below 200ms while minimizing cost.\n<strong>Why horizontal pod autoscaler matters here:<\/strong> Automatically adjusts replicas to meet latency targets during traffic changes.\n<strong>Architecture \/ workflow:<\/strong> Ingress -&gt; Deployment with HPA using Prometheus custom metric (request latency) -&gt; Cluster Autoscaler for node capacity.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Expose latency metric in app and scrape with Prometheus.<\/li>\n<li>Deploy Prometheus adapter to expose custom metrics.<\/li>\n<li>Create HPA targeting latency P95 via HPA v2.<\/li>\n<li>Set minReplicas 2 maxReplicas 50 and stabilization window 3m.<\/li>\n<li>Integrate with Cluster Autoscaler to provision nodes.\n<strong>What to measure:<\/strong> P95 latency, desired vs actual replicas, pod startup time, pending pods.\n<strong>Tools to use and why:<\/strong> Prometheus for metrics, Prometheus adapter for HPA, Cluster Autoscaler for node scaling.\n<strong>Common pitfalls:<\/strong> Misconfigured latency metric type, long pod startup times, insufficient node quotas.\n<strong>Validation:<\/strong> Load test with synthetic traffic ramps and spikes, confirm latency stays under SLO.\n<strong>Outcome:<\/strong> Auto-responsiveness to traffic with capped cost and maintained SLO.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless managed-PaaS with event-driven workers<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A managed PaaS running on Kubernetes for processing webhook events with bursty arrivals.\n<strong>Goal:<\/strong> Scale workers to process queue backlog without manual intervention.\n<strong>Why horizontal pod autoscaler matters here:<\/strong> Enables event-driven scaling to handle bursts efficiently.\n<strong>Architecture \/ workflow:<\/strong> Event source -&gt; KEDA scaler -&gt; HPA controls Deployment replicas -&gt; Worker pods process events.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Deploy KEDA and configure scaled object for webhook queue.<\/li>\n<li>Configure processed events metric mapping for HPA.<\/li>\n<li>Define minReplicas 0 maxReplicas 100 with cooldowns.<\/li>\n<li>Add readiness probes and short startup images.\n<strong>What to measure:<\/strong> Queue length, worker processing time, cold start rate.\n<strong>Tools to use and why:<\/strong> KEDA for event triggers, Prometheus optional for custom metrics.\n<strong>Common pitfalls:<\/strong> Cold start impact if minReplicas is zero, missing adapter permissions.\n<strong>Validation:<\/strong> Replay event bursts and confirm queue drains and workers scale accordingly.\n<strong>Outcome:<\/strong> Efficient cost and responsive processing during bursts.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident-response postmortem for scaling failure<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Production outage where API error rates spiked though HPA did not scale.\n<strong>Goal:<\/strong> Root cause and mitigations to prevent recurrence.\n<strong>Why horizontal pod autoscaler matters here:<\/strong> Failure to scale caused SLO breach and revenue loss.\n<strong>Architecture \/ workflow:<\/strong> HPA -&gt; Metrics API -&gt; Prometheus adapter -&gt; Deployment.\n<strong>Step-by-step implementation during incident:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Check Metrics API availability and Prometheus adapter logs.<\/li>\n<li>Inspect HPA status and events for errors.<\/li>\n<li>Verify desiredReplicas and whether API server accepted updates.<\/li>\n<li>Temporarily set replicas manually to restore service.\n<strong>What to measure:<\/strong> Metrics server health, HPA events, API server 429s, pod startup time.\n<strong>Tools to use and why:<\/strong> kubectl, Prometheus, cluster logs, alerting history.\n<strong>Common pitfalls:<\/strong> Missing RBAC permissions after cluster upgrades, adapter misconfig during rollover.\n<strong>Validation:<\/strong> Postmortem including timeline, root cause, and action items like retry\/backoff improvements.\n<strong>Outcome:<\/strong> Restored service and implemented monitoring and automation to prevent recurrence.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance trade-off for batch processing<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Batch image processing pipeline that can parallelize but costs increase with replica count.\n<strong>Goal:<\/strong> Meet nightly batch SLAs while minimizing cost.\n<strong>Why horizontal pod autoscaler matters here:<\/strong> Autoscale workers to process within the window, scale back afterwards.\n<strong>Architecture \/ workflow:<\/strong> Job orchestrator -&gt; Deployment of workers with HPA based on queue length -&gt; Node autoscaler to add nodes.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Measure historical batch load to set target throughput.<\/li>\n<li>Configure HPA to scale on queue length and processing time.<\/li>\n<li>Set maxReplicas to control cost and minReplicas for minimal throughput.<\/li>\n<li>Implement predictive scaling before batch window to warm nodes.\n<strong>What to measure:<\/strong> Job completion time, cost per job, replica hours.\n<strong>Tools to use and why:<\/strong> Prometheus for queue metrics, scheduler for job orchestration.\n<strong>Common pitfalls:<\/strong> Predictive model inaccuracy causing overprovisioning, long startup times.\n<strong>Validation:<\/strong> Run test batches and compare cost and SLA adherence.\n<strong>Outcome:<\/strong> Achieve SLA within cost budget by mixing predictive and reactive scaling.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>(15\u201325 items with Symptom -&gt; Root cause -&gt; Fix; include observability pitfalls)<\/p>\n\n\n\n<p>1) Symptom: No scaling despite increased latency -&gt; Root cause: Metrics adapter misconfigured -&gt; Fix: Validate adapter logs and metrics API endpoints.\n2) Symptom: Excessive scaling churn -&gt; Root cause: No stabilization window or noisy metric -&gt; Fix: Add smoothing, use rates, increase stabilization.\n3) Symptom: Pods pending after scale up -&gt; Root cause: Node capacity exhausted -&gt; Fix: Integrate Cluster Autoscaler and review resource requests.\n4) Symptom: HPA shows desired higher than actual -&gt; Root cause: API server rejects updates or RBAC issues -&gt; Fix: Check events and RBAC logs.\n5) Symptom: High cost after autoscale -&gt; Root cause: No maxReplicas or anomaly detection -&gt; Fix: Set upper bounds and cost-aware policies.\n6) Symptom: Scale based on garbage metrics -&gt; Root cause: High cardinality or incorrect metric semantics -&gt; Fix: Control labels and use appropriate metric type.\n7) Symptom: Slow recovery after scale -&gt; Root cause: Large images or heavy init containers -&gt; Fix: Optimize images, use image pull secrets and caches.\n8) Symptom: HPA not reading custom metric -&gt; Root cause: Prometheus adapter mislabeling -&gt; Fix: Verify metric name mapping and registration.\n9) Symptom: Scale down causes errors -&gt; Root cause: Aggressive scale down removing critical instances -&gt; Fix: Use PodDisruptionBudget and graceful drains.\n10) Symptom: Alerts fire but no paging needed -&gt; Root cause: Alert thresholds too tight -&gt; Fix: Raise thresholds and add suppression windows.\n11) Symptom: Observability missing during incidents -&gt; Root cause: Low retention or sampling -&gt; Fix: Increase retention for critical metrics and trace sampling during incidents.\n12) Symptom: HPA reacts to outlier spikes -&gt; Root cause: No anomaly filtering -&gt; Fix: Use sustained metrics or require sustained breach before scaling.\n13) Symptom: Canary rollout interferes with HPA -&gt; Root cause: Metric mixing between canary and baseline -&gt; Fix: Use separate metrics or traffic split labels.\n14) Symptom: API throttling errors -&gt; Root cause: High reconciliation rate or many HPAs -&gt; Fix: Increase reconciliation interval and aggregate HPAs where possible.\n15) Symptom: Jobs not suitable for HPA -&gt; Root cause: Non-parallelizable tasks -&gt; Fix: Use job schedulers or horizontal partitioning redesign.\n16) Symptom: HPA uses CPU but CPU unrelated to load -&gt; Root cause: Wrong metric choice -&gt; Fix: Use request rate or latency metrics instead.\n17) Symptom: Unexpected pod restarts on scale down -&gt; Root cause: lifecycle hooks or finalizers -&gt; Fix: Ensure graceful termination and finalize hooks.\n18) Symptom: Metrics pipeline lag -&gt; Root cause: Scrape intervals too sparse or storage backpressure -&gt; Fix: Tune scrape interval and retention, add capacity.\n19) Symptom: Missing owner reference prevents scaling -&gt; Root cause: Custom controller object not supported -&gt; Fix: Ensure HPA targets supported controllers.\n20) Symptom: Observability costs explode -&gt; Root cause: High metric cardinality from labels -&gt; Fix: Reduce labels and use recording rules.\n21) Symptom: HPA not scaling to zero -&gt; Root cause: MinReplicas &gt; 0 or dependency constraints -&gt; Fix: Set minReplicas to zero where safe and use KEDA if needed.\n22) Symptom: Unexplained latency during scale -&gt; Root cause: Load balancer reassignments -&gt; Fix: Tune load balancer health checks and session affinity.<\/p>\n\n\n\n<p>Observability pitfalls (at least five included above):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Low retention hides trends.<\/li>\n<li>Trace sampling omits tail cases.<\/li>\n<li>Metric cardinality costs and causes scrapes to fail.<\/li>\n<li>Missing HPA event logging.<\/li>\n<li>Not linking scaling events to alerts and postmortems.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform team owns HPA infrastructure and metrics pipeline.<\/li>\n<li>Service teams own HPA tuning and SLOs for their services.<\/li>\n<li>On-call rotations split between platform for infra and service for app incidents.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbooks: Step-by-step instructions for known issues like adapter outage.<\/li>\n<li>Playbooks: Decision guides for ambiguous incidents including escalation paths.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Canary deployments that isolate canary metrics from HPA.<\/li>\n<li>Use rollbacks and automated health checks before increasing traffic.<\/li>\n<li>Pause autoscaling during critical rollout windows if necessary.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use automated tuning pipelines that suggest HPA targets based on historical data.<\/li>\n<li>Alert-driven automation for temporary scaling to avoid repeated manual steps.<\/li>\n<li>Automate canary promotion only when SLIs held with HPA active.<\/li>\n<\/ul>\n\n\n\n<p>Security basics:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limit metrics adapter permissions via RBAC.<\/li>\n<li>Restrict who can edit HPA objects with admission controls.<\/li>\n<li>Monitor audit logs for changes to HPA or scaling-related secrets.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review top scaling events and any alerts triggered.<\/li>\n<li>Monthly: Audit HPA configurations and max\/min settings against costs and SLOs.<\/li>\n<li>Quarterly: Load test and run predictive tuning for traffic patterns.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems related to horizontal pod autoscaler:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Timeline of scaling events and metric values.<\/li>\n<li>Why autoscaler made decisions it did.<\/li>\n<li>Any metric pipeline lag or false signals.<\/li>\n<li>Action items to prevent recurrence and update runbooks.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for horizontal pod autoscaler (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>Metrics store<\/td>\n<td>Stores and queries metrics<\/td>\n<td>Prometheus exporters HPA adapter<\/td>\n<td>Scale by custom metrics<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Metrics adapter<\/td>\n<td>Exposes custom metrics to K8s API<\/td>\n<td>Prometheus Kubernetes HPA<\/td>\n<td>Must be reliable and low latency<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Event-driven scaler<\/td>\n<td>Scales on external events<\/td>\n<td>Kafka RabbitMQ cloud services<\/td>\n<td>Useful for serverless patterns<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>Cluster autoscaler<\/td>\n<td>Scales nodes based on pending pods<\/td>\n<td>Cloud provider APIs HPA<\/td>\n<td>Needed when pods pending due to no nodes<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>Observability<\/td>\n<td>Dashboards and alerts for HPA<\/td>\n<td>Grafana Datadog dashboards<\/td>\n<td>Visualize desired vs actual<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>CI\/CD<\/td>\n<td>Applies HPA configs in pipelines<\/td>\n<td>GitOps Argo CD Flux<\/td>\n<td>Use for reproducible configs<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Cost monitoring<\/td>\n<td>Tracks spend per replica\/service<\/td>\n<td>Billing export dashboards<\/td>\n<td>Enables cost-aware scaling<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>Security<\/td>\n<td>RBAC and admission controllers<\/td>\n<td>OPA Gatekeeper audit logs<\/td>\n<td>Controls who can change HPA<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>Load testing<\/td>\n<td>Validates HPA behavior under load<\/td>\n<td>Locust JMeter test harness<\/td>\n<td>Required for validation<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Incident management<\/td>\n<td>Pager and runbook orchestration<\/td>\n<td>PagerDuty ChatOps<\/td>\n<td>Connect scaling alerts to responders<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What metrics should I use for HPA?<\/h3>\n\n\n\n<p>Use metrics that closely correlate with work demand like RPS, queue length, or latency; CPU is acceptable for CPU-bound workloads.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can HPA scale stateful sets safely?<\/h3>\n\n\n\n<p>It can scale StatefulSets but ordered semantics and persistent identity may introduce correctness issues; evaluate application design first.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does HPA manage node scaling?<\/h3>\n\n\n\n<p>No, HPA manages pod replicas. Use Cluster Autoscaler or cloud provider services for node scaling.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How fast does HPA react?<\/h3>\n\n\n\n<p>Reaction time depends on reconciliation interval, metric scrape frequency, stabilization windows, and pod startup time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can HPA scale to zero?<\/h3>\n\n\n\n<p>HPA can set minReplicas to zero for some workloads; KEDA or Knative provide more robust scale-to-zero semantics.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I prevent cost runaway?<\/h3>\n\n\n\n<p>Set maxReplicas, use anomaly detection, and integrate cost monitoring to alert on unexpected scale patterns.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What happens if metrics API is down?<\/h3>\n\n\n\n<p>HPA cannot fetch metrics reliably and may stop scaling or use stale values; implement alerts for metric pipeline health.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is CPU a good default for all services?<\/h3>\n\n\n\n<p>No. CPU is fine for compute-bound tasks but poor for IO-bound or latency-sensitive services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can I combine HPA with VPA?<\/h3>\n\n\n\n<p>Yes, but use the VPA in recommend mode or set policies to avoid conflicts; coordinate with platform tooling.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I debug HPA decisions?<\/h3>\n\n\n\n<p>Inspect HPA object status, events, metric timeseries feeding HPA, adapter logs, and API server events.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What security constraints apply to HPA metrics?<\/h3>\n\n\n\n<p>Adapters and HPA require RBAC permissions to read metrics and update deployments; limit access via policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to avoid oscillation?<\/h3>\n\n\n\n<p>Use stabilization windows, rate metrics, conservative scale policies, and lower sensitivity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does Prometheus scaling induce high load?<\/h3>\n\n\n\n<p>Misconfigured Prometheus scraping at high cardinality can cause high CPU and storage usage; use recording rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What should be the reconciliation frequency?<\/h3>\n\n\n\n<p>Default is fine for many workloads; increase only if you need faster responses and can support metric throughput.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can HPA use external cloud metrics like SQS length?<\/h3>\n\n\n\n<p>Yes, via external metrics API or adapters like KEDA or custom adapters.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to handle slow-start applications?<\/h3>\n\n\n\n<p>Use pre-warmed pods, lower scale thresholds, or predictive scaling to prevent SLA blips.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Are there predictive autoscalers in Kubernetes?<\/h3>\n\n\n\n<p>Not built-in; use external predictive systems or ML-driven controllers integrated with HPA or custom controllers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I test HPA in CI?<\/h3>\n\n\n\n<p>Run synthetic load tests that simulate realistic patterns and assert SLOs and replica behavior under controlled conditions.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Horizontal Pod Autoscaler is a core mechanism for achieving scalable, resilient, and cost-effective workloads in Kubernetes. It requires proper observability, sane defaults, and integration with node autoscaling and application design to be effective. Treat HPA as part of an ecosystem: metrics, controllers, cluster capacity, runbooks, and ownership.<\/p>\n\n\n\n<p>Next 7 days plan:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Validate metrics pipeline and deploy Prometheus adapter or ensure metrics-server works.<\/li>\n<li>Day 2: Inventory services with missing resource requests and add requests\/limits.<\/li>\n<li>Day 3: Create basic HPA for a non-critical service using CPU and set safe min\/max.<\/li>\n<li>Day 4: Build on-call dashboard showing desired vs actual replicas and pending pods.<\/li>\n<li>Day 5: Run a controlled load test to observe HPA reactions and patch probes.<\/li>\n<li>Day 6: Define SLOs for top services and tie HPA configs to SLO sensitivity.<\/li>\n<li>Day 7: Document runbooks for common HPA failures and schedule a game day.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 horizontal pod autoscaler Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>horizontal pod autoscaler<\/li>\n<li>HPA Kubernetes<\/li>\n<li>Kubernetes autoscaling<\/li>\n<li>HPA tutorial<\/li>\n<li>\n<p>horizontal pod autoscaler 2026<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>HPA vs VPA<\/li>\n<li>HPA Prometheus adapter<\/li>\n<li>HPA best practices<\/li>\n<li>HPA failure modes<\/li>\n<li>\n<p>Kubernetes scaling patterns<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>how does horizontal pod autoscaler work in kubernetes<\/li>\n<li>how to scale pods automatically in kubernetes with hpa<\/li>\n<li>best metrics to use with horizontal pod autoscaler<\/li>\n<li>how to prevent oscillation with hpa<\/li>\n<li>hpa vs cluster autoscaler differences<\/li>\n<li>can hpa scale statefulset safely<\/li>\n<li>how to debug hpa not scaling<\/li>\n<li>how to set resource requests for hpa<\/li>\n<li>how to use custom metrics with hpa<\/li>\n<li>how to limit cost when using hpa<\/li>\n<li>how to scale to zero with hpa<\/li>\n<li>what is stabilization window in hpa<\/li>\n<li>predictive scaling alternatives to hpa<\/li>\n<li>keda vs hpa for event driven scaling<\/li>\n<li>\n<p>how to measure hpa effectiveness<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>metrics API<\/li>\n<li>metrics-server<\/li>\n<li>prometheus adapter<\/li>\n<li>custom metrics<\/li>\n<li>external metrics<\/li>\n<li>pod readiness<\/li>\n<li>pod startup time<\/li>\n<li>cluster autoscaler<\/li>\n<li>vertical pod autoscaler<\/li>\n<li>prometheus<\/li>\n<li>keda<\/li>\n<li>canary deployment<\/li>\n<li>pod disruption budget<\/li>\n<li>resource requests<\/li>\n<li>resource limits<\/li>\n<li>stabilization window<\/li>\n<li>scale policy<\/li>\n<li>reconciliation loop<\/li>\n<li>cost-aware scaling<\/li>\n<li>predictive autoscaling<\/li>\n<li>event-driven scaling<\/li>\n<li>autoscaler latency<\/li>\n<li>pending pods<\/li>\n<li>eviction events<\/li>\n<li>API throttling<\/li>\n<li>telemetry pipeline<\/li>\n<li>cardinality<\/li>\n<li>observability dashboard<\/li>\n<li>runbook<\/li>\n<li>game day<\/li>\n<li>incident response<\/li>\n<li>SLI SLO<\/li>\n<li>error budget<\/li>\n<li>readiness probe<\/li>\n<li>liveness probe<\/li>\n<li>image pull time<\/li>\n<li>init container<\/li>\n<li>node pressure<\/li>\n<li>RBAC<\/li>\n<li>admission controller<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[239],"tags":[],"class_list":["post-1721","post","type-post","status-publish","format-standard","hentry","category-what-is-series"],"_links":{"self":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1721","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=1721"}],"version-history":[{"count":1,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1721\/revisions"}],"predecessor-version":[{"id":1843,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1721\/revisions\/1843"}],"wp:attachment":[{"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=1721"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=1721"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aiopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=1721"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}