CPA Introduction

​

How CPA decides replica counts

• CPA reads cluster metrics (node count and/or CPU cores) and respects the includeUnschedulableNodes setting when configured.
• It computes desired replicas using either:
  • a ladder (step) mapping — discrete thresholds, or
  • a linear formula — proportional calculation.
• CPA then updates the target Deployment’s spec.replicas through the Kubernetes API.

desired_replicas = base_replicas + (cluster_metric * scale_factor)

• base_replicas = 2
• scale factor = 1 replica per 5 nodes
• 10-node cluster -> desired_replicas = 2 + (10 / 5) * 1 = 4

​

Integration with the Kubernetes API

• CPA queries the kube-apiserver for cluster information (nodes and CPU capacity) and for the Deployments it manages.
• It calculates the desired replica count according to configuration.
• CPA then issues a patch/update to the Deployment spec.replicas field via the API.

​

Scaling modes: ladder vs linear

• Ladder mode — predictable, discrete steps. Good for strict SLAs or when you want controlled change points.
• Linear mode — continuous, proportional scaling. Good for smoother scaling based on capacity.

​

Ladder mode

data:
  ladder: |-
    {
      "coresToReplicas":
      [
      ],
      "nodesToReplicas":
      [
      ],
      "includeUnschedulableNodes": false
    }

data:
  ladder: |-
    {
      "coresToReplicas":
      [
        [1, 1],
        [64, 3],
        [512, 5]
      ],
      "nodesToReplicas":
      [
        [1, 1],
        [2, 2]
      ],
      "includeUnschedulableNodes": false
    }

• For each mapping (cores or nodes), CPA selects the largest threshold that is less than or equal to the current metric.
  • Example: a cluster with 400 cores will match the 64 threshold (since 400 >= 64 but < 512), yielding 3 replicas from coresToReplicas.
• The final replica count depends on how CPA is configured to combine the cores and nodes results (for many setups you will select the mapping for the metric you care about or merge results according to the operator’s logic).

​

Linear mode

data:
  linear: |-
    {
      "coresPerReplica": 2,
      "nodesPerReplica": 1,
      "min": 1,
      "max": 100,
      "preventSinglePointFailure": true,
      "includeUnschedulableNodes": true
    }

• Compute:
  • replicas_from_cores = ceil(total_cores / coresPerReplica)
  • replicas_from_nodes = ceil(total_nodes / nodesPerReplica)
• CPA uses the larger of the two values, then enforces min and max.
• Always round up (ceiling) to prevent under-provisioning.

• Cluster: 4 nodes, 13 cores
• coresPerReplica = 2 -> replicas_from_cores = ceil(13 / 2) = 7
• nodesPerReplica = 1 -> replicas_from_nodes = ceil(4 / 1) = 4
• Choose the higher value: 7
• Apply bounds (min=1, max=100): final replicas = 7

​

Best practices and tips

• For critical cluster services (DNS, controllers), set a conservative min and consider preventSinglePointFailure: true.
• If you need predictable capacity steps for SLA reasons, use ladder mode with deliberate thresholds.
• For smoother autoscaling reacting to cluster capacity, use linear mode and tune coresPerReplica and nodesPerReplica.
• Consider includeUnschedulableNodes only if your cluster topology requires counting nodes that are cordoned/unschedulable.

​

Summary

• CPA adjusts Deployment replicas for cluster-level services based on node count and/or CPU cores.
• Ladder mode provides discrete, threshold-based scaling; linear mode provides proportional scaling with min/max and redundancy protections.
• CPA integrates with the kube-apiserver to read cluster state and to update Deployment replica counts.
• Choose the mode and configuration that best match your reliability and capacity requirements.

​

Links and references

• Kubernetes Concepts: Scaling
• Kubernetes API Overview
• For CPA operator specifics, consult your distribution/operator documentation and ConfigMap examples for ladder and linear.