Introduction
Les API Kubernetes évoluent. Un manifeste qui fonctionnait sur un cluster plus ancien peut échouer sur un cluster récent, soit parce qu'une version d'API a été supprimée, soit parce que les champs ont été restructurés. Dans le cadre de la certification CKAD, cela se traduit généralement par une tâche de maintenance concrète : lire l'erreur, identifier l'API actuelle, mettre à jour le manifeste et vérifier que la nouvelle version est acceptée.
Dans ce laboratoire, vous allez migrer un ancien manifeste Ingress de networking.k8s.io/v1beta1 vers networking.k8s.io/v1. Vous créerez d'abord un Service auquel l'Ingress pourra faire référence, puis vous observerez l'échec de l'ancien manifeste, utiliserez les commandes de découverte kubectl pour inspecter l'API actuelle, réécrirez le manifeste et appliquerez l'Ingress corrigé.
Préparer une référence de Service
Dans cette étape, vous allez préparer un espace de noms (namespace) propre et un Service simple. Les anciens et nouveaux manifestes Ingress pointeront tous deux vers ce Service, afin que la migration se concentre sur la structure de l'API plutôt que sur la disponibilité des Pods ou le routage du trafic.
Commencez dans /home/labex/project :
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...
Créez un espace de noms nommé ckad-prep-api-migration et définissez-le comme espace de noms actuel :
kubectl create namespace ckad-prep-api-migration
kubectl config set-context --current --namespace=ckad-prep-api-migration
Créez un Service de type ClusterIP nommé app-web. L'option --tcp=80:80 signifie que le Service écoute sur le port 80 et redirigerait vers le port cible 80 si des Pods correspondants existaient. Pour ce laboratoire de migration, l'objet Service lui-même suffit car vous validez les champs de l'API Ingress, et non le trafic HTTP.
kubectl create service clusterip app-web --tcp=80:80
Confirmez que le Service existe :
kubectl get service app-web
La sortie attendue inclut :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
app-web ClusterIP ... <none> 80/TCP ...
Observer l'échec d'un manifeste obsolète
Dans cette étape, vous allez créer un ancien manifeste Ingress et laisser le cluster actuel le rejeter. C'est un exercice utile, car le premier indice dans une tâche de migration est souvent le message d'erreur du serveur d'API.
Créez old-ingress.yaml :
cat > old-ingress.yaml <<'EOF'
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: app-web
spec:
rules:
- host: app.example.local
http:
paths:
- path: /
backend:
serviceName: app-web
servicePort: 80
EOF
Lisez le début du fichier. Le champ apiVersion indique à Kubernetes quel groupe d'API et quelle version doivent traiter cet objet.
sed -n '1,20p' old-ingress.yaml
La sortie attendue inclut :
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
...
serviceName: app-web
servicePort: 80
Demandez au serveur d'API de valider le manifeste sans le créer. --dry-run=server envoie l'objet au serveur d'API pour validation, tandis que || true permet au tutoriel de continuer car cet échec est attendu.
kubectl apply --dry-run=server -f old-ingress.yaml || true
La sortie attendue inclut une erreur similaire à :
error: resource mapping not found for name: "app-web" namespace: "" from "old-ingress.yaml": no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"
L'élément important est no matches for kind "Ingress" in version "networking.k8s.io/v1beta1". Cela signifie que le cluster actuel ne prend plus en charge cette version d'API.
Découvrir la structure actuelle de l'API Ingress
Dans cette étape, vous allez inspecter l'API Ingress actuelle avant de réécrire le fichier. C'est ce qui permet de garder une approche rigoureuse : ne devinez pas les nouveaux champs quand le cluster peut vous montrer la structure acceptée.
Listez la ressource Ingress disponible :
kubectl api-resources | grep -i '^ingresses'
La sortie attendue inclut :
ingresses ing networking.k8s.io/v1 true Ingress
Utilisez kubectl explain pour inspecter le champ du service backend actuel. Le chemin est long car le backend du Service est imbriqué sous spec.rules[].http.paths[].backend.service.
kubectl explain ingress.spec.rules.http.paths.backend.service --recursive | sed -n '1,80p'
La sortie attendue inclut :
GROUP: networking.k8s.io
KIND: Ingress
VERSION: v1
FIELD: service <IngressServiceBackend>
...
name <string> -required-
port <ServiceBackendPort> -required-
Créez maintenant le fichier current-ingress.yaml migré. Le nouveau manifeste utilise networking.k8s.io/v1, ajoute pathType, et remplace serviceName et servicePort par les champs imbriqués service.name et service.port.number.
cat > current-ingress.yaml <<'EOF'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-web
spec:
rules:
- host: app.example.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-web
port:
number: 80
EOF
Validez le manifeste migré avec un test à sec côté serveur :
kubectl apply --dry-run=server -f current-ingress.yaml
Sortie attendue :
ingress.networking.k8s.io/app-web created (server dry run)
Appliquer et inspecter l'Ingress migré
Dans cette étape, vous allez créer l'Ingress migré et inspecter les champs stockés par Kubernetes. L'application de la ressource est la preuve finale que le manifeste correspond désormais au serveur d'API actuel.
Appliquez le manifeste migré :
kubectl apply -f current-ingress.yaml
Sortie attendue :
ingress.networking.k8s.io/app-web created
Listez l'Ingress :
kubectl get ingress app-web
La sortie attendue inclut :
NAME CLASS HOSTS ADDRESS PORTS AGE
app-web ... app.example.local ... 80 ...
Inspectez directement les champs du backend migré à partir de l'objet stocké :
kubectl get ingress app-web -o jsonpath='{.apiVersion}{" "}{.spec.rules[0].http.paths[0].pathType}{" "}{.spec.rules[0].http.paths[0].backend.service.name}{":"}{.spec.rules[0].http.paths[0].backend.service.port.number}{"\n"}'
Sortie attendue :
networking.k8s.io/v1 Prefix app-web:80
Ce résultat prouve trois choses : l'objet utilise la version d'API actuelle, le chemin possède un pathType explicite, et le backend utilise la référence de Service imbriquée requise par networking.k8s.io/v1.
Résumé
Vous avez pratiqué un flux de travail concret de migration d'API. Vous avez créé un ancien manifeste Ingress networking.k8s.io/v1beta1, utilisé un test à sec côté serveur pour confirmer que le cluster actuel le rejetait, inspecté l'API networking.k8s.io/v1 disponible, réécrit les champs du backend avec pathType et la référence de Service imbriquée, puis appliqué et inspecté l'Ingress migré.
