Introduction
Helm permet de packager des modèles Kubernetes sous forme de releases. Kustomize adopte une approche différente : il part de fichiers YAML Kubernetes ordinaires et y superpose des modifications sans utiliser d'expressions de template. Cette méthode est particulièrement utile lorsque vous souhaitez disposer d'une base commune tout en gérant de légères différences selon l'environnement, telles que les noms, les espaces de noms (namespaces), le nombre de réplicas ou des correctifs spécifiques.
Dans ce laboratoire, vous allez créer un déploiement et un service de base, générer le rendu de cette base avec Kustomize, puis créer une surcouche de production qui modifiera le nom, l'espace de noms, le nombre de réplicas et le message de l'application. Enfin, vous déploierez cette surcouche avec kubectl apply -k et testerez le service résultant.
Préparer un espace de travail Kustomize
Dans cette étape, vous allez préparer un espace de noms et confirmer que la prise en charge de Kustomize est disponible via kubectl.
Commencez dans /home/labex/project. Ce laboratoire conserve les manifestes de base et les fichiers de surcouche dans cet espace de travail.
mkdir -p /home/labex/project
cd /home/labex/project
Vérifiez que le serveur d'API Kubernetes est accessible. Si la machine virtuelle vient de démarrer et que le nœud n'est pas encore prêt, attendez quelques secondes et relancez la commande.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Attendez que le Pod réseau du cluster soit prêt. Vous testerez un service à la fin du laboratoire, il est donc nécessaire que le réseau du cluster soit opérationnel.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Sortie attendue :
pod/calico-node-... condition met
Créez un espace de noms nommé ckad-prep-kustomize et définissez-le comme espace de noms par défaut :
kubectl create namespace ckad-prep-kustomize
kubectl config set-context --current --namespace=ckad-prep-kustomize
Confirmez l'espace de noms et vérifiez que kubectl kustomize est disponible. kubectl kustomize génère le rendu des répertoires Kustomize sans les appliquer.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
kubectl kustomize --help | sed -n '1,3p'
La sortie attendue inclut :
ckad-prep-kustomize
Build a set of KRM resources...
Créer une base réutilisable
Dans cette étape, vous allez créer une base Kustomize à partir de fichiers YAML Kubernetes ordinaires.
Une base constitue le point de départ partagé. Elle doit contenir des objets Kubernetes complets et valides avant toute personnalisation spécifique à l'environnement. Ici, la base contient un déploiement et un service. L'application écrit la valeur de la variable d'environnement MESSAGE dans une petite page web.
Créez le répertoire de base :
mkdir -p kustomize-demo/base
Créez le déploiement de base :
cat > kustomize-demo/base/deployment.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: kustomize-web
labels:
app: kustomize-web
spec:
replicas: 1
selector:
matchLabels:
app: kustomize-web
template:
metadata:
labels:
app: kustomize-web
spec:
terminationGracePeriodSeconds: 0
containers:
- name: web
image: busybox:1.36
env:
- name: MESSAGE
value: base-v1
command:
- /bin/sh
- -c
- |
mkdir -p /www
echo "$MESSAGE" > /www/index.html
httpd -f -p 8080 -h /www
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 1
periodSeconds: 2
EOF
Créez le service de base. Son sélecteur correspond au label du Pod défini dans le déploiement.
cat > kustomize-demo/base/service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: kustomize-web
spec:
selector:
app: kustomize-web
ports:
- port: 80
targetPort: 8080
EOF
Créez le fichier kustomization.yaml de base. Ce fichier indique à Kustomize quelles ressources appartiennent à la base.
cat > kustomize-demo/base/kustomization.yaml <<'EOF'
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
EOF
Générez le rendu de la base sans l'appliquer :
kubectl kustomize kustomize-demo/base | sed -n '1,120p'
La sortie attendue inclut un service nommé kustomize-web, un déploiement nommé kustomize-web, replicas: 1 et value: base-v1.
Ajouter une surcouche de production
Dans cette étape, vous allez créer une surcouche (overlay) qui personnalise la base pour un déploiement de type production.
Une surcouche pointe vers une base et y ajoute des modifications. Cette surcouche placera les objets dans ckad-prep-kustomize, ajoutera le préfixe prod- au nom, mettra à l'échelle le déploiement à trois réplicas et modifiera la valeur de MESSAGE en prod-v2.
Créez le répertoire de la surcouche :
mkdir -p kustomize-demo/overlays/prod
Créez un correctif (patch) pour le déploiement. Le correctif nomme l'objet de base original, kustomize-web. Kustomize fait correspondre le correctif avant d'ajouter le préfixe prod-.
cat > kustomize-demo/overlays/prod/deployment-patch.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: kustomize-web
spec:
replicas: 3
template:
spec:
containers:
- name: web
env:
- name: MESSAGE
value: prod-v2
EOF
Créez le fichier kustomization.yaml de la surcouche. L'entrée resources pointe vers la base, tandis que namespace, namePrefix et patches décrivent la personnalisation.
cat > kustomize-demo/overlays/prod/kustomization.yaml <<'EOF'
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: ckad-prep-kustomize
namePrefix: prod-
resources:
- ../../base
patches:
- path: deployment-patch.yaml
EOF
Générez le rendu de la surcouche de production :
kubectl kustomize kustomize-demo/overlays/prod | sed -n '1,160p'
La sortie attendue inclut :
name: prod-kustomize-web
namespace: ckad-prep-kustomize
replicas: 3
value: prod-v2
Déployer et tester l'application personnalisée
Dans cette étape, vous allez appliquer la surcouche de production et tester le service qu'elle crée.
La commande kubectl apply -k génère le rendu d'un répertoire Kustomize et envoie les objets générés au serveur d'API Kubernetes. Vous n'avez pas besoin de créer un fichier YAML temporaire.
Appliquez la surcouche de production :
kubectl apply -k kustomize-demo/overlays/prod
La sortie attendue inclut :
service/prod-kustomize-web created
deployment.apps/prod-kustomize-web created
Attendez que le déploiement personnalisé soit prêt :
kubectl rollout status deployment/prod-kustomize-web --timeout=120s
Sortie attendue :
deployment "prod-kustomize-web" successfully rolled out
Inspectez les objets créés à partir de la surcouche :
kubectl get deployment,service prod-kustomize-web
La sortie attendue inclut :
deployment.apps/prod-kustomize-web 3/3
service/prod-kustomize-web
Créez un Pod client et testez le service. La réponse devrait être prod-v2, ce qui prouve que le correctif de la surcouche a bien modifié la configuration de l'application en cours d'exécution.
kubectl run kustomize-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
kubectl wait --for=condition=Ready pod/kustomize-client --timeout=120s
kubectl exec kustomize-client -- wget -qO- http://prod-kustomize-web
Sortie attendue :
prod-v2
Résumé
Vous avez construit une base Kustomize à partir de fichiers YAML de déploiement et de service ordinaires, puis créé une surcouche de production qui a modifié l'espace de noms, les noms des objets, le nombre de réplicas et le message de l'application. Vous avez généré le rendu de la base et de la surcouche avant d'appliquer cette dernière avec kubectl apply -k, puis vérifié l'application personnalisée via son service.
