Zarf is meant to be able to take k8s resources (whether they be charts, images, manifests, kustomizations, etc...), package them up into a single tarball, then be able to bring that tarball across the airgap and deploy.
Zarf is also meant to be a standalone single binary solution to a lot of other common problems in the k8s airgapped deployment sphere (which is why k9s and some other common utils are embedded under `zarf tools`).
The logging stack is part of the default "init" package, which is a special package that bootstraps ANY k8s cluster to point references (images, git repos, oci artifacts) to internally deployed registries (distribution/distribution, and Gitea).
Git repos exist as a citizen to enable gitops based deployments (flux, argocd).
OK, now I see, it does make sense. So it's more like a base functionality of bundling tarballs with software and dependencies PLUS a set of tooling for CI/CD preconfigured to work in such isolated env.
I actually like it a lot, would use it at work if I knew about that before. Not for fully airgapped envs but rather semi-isolated, where at least Internet access should not come as granted.
Zarf is also meant to be a standalone single binary solution to a lot of other common problems in the k8s airgapped deployment sphere (which is why k9s and some other common utils are embedded under `zarf tools`).
The logging stack is part of the default "init" package, which is a special package that bootstraps ANY k8s cluster to point references (images, git repos, oci artifacts) to internally deployed registries (distribution/distribution, and Gitea).
Git repos exist as a citizen to enable gitops based deployments (flux, argocd).