Optimize zone performance

3 min read · Intermediate

Edera zones perform well out of the box, but the default settings prioritize flexibility and resource efficiency over raw performance. This guide covers the knobs you can turn to get the most out of your zones for performance-sensitive workloads.

Zone resource annotations

Edera provides Kubernetes annotations to control how zones are resourced at creation time. Standard Kubernetes resources.requests and resources.limits still apply for cgroup enforcement inside the zone, but these annotations set the zone-level resource configuration:

Annotation	Description
`dev.edera/cpu`	Number of CPUs the zone boots with
`dev.edera/initial-memory-request`	Initial memory for the zone. Kubernetes memory requests are used for scheduling only and are never sent to the container runtime, so use this annotation to set the actual zone memory (especially important in static resource mode)
`dev.edera/resource-policy`	Resource mode: `static` or `dynamic` (default: `dynamic`)
`dev.edera/virt-backend`	Virtualization mode: `pv` or `pvh` (default: `pv`)

Example pod spec

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  annotations:
    dev.edera/cpu: "4"
    dev.edera/initial-memory-request: "4096"
    dev.edera/resource-policy: static
    dev.edera/virt-backend: pvh
spec:
  runtimeClassName: edera
  containers:
    - name: my-app
      image: my-app:latest
      resources:
        requests:
          cpu: "4"
          memory: 4Gi
        limits:
          cpu: "4"
          memory: 4Gi

Resource modes

Dynamic (default)

Zones in dynamic mode adjust CPU and memory as workload demand changes. This is the most resource-efficient option but can introduce variability under high-churn or spiky loads.

Static

Zones in static mode are allocated a fixed amount of CPU and memory at boot, similar to a traditional VM. Use static mode when your workload needs predictable, consistent performance rather than efficient resource sharing.

Set static mode with the dev.edera/resource-policy: static annotation and pair it with dev.edera/initial-memory-request to ensure the zone gets the memory it needs from the start.

Virtualization modes

PV (default)

Paravirtualization (PV) is the default mode. It is broadly compatible across cloud platforms and instance types.

PVH

PVH uses hardware virtualization extensions for higher performance. It is available on bare metal and instances that expose virtualization extensions to the guest.

Set PVH mode with the dev.edera/virt-backend: pvh annotation.

Recommended configuration for peak performance

The highest-performing configuration combines static resourcing, PVH virtualization, and generous CPU and memory allocation:

annotations:
  dev.edera/resource-policy: static
  dev.edera/virt-backend: pvh
  dev.edera/cpu: "8"
  dev.edera/initial-memory-request: "8192"

Test different combinations in your environment. Results vary based on workload type, instance type, and cloud provider.

IO and disk performance

For IO-heavy workloads, the filesystem transport layer (9p for Xen, virtiofs for KVM) provides good general-purpose performance. If your application requires high throughput or low-latency disk access, attach block devices directly to zones instead.

Direct block device attachment gives near-native IO performance by bypassing the filesystem transport entirely.

See Attach block devices to zones for setup instructions.

Last updated on 2026-06-09