Skip to content

Choosing Flavors

A Garden Linux flavor is a pre-composed combination of a platform target (e.g. aws, baremetal) and one or more features (e.g. gardener, _prod, _fips). The flavor name encodes both: <platform>-<feature1>_<feature2> (e.g. aws-gardener_prod).

This guide walks you through selecting the right flavor in four steps. For background on how flavors work, see Flavors. For the complete list of all published flavors, see the Flavor Matrix.

Step 1: Identify Your Use Case

Determine which of the primary Garden Linux use cases matches your workload. Each use case maps to a specific feature set.

Use CaseKey FeaturesGo To
Gardener-managed Kubernetes nodesgardener, _prodGardener Kubernetes Nodes
Bare-metal Gardener nodes via IronCore (Cluster API)capiBare-Metal via IronCore
Vanilla (non-Gardener) Kubernetes nodeskhostVanilla Kubernetes Nodes
OCI container base imagecontainer or bare-*Container Base Images
KVM/libvirt virtualization hostvhostVirtualization Host

If no existing use case matches, you can compose a custom flavor. See Building Images for instructions.

Step 2: Determine Your Target Platform

The platform identifies the hardware or cloud environment where the image runs. Choose the platform that corresponds to your infrastructure.

PlatformCategoryDescription
awsPublic cloudAmazon Web Services EC2
azurePublic cloudMicrosoft Azure Virtual Machines
gcpPublic cloudGoogle Cloud Platform Compute Engine
openstackPrivate cloudOpenStack-based private cloud or hosted OpenStack
vmwareHypervisorVMware vSphere / ESXi
kvmHypervisorKVM/QEMU-based virtualization
baremetalBare-metalPhysical servers, PXE boot, IronCore
containerContainerFull OCI base images (Docker, Podman, containerd)
limaLocal devLima-based local development on Linux and macOS

One platform per flavor

Each flavor must target exactly one platform. The build system enforces this by default — specifying zero or multiple platforms causes the build to fail. See ADR 0020 for the rationale and opt-in override.

For the full list of platform targets and their YAML schema, see Flavors Reference.

Step 3: Select Features

Features extend the base platform with additional capabilities. The most common features are listed below.

FeatureDescription
gardenerInstalls containerd for Gardener-managed Kubernetes; systemd unit disabled at build time and enabled by Gardener at runtime
_prodProduction hardening: disables debug tooling and applies security defaults
khostInstalls containerd for vanilla (non-Gardener) Kubernetes
vhostInstalls KVM kernel modules and libvirt for use as a hypervisor host
capiCluster API support for bare-metal provisioning via IronCore
_fipsFIPS 140-2 compliant cryptography
_usiBoot using a UKI with embedded EROFS root disk
_trustedbootTrusted Boot: validates the entire boot chain including the rootfs (requires _tpm2 for persistent storage)
_tpm2TPM 2.0 sealed disk encryption for /var, bound to the Secure Boot certificate chain (see Boot Modes: Mutable Data)

Step 4: Look Up the Flavor Name

Once you have a platform and feature set, look up the exact flavor name and confirm it is published.

  • Common flavors by use case: The Use Cases page includes a "Recommended Flavors" table under each use case section.
  • Complete flavor list: The Flavor Matrix lists every flavor built from flavors.yaml, with their resolved feature dependencies, architectures, and publication status.

How features are joined into a flavor name

Garden Linux uses the CNAME system to construct canonical flavor names.

Example: Choosing a Gardener Flavor on AWS

The following walkthrough illustrates all four steps for a common scenario.

  1. Use case: Gardener-managed Kubernetes worker nodes.
  2. Platform: aws.
  3. Features: gardener (required for Gardener integration) and _prod (production hardening).
  4. Flavor name: aws-gardener_prod

To obtain the image for this flavor, see Getting Images.

TIP

The Flavor Matrix gives you an overview of pre-built flavors and the exact recursive features they contain.