Introduction
Kubernetes peut être étendu avec de nouveaux types de ressources. Une CustomResourceDefinition, généralement appelée CRD, enregistre une nouvelle ressource API auprès du serveur d'API Kubernetes. Une fois cela fait, vous pouvez utiliser les commandes kubectl habituelles pour créer, récupérer, décrire, étiqueter (label) et modifier (patch) des objets de ce nouveau type.
Dans ce laboratoire, vous allez créer une petite CRD nommée AppProfile dans un namespace, la découvrir à l'aide des commandes de découverte de l'API Kubernetes, créer des ressources personnalisées à partir de fichiers YAML et les mettre à jour comme des objets Kubernetes classiques. Aucun contrôleur n'est nécessaire pour ce laboratoire ; l'objectif est de comprendre comment les types de ressources personnalisées apparaissent et comment manipuler leurs objets.
Préparer un namespace pour les ressources personnalisées
Dans cette étape, vous allez préparer un namespace propre pour vous entraîner aux ressources personnalisées.
Commencez dans /home/labex/project. Vous rédigerez les manifestes de la CRD et de la ressource personnalisée dans ce répertoire.
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 avant de créer des objets applicatifs.
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 namespace nommé ckad-prep-customresources :
kubectl create namespace ckad-prep-customresources
Définissez ce namespace comme namespace par défaut pour le contexte actuel :
kubectl config set-context --current --namespace=ckad-prep-customresources
Confirmez le namespace actuel :
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Sortie attendue :
ckad-prep-customresources
Enregistrer un nouveau type de ressource avec une CRD
Dans cette étape, vous allez créer une CustomResourceDefinition nommée AppProfile.
Une CRD possède deux niveaux de nommage importants. Le metadata.name est le nom pluriel de la ressource suivi du groupe API, par exemple appprofiles.training.labex.io. La section spec.names définit comment les utilisateurs feront référence à la ressource : kind: AppProfile, plural: appprofiles, singular: appprofile, et un nom court appprof.
Créez app-profile-crd.yaml :
cat > app-profile-crd.yaml <<'EOF'
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: appprofiles.training.labex.io
spec:
group: training.labex.io
scope: Namespaced
names:
plural: appprofiles
singular: appprofile
kind: AppProfile
shortNames:
- appprof
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required:
- image
- replicas
properties:
image:
type: string
replicas:
type: integer
minimum: 1
tier:
type: string
EOF
Appliquez la CRD :
kubectl apply -f app-profile-crd.yaml
Sortie attendue :
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io created
Attendez que le serveur d'API confirme que la CRD est établie :
kubectl wait --for=condition=Established crd/appprofiles.training.labex.io --timeout=120s
Sortie attendue :
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io condition met
Inspectez les noms et la portée (scope) de la CRD :
kubectl get crd appprofiles.training.labex.io -o 'jsonpath={.spec.names.kind}{" "}{.spec.names.plural}{" "}{.spec.scope}{"\n"}'
Sortie attendue :
AppProfile appprofiles Namespaced
Découvrir et créer des ressources personnalisées
Dans cette étape, vous allez découvrir le nouveau type de ressource et créer votre premier AppProfile.
kubectl api-resources liste les types de ressources connus du serveur d'API. Une fois qu'une CRD est établie, elle apparaît dans cette liste aux côtés des types de ressources intégrés.
kubectl api-resources --api-group=training.labex.io
La sortie attendue inclut :
NAME SHORTNAMES APIVERSION NAMESPACED KIND
appprofiles appprof training.labex.io/v1 true AppProfile
Utilisez kubectl explain pour lire le schéma que Kubernetes a appris à partir de la CRD. Le champ spec est l'endroit où résident les paramètres spécifiques à l'application.
kubectl explain appprofile.spec
La sortie attendue inclut :
GROUP: training.labex.io
KIND: AppProfile
VERSION: v1
FIELD: spec <Object>
Créez frontend-profile.yaml :
cat > frontend-profile.yaml <<'EOF'
apiVersion: training.labex.io/v1
kind: AppProfile
metadata:
name: frontend
labels:
app.kubernetes.io/part-of: storefront
tier: web
spec:
image: nginx:1.27
replicas: 2
tier: web
EOF
Appliquez la ressource personnalisée :
kubectl apply -f frontend-profile.yaml
Sortie attendue :
appprofile.training.labex.io/frontend created
Listez les ressources personnalisées avec le nom au pluriel :
kubectl get appprofiles
La sortie attendue inclut :
NAME AGE
frontend ...
Lisez les champs de la ressource personnalisée avec jsonpath :
kubectl get appprofile frontend -o 'jsonpath={.spec.image}{" "}{.spec.replicas}{" "}{.spec.tier}{"\n"}'
Sortie attendue :
nginx:1.27 2 web
Mettre à jour et sélectionner des ressources personnalisées
Dans cette étape, vous allez gérer les ressources personnalisées avec les mêmes modèles kubectl que ceux que vous utilisez déjà pour les objets intégrés.
Appliquez un patch à la ressource personnalisée frontend pour modifier le nombre de réplicas souhaité. L'option --type=merge indique à Kubernetes de fusionner votre objet JSON dans l'objet existant au lieu de remplacer toute la ressource.
kubectl patch appprofile frontend --type=merge -p '{"spec":{"replicas":3}}'
Sortie attendue :
appprofile.training.labex.io/frontend patched
Confirmez la valeur mise à jour :
kubectl get appprofile frontend -o 'jsonpath={.spec.replicas}{"\n"}'
Sortie attendue :
3
Créez une deuxième ressource personnalisée nommée worker :
cat > worker-profile.yaml <<'EOF'
apiVersion: training.labex.io/v1
kind: AppProfile
metadata:
name: worker
labels:
app.kubernetes.io/part-of: storefront
tier: worker
spec:
image: busybox:1.36
replicas: 1
tier: worker
EOF
kubectl apply -f worker-profile.yaml
Sortie attendue :
appprofile.training.labex.io/worker created
Listez uniquement les ressources personnalisées appartenant à l'application storefront. Cela fonctionne car les ressources personnalisées prennent en charge les labels Kubernetes standard.
kubectl get appprofiles -l app.kubernetes.io/part-of=storefront
La sortie attendue inclut :
NAME AGE
frontend ...
worker ...
Utilisez le nom court appprof pour afficher le nom de chaque ressource et son nombre de réplicas :
kubectl get appprof -o 'jsonpath={range .items[*]}{.metadata.name}{"="}{.spec.replicas}{"\n"}{end}'
La sortie attendue inclut :
frontend=3
worker=1
Résumé
Vous avez créé une CRD, attendu qu'elle soit établie, découvert la nouvelle ressource API avec kubectl api-resources et kubectl explain, créé des ressources personnalisées, modifié une ressource personnalisée, les avez sélectionnées par label et avez utilisé un nom court. Ce sont les mêmes compétences opérationnelles que vous utiliserez lorsque les tâches CKAD impliqueront des ressources installées par un opérateur, un contrôleur ou une extension de plateforme.
