While a Kubernetes cluster’s RAM tends to remain constant, its CPU tends to spike with high bursts of activity. For this reason, we recommend sizing your CPU to accommodate these spikes in your workload.
Choosing the Right Kubernetes Plan
Last verified 25 Aug 2026
DigitalOcean Kubernetes (DOKS) is a Kubernetes service with a fully managed control plane, high availability, and autoscaling. DOKS integrates with standard Kubernetes toolchains and DigitalOcean’s load balancers, volumes, CPU and GPU Droplets, API, and CLI.
Choosing the right Kubernetes plan highly depends on your workload. An oversized cluster underuses its resources and costs more, but an undersized cluster running at full CPU or memory suffers from degraded performance or errors.
This guide covers the following topics:
- How to select node machine type
- How to select node size and count
- How to make a data-driven decision
After creation, you can change a cluster’s worker configuration by adding a node pool with the desired size, draining the old node pool, and removing it. For a full list of plans and prices, see the cluster pricing page.
If this is your first time testing out Kubernetes, see our Build and Deploy Your First Image to Your First Cluster tutorial.
Select Machine Type
Nodes are built on Droplets. For bundled worker-node plans, you can choose from the following Droplet plans for your node’s machine type:
| Machine Type | CPU | vCPUs | Memory | Common Uses |
|---|---|---|---|---|
| Basic (Regular and Premium) | Shared | 1 - 8 | 1 - 16 GB RAM | Testing, Low-Traffic Servers |
| General Purpose | Dedicated | 2 - 40 | 8 - 160 GB RAM 4 GB RAM / vCPU |
Medium to High-Traffic Servers |
| CPU-Optimized | Dedicated | 2 - 48 | 4 - 96 GB 2 GB RAM / vCPU |
CI/CD, Video Encoding, Batch Processing |
| Memory-Optimized | Dedicated | 2 - 32 | 16 - 256 GB RAM 8 GB RAM / vCPU |
High-Performing Databases, Caches, Indexing |
| Storage-Optimized | Dedicated | 2 - 32 | 16 - 256 GB RAM 8 GB RAM / vCPU 150 - 225 GB SSD / vCPU |
Data Storage, Monitoring, Analytics |
All machine types, except the Basic nodes, are dedicated CPU Droplets. For more details on these machine types and their compatibility with your workload, see the respective Droplet plans.
v5 Worker Node Configurations
In supported datacenters, you can create node pools with supported v5 Droplet configurations. v5 worker nodes run on 5th Generation AMD EPYC processors and let you size compute, memory, storage, and networking independently. Shared configurations use shared vCPUs for bursty or variable workloads, while General Purpose configurations use dedicated vCPUs for consistent performance.
DigitalOcean Kubernetes (DOKS) supports a subset of the v5 configurations available for standalone Droplets. Supported v5 size slugs begin with g5- for General Purpose configurations and s5- for Shared configurations. v5 worker nodes have a 50 GiB or 80 GiB persistent NVMe boot disk. Use the List Kubernetes Options endpoint, the doctl kubernetes options sizes command, or the Control Panel to see the configurations available in a region.
v5 worker nodes are billed per second at an hourly rate without a monthly usage cap. Bundled-plan worker nodes have a monthly usage cap. For details, see Kubernetes Pricing.
Kubernetes uses the boot disk for emptyDir volumes, container image layers, and containers’ writable layers. For other application data, use a PersistentVolumeClaim backed by DigitalOcean Volumes Block Storage, which provides durable storage beyond the 80 GiB boot disk limit.
You can use bundled and v5 node pools in the same cluster. Their storage characteristics differ, so workloads that require consistent local disk performance should run on a specific node pool. Set the doks.digitalocean.com/node-pool key in a workload’s nodeSelector, replacing <node-pool-name> with the target pool:
spec:
template:
spec:
nodeSelector:
doks.digitalocean.com/node-pool: <node-pool-name>A node pool’s machine size slug is immutable. To move workloads to or from v5, create a node pool with the target configuration, drain the old node pool, and then remove it. You can still change the number of nodes in a pool directly or with autoscaling.
Select Node Size and Count
Node size and count determine the overall CPU, RAM, and storage of your cluster. The better hardware a node has, the more pods can operate effectively within it before needing another node.
Node size determines the maximum amount of memory you can allocate to pods within it. For a full breakdown of memory available per pod, see the allocatable memory table.
Because of this, we recommend using nodes with less than 2 GB of allocatable memory only for development purposes and not production. For production clusters, we recommend sizing nodes large enough (2.5 GB or more) to absorb the workload of a down node.
Larger nodes are easier to manage, are more cost efficient, and can run more demanding applications; however, they also require more pod management and cause a larger impact if they fail. If you later enable autoscaling for a node pool, DigitalOcean only adds and removes nodes of the chosen size, which results in larger spikes of both performance and cost.
Make a Data-Driven Decision
After creating a cluster, we recommend benchmarking and load testing your workload to see how it performs under simulated load. For bursty apps or batch jobs, look at resource usage when load is at its expected peak, especially when using shared CPU Basic nodes. If you notice that your app’s performance is too variable for your production needs, consider a machine type with dedicated vCPUs.
Clusters with high DNS traffic also benefit from dedicated CPU nodes, because shared CPU is prone to increased UDP latency. For details, see Use Dedicated CPU Nodes for High DNS Traffic.
CPU and RAM
Using Kubernetes metrics, you can get more information on your cluster’s CPU load and memory usage:
-
If your cluster has high CPU usage most of the time and also significant memory usage, consider scaling both vCPUs and memory and using balanced General Purpose nodes.
-
If your cluster has high CPU usage most of the time but very low memory usage, you might be able to save money with CPU-Optimized nodes.
-
If your cluster has high memory usage most of the time (potentially maxing out and swapping to disk) but low or moderate CPU usage, consider scaling memory and using Memory-Optimized nodes.
-
If your cluster has low to moderate CPU or memory usage most of the time but sometimes bursts up and hits resource limits, consider shared CPU Basic nodes and scale the limiting resource accordingly.
Network
Nodes include unlimited free inbound data transfer and some amount of free outbound data transfer, depending on the Droplet instance type and size. Depending on your workload type and bandwidth usage, you could scale your nodes to take advantage of additional free outbound data transfer. For example, streaming and video applications require more bandwidth and network capabilities.
Disk
If you need additional storage, you can use network-attached block storage to attach additional volumes to a cluster.