Installing Edera on other managed Kubernetes services

4 min read · Intermediate

Developer Platform Engineer

This guide installs Edera Protect on a managed Kubernetes cluster using the Helm chart for Edera Protect, then covers what each major cloud provider’s managed Kubernetes service does and doesn’t support.

ℹ️
Edera needs either a bare metal node or a VM that exposes nested virtualization. Fully managed Kubernetes node pools, such as the one provided through [EKS Auto Mode][eks-automode], [GKE Autopilot][gke-autopilot], [AKS Automatic][aks-automatic], do not allow any external customizations and don’t work with Edera. See Compatibility by cloud provider below before you pick a node pool.

Prerequisites

  • A Google Artifact Registry (GAR) key from Edera (key.json). Don’t have one? Contact support@edera.dev.
  • Helm 3.7 or later.
  • kubectl configured against the target cluster.
  • A node pool that meets the compatibility requirements for your cloud provider (see below).

Install the chart

The chart runs the same installer used in the Run the Edera installer guide, packaged for a Kubernetes-native rollout. It takes two values:

ValueDescription
imageThe Protect installer OCI image, tagged with the release you want. See Edera release notes for current versions.
dockerconfigjsonThe contents of a Docker config file authenticated against Edera’s registry. The chart uses this to create a kubernetes.io/dockerconfigjson Secret and reference it as an imagePullSecrets entry, so nodes can pull the installer image.

Step 1: Get your Docker authentication

Log in to the registry with the GAR key to produce a Docker config file:

docker login us-central1-docker.pkg.dev -u _json_key --password-stdin < key.json

This writes credentials to ~/.docker/config.json. You’ll pass that file to the chart in the next step.

Step 2: Install the chart

Set TAG to the release version you want to install. See Edera release notes for current versions.

helm install edera-protect oci://ghcr.io/edera-dev/charts/edera-installer \
  --namespace edera-system --create-namespace \
  --set image=us-central1-docker.pkg.dev/edera-protect/staging/protect-installer:${TAG} \
  --set-file dockerconfigjson=$HOME/.docker/config.json

The chart deploys the installer as a DaemonSet scoped to your compatible node pool. Give it a minute to roll out, then confirm the Protect daemon is running:

kubectl -n edera-system get pods -o wide

Step 3: Apply the Edera RuntimeClass 

kubectl apply -f https://public.edera.dev/kubernetes/runtime-class.yaml
kubectl get runtimeclass

Expected output:

NAME    HANDLER   AGE
edera   edera     1m

Step 4: Label nodes and test

The Edera RuntimeClass requires nodes to be labeled runtime=edera:

kubectl label nodes <node-name> runtime=edera
Managed Kubernetes services allow you to pre-label your Kubernetes nodes directly from the node pool configuration.

Then run a test Pod against it:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: edera-test
spec:
  runtimeClassName: edera
  containers:
  - name: nginx
    image: nginx:1.25.3
EOF
kubectl wait --for=condition=ready pod/edera-test --timeout=300s

Compatibility by cloud provider

Node support varies significantly by provider. What counts as “bare metal” or “nested virtualization” differs, and each provider draws the managed/unmanaged line in a different place. Check your provider below before you provision a node pool.

Amazon Elastic Kubernetes Service (EKS)

ℹ️
Helm chart or AMI? This section covers installing onto an existing EKS cluster with the Helm chart. Edera also publishes EKS-optimized AMIs that bake Protect into the node image at boot. See Installing Edera with AWS EKS. Both paths get you to the same result; pick the Helm chart if you’re managing node images yourself, or the AMI if you’d rather not.
Unsupported setupsManaged node groups, including EKS Auto Mode do not allow any external customizations. Note however that EKS supports clusters with a mixture of managed and self-managed (BYO) node groups.
Metal instancesBroad support across almost every EC2 instance category.
Nested virtualization instancesc8i, m8i, r8i, c8id, r8id, m8id, c8i-flex, r8i-flex, m8i-flex, x8i, c7i, r7i, m7i, c7i-flex, m7i-flex, i7i. See nested virtualization in EC2.
Supported node imagesAL2023 and Ubuntu AMIs

Google Kubernetes Engine (GKE)

Unsupported setupsGKE Autopilot clusters do not allow any external customizations. They also lack support for nested virtualization, and do not offer a way to add self-managed (BYO) node pools.
Metal instancesc4-*-384-metal, c4a-*-288-metal, c4a-*-288-lssd-metal, c4d-*-384-metal, c3-*-192-metal, x4-*-metal, z3-highmem-192-highlssd-metal, a4x-maxgpu-4g-metal. See bare metal instances.
Nested virtualization instancesAll machine types except e2-*, h4d-*, m* (memory-optimized), and any type with an AMD or ARM CPU. See nested virtualization.
Supported node imagesubuntu-containerd

Microsoft Azure Kubernetes Service (AKS)

Unsupported setupsAKS Automatic clusters do not allow any external customization. They also lack support for nested virtualization, and do not offer a way to add self-managed (BYO) node pools.
Metal instancesNot supported. Azure’s BareMetal Infrastructure is provided through Nutanix, a third party, and only supports the Nutanix AHV hypervisor.
Nested virtualization instancesAny Intel based VM is theoretically capable of running Edera. Microsoft’s own support statement for nested virtualization covers Hyper-V as the outer hypervisor specifically, but in Edera’s own testing, Protect installs and runs cleanly on standard Azure VMs regardless. If you hit a case that doesn’t work, let us know.

What’s next

Last updated on