This folder contains packages maintained by the Zarf team. Some of these packages are used by zarf init for new cluster initialization.

The distros package adds optional capabilities for spinning up and tearing down clusters. Currently, the following distros are supported:

• EKS - Zarf deploys and tears down using the eksctl binary under the hood. See how it's done in the EKS package's zarf.yaml and checkout the EKS package's config for more information.

• k3s - Zarf deploys and tears down using the k3s service under the hood. See how it's done in the k3s package's zarf.yaml.

Note - requires eksctl credentials.

zarf package create packages/distros/eks -o build --confirm

zarf package deploy build/zarf-package-distro-eks-amd64-x.x.x.tar.zst --components=deploy-eks-cluster --set=CLUSTER_NAME='zarf-nightly-eks-e2e-test',INSTANCE_TYPE='t3.medium' --confirm

See the nightly-eks test for another example.

Note - requires systemd and root access only (no sudo) on a linux machine.

zarf init --components=k3s

Users who rely heavily on GitOps find it useful to deploy an internal Git repository. Zarf uses Gitea to provide this functionality. The Gitea package deploys a Gitea instance to the cluster and configures it to use the credentials in the private-git-server secret in the Zarf namespace.

zarf init --components=git-server

The Zarf Agent is a mutating admission controller used to modify the image property within a PodSpec. The purpose is to redirect it to Zarf's configured registry instead of the the original registry (such as DockerHub, GHCR, or Quay). Additionally, the webhook attaches the appropriate ImagePullSecret for the seed registry to the pod. This configuration allows the pod to successfully retrieve the image from the seed registry, even when operating in an air-gapped environment.

$ zarf tools kubectl get deploy -n zarf agent-hook

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
agent-hook   2/2     2            2           17m

The Zarf internal registry is utilized to store container images for use in air-gapped environments. The registry is deployed as a Deployment with a single replica and a PersistentVolumeClaim to store the images. Credentials for basic authentication are autogenerated and stored within a secret in the zarf namespace. The internal registry is HTTP only.