Carvel : la boîte à outils Kubernetes (ytt, kapp, imgpkg)

Carvel est une suite d'outils Kubernetes à usage unique et composables : ytt template le YAML, kapp déploie un groupe de ressources comme une seule application, imgpkg les empaquette en bundle OCI. Ce guide montre ytt et kapp en pratique (sorties d'un lab réel sur k3d), puis situe imgpkg, kbld, vendir et kapp-controller. Pour utilisateurs Kubernetes intermédiaires. Carvel est un projet CNCF Sandbox, né chez VMware ; toute la suite est active en 2026 (versions de mai-juin 2026).

Ce que vous allez apprendre

Templater et patcher du YAML avec ytt
Déployer et suivre un groupe de ressources avec kapp
Enchaîner ytt et kapp
Situer imgpkg, kbld, vendir, kapp-controller et Carvel face à Helm

Prérequis

Un cluster Kubernetes de test (k3d est parfait) et kubectl
Notions de manifests Kubernetes (Deployment, Service)

La philosophie Carvel

Là où Helm regroupe tout dans un outil unique, Carvel suit l'approche UNIX : des outils à usage unique que vous composez. Chacun fait une chose et se branche sur les autres.

Outil	Rôle	Version (juin 2026)
ytt	templater et patcher du YAML (structures, pas du texte)	0.55.1
kapp	déployer un groupe de ressources comme une « app »	0.65.3
imgpkg	empaqueter config + images en bundle OCI	0.48.1
kbld	résoudre les images en digests immuables	0.49.1
vendir	vendoriser des configs depuis git, http, OCI	0.46.0
kapp-controller	opérateur GitOps (packaging dans le cluster)	0.60.3

Aucun n'impose les autres : vous pouvez n'utiliser que ytt, ou enchaîner ytt | kbld | kapp.

Installer Carvel

Le script officiel installe tous les binaires (vérification des sommes SHA-256 incluse) :

curl -L https://carvel.dev/install.sh | bash

Pour un seul outil, récupérez le binaire de la release GitHub :

curl -Lo ytt https://github.com/carvel-dev/ytt/releases/download/v0.55.1/ytt-linux-amd64
sudo mv ytt /usr/local/bin/ytt && sudo chmod +x /usr/local/bin/ytt
ytt version

ytt version 0.55.1

ytt : templater du YAML structuré

ytt ne fait pas du templating de texte (comme les Go templates de Helm) mais manipule des structures YAML, ce qui évite les pièges d'indentation et d'échappement. Les valeurs viennent d'un fichier #@data/values, le template les consomme avec #@ data.values.<clé>.

config.yml (le template, avec une fonction) :

#@ load("@ytt:data", "data")

#@ def name(app):
#@   return app + "-service"
#@ end

apiVersion: v1
kind: Service
metadata:
  name: #@ name(data.values.name)
spec:
  selector:
    app: #@ data.values.name
  ports:
    - port: #@ data.values.port

values.yml (les valeurs, séparées du template) :

#@data/values
---
name: frontend
port: 80

Le rendu combine les deux fichiers :

ytt -f config.yml -f values.yml

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend
  ports:
  - port: 80

La logique (la fonction name, les valeurs) est séparée du résultat. C'est plus lisible qu'une chaîne de caractères templatée.

ytt : patcher avec un overlay

L'overlay est la force de ytt : modifier une ressource sans toucher au fichier source, en ciblant précisément ce qu'on veut changer. Ici, on ajoute un label à tous les Service :

#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind": "Service"})
---
metadata:
  #@overlay/match missing_ok=True
  labels:
    managed-by: carvel

ytt -f config.yml -f values.yml -f overlay.yml

metadata:
  name: frontend-service
  labels:
    managed-by: carvel

overlay.subset({"kind": "Service"}) cible la ressource, missing_ok=True crée le bloc labels s'il n'existe pas. C'est l'équivalent structuré (et plus puissant) des patches de Kustomize.

kapp : déployer un groupe de ressources comme une app

kapp remplace kubectl apply avec deux apports majeurs : il regroupe les ressources sous un nom d'application, et il montre un diff avant d'agir, puis attend la convergence. Déployons un Deployment et son Service (fichier app.yml) :

kapp deploy -a demo -f app.yml -y

Changes
Namespace  Name  Kind        Op      Wait to
default    web   Deployment  create  reconcile
^          web   Service     create  reconcile
Op:      2 create, 0 delete, 0 update, 0 noop, 0 exists

create service/web (v1) namespace: default
create deployment/web (apps/v1) namespace: default
ok: reconcile service/web (v1) namespace: default
ongoing: reconcile deployment/web (apps/v1) namespace: default
 L ok: waiting on replicaset/web-6bd47565d
 L ongoing: waiting on pod/web-6bd47565d-5jtsk

