Install on EKS

Infrared installs on EKS the way it installs on GKE: one values file, one helm install from the public chart, then the setup wizard. This page covers what is different on AWS. Infrared reaches AWS through IAM roles, never a long-lived key: for the AWS Load Balancer Controller, and to reach the cloud accounts your orgs add.

Install it with us

Infrared's EKS cluster template, aws/eks-cluster, is built from nothing, connected, used and deleted every day as a workload cluster. Running Infrared's management cluster on EKS has had less use than on GKE, so book a call and we install it with you.

Before you start

• An EKS cluster with kubectl able to reach it. Build it from aws/eks-cluster in infrared-iac-modules, which we share with you when you start. It makes:

  • a VPC across az_count zones with one NAT gateway, and subnets tagged for the AWS Load Balancer Controller;
  • a public API endpoint open only to endpoint_public_access_cidrs, with cluster admins through EKS access entries (admin_principal_arns);
  • one managed node group, on-demand or Spot. For a management cluster, use at least 3 nodes of 4 vCPU and 16 GiB, such as m6i.xlarge;
  • the EKS Pod Identity Agent, the EBS CSI driver, and a Pod Identity role for the AWS Load Balancer Controller on kube-system/aws-load-balancer-controller;
  • optionally, a permissions boundary on every role it creates (permissions_boundary_arn).

  A cluster of your own works too, with the Pod Identity Agent (or IRSA) and the controller's role.

• helm 3.8 or later and kubectl. Infrared's chart and images are public, so there is nothing to sign in to.

• A domain on Cloudflare and an API token for it, for Infrared's edge. As on GKE, the edge is one Envoy on every node's ports 80 and 443 behind Cloudflare's proxy, so the nodes that run it need addresses Cloudflare can reach. The template's node group is in private subnets, so we set the edge up with you.

• IAM roles for Infrared, through IRSA:

  Role for	Chart value	Needs
  Reaching your orgs' cloud accounts	cloudIdentity.aws.roleARN	Only sts:AssumeRole. Each org's role trusts it

• No license yet. Infrared 0.1 runs with no license through November 30, 2026 (UTC). See Licensing.

1. Write your values file

# infrared-values.yaml
infrared-core:
  managementCluster:
    name: acme-cp          # the EKS cluster's own name
  cloud: aws
  image:
    registry: us-central1-docker.pkg.dev/darkshift-public/infrared
  gitops:
    chartRepository: us-central1-docker.pkg.dev/darkshift-public/infrared/charts
  installation:
    edge: gateway
    previews:
      domain: apps.example.com
      signInURL: https://infrared.example.com
  cloudIdentity:
    aws:
      roleARN: arn:aws:iam::<account>:role/infrared-cloud

Every value is in Chart values.

2. Install

helm install infrared oci://us-central1-docker.pkg.dev/darkshift-public/infrared/charts/infrared \
  --version 0.1.0 \
  --kube-context <your EKS context> \
  --namespace infrared --create-namespace \
  --values infrared-values.yaml \
  --set-file infrared-core.platformTokens.cloudflareApiToken=$HOME/.secrets/cloudflare-token

Infrared detects the cluster as flavor eks on provider aws. The flavor decides what your gitops repo gets: on EKS, sync wave 10 adds the AWS Load Balancer Controller, for the load balancers your Products' Services ask for. Then run the setup wizard as on GKE: see Run the setup wizard, then After setup.

Differences from GKE

	GKE	EKS
Flavor detected	none (provider gcp)	eks (provider aws)
Load balancers	None for Infrared's edge	The AWS Load Balancer Controller, sync wave 10, for Services that ask for one
Image pulls	Infrared's public registry, no sign-in	Infrared's public registry, no sign-in
Infrared's cloud identity	A Google service account	An IAM role
managementCluster.name	Any name	The EKS cluster's name
Backups	Cloud Storage, with no key	Amazon S3 or another S3-compatible store, with an access key

If the load balancer controller uses IRSA instead of Pod Identity, its service account needs the annotation eks.amazonaws.com/role-arn. The gitops template leaves its annotations empty: after setup, add it in registry/clusters/<cluster>/components/aws-load-balancer-controller.yaml in your gitops repo, and check it is still there after each template upgrade.