Kubernetes is powerful for container orchestration but notoriously difficult for cost management. The abstraction layer between pods and underlying infrastructure makes it hard to answer "how much does this service cost?"
OKE Cost Structure
OCI Kubernetes Engine (OKE) itself is free — you only pay for the underlying resources:
Worker nodes: Compute instances (the biggest cost)
Load balancers: For exposing services
Block volumes: For persistent storage
Networking: Data transfer between nodes, pods, and external services
The challenge: OCI cost reports show compute instance costs, not Kubernetes workload costs. A $500/month instance might run 20 different pods from 5 different teams.
Cluster-Level Optimization
1. Right-Size Your Node Pool
The most common mistake: over-provisioning node pools. If your pods need 10 OCPUs total but your node pool has 32 OCPUs, you're paying 3x what you need.
Action: Monitor node utilization (CPU and memory). If average utilization is below 50%, consider smaller or fewer nodes.
2. Use Multiple Node Pools
Instead of one large node pool, create specialized pools:
General pool: Standard shapes for typical workloads
Memory-optimized pool: For memory-heavy services (databases, caches)
ARM pool: A1.Flex nodes for ARM-compatible workloads (30-50% cheaper)
Use node selectors and taints to schedule pods on the appropriate pool.
3. Enable Cluster Autoscaler
OKE supports the Kubernetes Cluster Autoscaler, which automatically adjusts the number of nodes based on pod scheduling needs. This prevents both over-provisioning (wasted money) and under-provisioning (performance issues).
Configure appropriate min/max node counts:
Min: Enough nodes for your baseline workload
Max: Enough for peak periods + buffer
4. Use Flexible Shapes
OKE worker nodes support OCI flexible shapes. Instead of fixed shapes (where you might pay for 64 GB memory when you need 48 GB), use flex shapes to match exact requirements.
Pod-Level Optimization
1. Set Resource Requests and Limits
Every pod should have CPU and memory requests and limits. Without them:
•The scheduler can't efficiently pack pods onto nodes
•Pods might consume more resources than needed
•Autoscaling decisions are less accurate
2. Right-Size Pod Resources
Many Kubernetes deployments use copy-pasted resource specifications. A pod requesting 2 CPU and 4Gi memory that uses 0.1 CPU and 256Mi is wasting 95% of its allocation.
Use metrics-server or Prometheus to measure actual pod usage and adjust requests accordingly.
3. Use Horizontal Pod Autoscaler (HPA)
Scale pod replicas based on actual demand (CPU, memory, or custom metrics). This is more cost-effective than running maximum replicas 24/7.
4. Implement Pod Disruption Budgets
PDBs allow the cluster autoscaler to safely remove underutilized nodes by gracefully rescheduling pods. Without PDBs, the autoscaler is more conservative about removing nodes.
Cost Attribution
Namespace-Based Attribution
Organize workloads into namespaces that map to teams or applications. While OCI doesn't natively show per-namespace costs, you can estimate them by:
1. Tracking pod resource usage per namespace
2. Dividing node costs proportionally based on resource consumption
Labels for Cost Tracking
Apply consistent labels to all pods:
•`app`, `team`, `environment`, `cost-center`
These enable cost reporting tools to aggregate costs by business dimension.
Monitoring with OCIFinOps
OCIFinOps tracks the underlying OKE compute costs. Use it to:
•Monitor total cluster cost over time
•Identify nodes that are underutilized
•Compare costs across environments (production vs. staging clusters)
•Detect cost anomalies from unexpected autoscaling events
Ask "What's my OKE compute cost this month?" to get a quick overview, then drill into specific node pools and time ranges for detailed analysis.