kapp attend que le déploiement converge (pods prêts) avant de rendre la main, là où kubectl apply rend la main immédiatement. L'application apparaît dans la liste :

kapp list

Name  Namespace  ...
demo  default    ...

kapp : inspecter et supprimer

kapp inspect montre toutes les ressources rattachées à l'app, y compris celles créées en cascade (ReplicaSet, Pod, Endpoints) :

kapp inspect -a demo

default  web                  Deployment     kapp     ok
default  web                  Service        kapp     ok
default  web-6bd47565d        ReplicaSet     cluster  ok
default  web-6bd47565d-5jtsk  Pod            cluster  ok
default  web                  Endpoints      cluster  ok

La suppression retire tout le groupe d'un coup, dans le bon ordre, et attend la fin :

kapp delete -a demo -y

---- applying complete [6/6 done] ----
---- waiting complete [6/6 done] ----
Succeeded

Plus besoin de traquer chaque ressource : l'app est l'unité de gestion.

Enchaîner ytt et kapp

La vraie puissance de Carvel vient de la composition. kapp lit sur l'entrée standard (-f -), donc on chaîne le rendu ytt directement au déploiement :

ytt -f config.yml -f values.yml | kapp deploy -a svc-only -f - -y

create service/frontend-service (v1) namespace: default
Op:      1 create, 0 delete, 0 update, 0 noop, 0 exists

Le pipeline complet en production est souvent ytt | kbld | kapp : ytt rend le YAML, kbld remplace les tags d'images par leurs digests immuables, kapp déploie. Chaque maillon reste indépendant.

Les autres outils de la suite

imgpkg empaquette une configuration et ses images comme un bundle OCI unique (un artefact à digest SHA256), poussé dans un registre : imgpkg push -b registry/bundle:v1 -f config/. Idéal pour l'air-gapped (copie registre à registre) et la reproductibilité via un lock file.
kbld résout les références d'images en digests immuables, pour des déploiements reproductibles.
vendir vendorise des fichiers depuis des sources déclarées (git, http, OCI, chart Helm) : utile pour figer des dépendances de configuration.
kapp-controller est l'opérateur GitOps de Carvel. Installé dans le cluster, il récupère la config (git, OCI, Helm), la template (ytt, kbld) et la déploie (kapp), piloté par des ressources App, Package et PackageInstall. C'est le composant le plus actif de la suite.

kubectl apply -f https://github.com/carvel-dev/kapp-controller/releases/download/v0.60.3/release.yml

Attention, les notes amont écrivent parfois kubectl deploy (commande inexistante) : utilisez bien kubectl apply -f, ou kapp deploy -a kc -f <url>.

Carvel face à Helm et Kustomize

Carvel ne remplace pas l'un par l'autre : il découpe ce que Helm fait en bloc.

Besoin	Helm	Carvel
Templating	Go templates (texte)	ytt (structures YAML)
Patch / overlay	options exposées par le chart	ytt overlay (ciblé)
Déploiement	`helm install` (CRD release)	kapp (diff + convergence, sans CRD)
Empaquetage	chart (tgz)	imgpkg (bundle OCI)
GitOps	Argo CD / Flux	kapp-controller

ytt brille quand le templating texte de Helm devient illisible (comptage d'espaces, échappements). kapp apporte un diff explicite et l'attente de convergence que kubectl apply n'a pas. Côté Kustomize, ytt va plus loin : conditions, boucles et fonctions, au-delà du patch déclaratif.

À garder en tête : Carvel est un projet CNCF Sandbox (premier palier de maturité), toutes ses versions sont < 1.0, et son adoption reste plus modeste que Helm ou Argo CD. C'est un choix d'équipe convaincue, pas un standard de marché.

À retenir

Carvel = des outils composables : ytt (template), kapp (deploy), imgpkg (bundle), kbld, vendir, kapp-controller.
ytt template des structures YAML (pas du texte) et patche par overlay, sans toucher la source.
kapp déploie un groupe de ressources comme une « app », avec diff et attente de convergence.
kapp inspect voit toutes les ressources dérivées ; kapp delete retire le groupe entier.
On enchaîne les outils : ytt | kbld | kapp deploy -f -.
Projet CNCF Sandbox vivant (versions juin 2026), mais maturité < 1.0 et adoption plus modeste que Helm.

Prochaines étapes

Helm Le gestionnaire de paquets Kubernetes le plus répandu

k9s Explorer son cluster dans le terminal

Démarrer avec k3s / k3d Un cluster de test léger pour pratiquer

Kubernetes Revenir au parcours Kubernetes