¶ VPA
As part of CTO2B’s autoscaling architecture, the Vertical Pod Autoscaler (VPA) is used to automatically analyze and recommend optimal CPU and memory resource settings for workloads over time. This enhances reliability and performance across user deployments hosted via the CTO2B platform.
✅ Supported Application Types
At CTO2B, VPA support is integrated at the Recommender level and available for applications deployed using the following Helm chart templates:
- app-k8s-generic
- app-k8s-django-nginx
- Other app types may also support VPA if defined in default values set `vpa.enabled: true`
¶ Enabling VPA for Your Deployment
To activate VPA support in your deployment, add the following configuration to your values.yaml:
vpa:
enabled: trueOnce enabled, this will:
- Deploy a VPA custom resource to your Kubernetes cluster.
- Begin tracking CPU and memory usage metrics over time using the VPA Recommender component.
This is part of CTO2B's best-practice automation for observability and performance tuning.
¶ Viewing VPA Recommendations in Grafana
CTO2B provides pre-integrated observability via Grafana. To review VPA suggestions:
- Log in via Teleport to your Kubernetes environment.
- Access Grafana.
- Navigate to: Dashboards -> Application -> VPA recommendations.
*Figure 1.1 shows Memory recommendation setting*
As per Figure 1.1 we see that application has set memory:
- Memory Request 128MB
- Memory limit: 4GB
VPA Recommendation:
- Suggested Memory Request: 2.77GiB based on actual usage over time
As shown in Figure 1.1, VPA has analysed real-time memory consumption and recommends increasing the request to ensure stable performance under typical load. This recommendation helps avoid issues like OOM kills or underutilisation.
¶ VPA Behaviour at CTO2B
By default, CTO2B uses VPA in recommendation-only mode (updateMode: "Off"). This allows developers and DevOps teams to manually inspect and approve resource adjustments.
Advanced Mode (optional):
If desired, you can configure automatic updates by explicitly enabling:
vpa:
updateMode: "Auto"⚠️ Note: Auto mode causes pods to restart to apply new resource values.
¶ Karpenter
CTO2B uses Karpenter which is a high-performance, flexible, and extensible node provisioning system for Kubernetes clusters. It enables:
- Fast and efficient provisioning of EC2 instances
- Responsive to workload changes
- Cost-efficient resource utilisation across spot and on-demand instances
- Safe decommissioning of legacy node pools
- Dynamic scaling aligned with Terraform-based infrastructure definitions
By leveraging Karpenter, CTO2B ensures high performance and cost-optimised autoscaling for its development and production workloads. Unlike the Kubernetes Cluster Autoscaler, which modifies node groups based on predefined rules, Karpenter dynamically launches the right compute resources based on the actual scheduling needs of pods.
Karpenter and VPA work together to solve complementary problems:
- Karpenter ensures that pods can be scheduled by dynamically provisioning the right nodes.
- VPA (Vertical Pod Autoscaler) - optimise individual pod resource usage by ensuring pods request an appropriate amount of resources (CPU/memory).
Key Karpenter Features:
1. Just-In-Time Node Provisioning
- Launches nodes in real time as unscheduled pods are detected.
- Does not rely on pre-defined node groups or autoscaling groups.
- Can select the best instance types and sizes on the fly.
2. Cost Optimisation
- Uses instance attributes like price, availability, and capacity to make informed decisions.
- Supports Spot instances and On-Demand pricing models.
- Optionally integrates with EC2 Fleet API to select the most cost-efficient instances.
3. Fast Termination
- Deallocates underutilised nodes quickly to reduce cost.
- Evicts and consolidates pods automatically to optimise node usage.
4. Allows customisable Scheduling Constraints like:
- Node labels
- Zonal/Regional affinity
- Capacity type (e.g., spot vs on-demand)
- Instance size, AMI, etc.
How Karpenter Works
- A pod cannot be scheduled due to insufficient resources.
- Karpenter observes this unschedulable pod.
- It evaluates the best instance type(s) to run the pod.
- It directly interacts with the cloud provider (e.g., AWS EC2) to launch a new instance.
- The pod is scheduled once the new node joins the cluster.
- When nodes are underutilised, Karpenter may consolidate and terminate them to save cost.
⚠️ As of now, Karpenter is primarily optimised for AWS, but there is active community interest and ongoing development to support other cloud providers such as Google Cloud Platform (GCP) and Azure.