One Sketch Away

The Gimli Glider Moment In Kubernetes Sizing Ocpus Vcpus And Unit Mismatch

The Gimli Glider Moment in Kubernetes Sizing: OCPUs, vCPUs, and Unit Mismatch

gimli

In 1983, Air Canada Flight 143 ran out of fuel mid-air.

Not because the pilots forgot to refuel. Not because the math was wrong.

A Quick Note for the Uninitiated

The Gimli Glider incident was caused by a kilograms-versus-pounds conversion error during manual fuel calculation.

A failed fuel-quantity indicator forced the crew to calculate fuel manually. The aircraft’s systems expected fuel mass in kilograms, but an incorrect conversion using pounds was applied instead.

The math was internally consistent. The unit assumption was wrong.

As a result, the aircraft took off with roughly 45% of the fuel it actually required.

The aircraft survived and became known as the Gimli Glider — a lasting reminder that many failures don’t happen inside systems, but at the boundaries between abstractions.

Four decades later, we still see the same failure pattern — except now it shows up in cloud infrastructure and Kubernetes sizing.

The Modern Gimli Glider: OCPU vs vCPU

In Oracle Cloud Infrastructure (OCI), compute capacity is sized in OCPUs. In Kubernetes, workloads are sized in vCPUs and millicores.

Both are casually referred to as “cores”. Both feel interchangeable. They are not.

And this is where even experienced architects can get tripped up.

A Very Familiar Sizing Conversation

The scenario usually looks like this:

Suddenly, the workload size is doubled.

Not because the application needs more compute — but because the unit silently changed.

That’s the Gimli Glider moment.

First, an Important Clarification: Our Sizing Model Is Correct

It’s important to state this clearly.

Our internal hardware sizing calculator — used for the banking products we implement — is:

This is intentional.

It maps naturally to OCI’s OCPU model, where:

In other words: The hardware sizing calculator is doing exactly what it is supposed to do. Nothing is broken here.

Where the Confusion Actually Starts: Kubernetes

The problem appears at deployment time.

Kubernetes does not speak in physical cores or OCPUs. It speaks in vCPUs and millicores.

So when an architect looks at a Pod spec and sees:

resources:
  requests:
    cpu: "8000m"

The instinctive reaction is natural: “This workload needs 8 cores.”

That statement is correct in Kubernetes terms.

But it becomes incorrect when those same numbers are fed directly into a physical-core-based sizing calculator without conversion.

Reduce Everything to the Same Unit

Let’s normalize the units.

On OCI (x86):

In Kubernetes:

Therefore:

4 OCPUs = 8 vCPUs = 8000 millicores

So if the total CPU requested across all Pods is 8000m, it does not mean you need 8 physical cores. It means you need 4 OCPUs.

The Pod specification is correct. The hardware sizing calculator is correct. Only the unit translation between them is wrong.

Why vCPU Feels Simpler — and Why That’s Misleading

Most engineers grow up with this assumption: 1 vCPU = 1 unit of compute

That assumption holds on many clouds — until it doesn’t.

What vCPU Typically Means

What OCPU Means on OCI

On x86:

1 OCPU = 2 vCPUs (industry equivalent)

So if a workload needs 12 vCPUs, you order 6 OCPUs, not 12. Many teams miss this and quietly over-allocate.

Why CPU Models Often Feel Simpler Than They Are

vCPU-based pricing often looks simpler on paper. But that simplicity comes from abstraction. Behind the scenes, it can involve:

If an application’s performance changes without its code changing, that’s usually not the application — it’s the infrastructure abstraction surfacing.

More explicit compute models may feel less intuitive at first, but they force architects to reason about capacity and units — exactly the same discipline Kubernetes already requires.

A Quick Note on ECPU (For Completeness)

OCPU is tied to physical hardware generations (Intel, AMD, ARM). That makes long-term pricing comparisons fragile.

Oracle introduced ECPU to address this:

A simple mental shortcut:

For Kubernetes sizing, however, the core lesson remains unchanged:

Always convert explicitly to vCPUs and millicores.

Why This Matters Beyond Cost

This isn’t just about saving money. Incorrect unit translation affects:

When things look inefficient, Kubernetes often gets blamed when the real issue is unit mismatch.

Closing the Loop Back to Gimli

The Gimli Glider wasn’t caused by bad pilots. It wasn’t caused by bad math.

It happened because two correct systems met without proper unit conversion.

Kubernetes Pod specs and enterprise sizing models are no different.

TL;DR

References