Kubernetes est conçu pour être extensible. Les ressources natives (Pods, Services, Deployments, etc.) couvrent de nombreux cas d'usage, mais ne suffisent pas toujours pour des besoins spécifiques. Les Custom Resource Definitions (CRDs) et Operators permettent d'étendre Kubernetes pour gérer n'importe quel type d'application ou infrastructure.
Cette fonctionnalité est officiellement incluse dans le curriculum CKA 2025, reconnaissant son importance dans les architectures Kubernetes modernes.
Limitations des ressources natives :
Exemples de cas d'usage :
Un CustomResourceDefinition (CRD) est une ressource Kubernetes qui permet de définir de nouveaux types de ressources personnalisées. Une fois une CRD créé, vous pouvez créer, lire, modifier et supprimer des instances de cette ressource personnalisée (appelées Custom Resources ou CR) comme n'importe quelle ressource native Kubernetes.
Architecture :
Une CRD définit :
mycompany.com)v1, v1beta1)Namespaced ou Cluster (portée)Créons une CRD pour gérer des bases de données de manière déclarative.
# database-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: databases.mycompany.com
spec:
group: mycompany.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
type:
type: string
enum: ["mysql", "postgres", "redis"]
version:
type: string
storage:
type: string
replicas:
type: integer
minimum: 1
maximum: 5
scope: Namespaced
names:
plural: databases
singular: database
kind: Database
shortNames:
- db
Explications :
databases.mycompany.com (format: <plural>.<group>)mycompany.com (votre domaine, évite les conflits)v1 du schéma
Namespaced (ressources par namespace) ou Cluster (globale)databases (utilisé dans les URLs API et kubectl get databases)database (utilisé dans la CLI)Database (utilisé dans les manifestes YAML)db (alias pour kubectl get db)# Appliquer le CRD
kubectl apply -f database-crd.yaml
# Vérifier la création
kubectl get crd databases.mycompany.com
# Voir les détails
kubectl describe crd databases.mycompany.com
Résultat attendu :
NAME CREATED AT
databases.mycompany.com 2025-01-24T10:15:00Z
Une fois le CRD créé, Kubernetes accepte maintenant des ressources de type Database !
Maintenant que le type Database existe, créons des instances :
# mysql-database.yaml
apiVersion: mycompany.com/v1
kind: Database
metadata:
name: mysql-prod
namespace: production
spec:
type: mysql
version: "8.0"
storage: "20Gi"
replicas: 3
# postgres-database.yaml
apiVersion: mycompany.com/v1
kind: Database
metadata:
name: postgres-analytics
namespace: analytics
spec:
type: postgres
version: "16"
storage: "100Gi"
replicas: 2
# redis-database.yaml
apiVersion: mycompany.com/v1
kind: Database
metadata:
name: redis-cache
namespace: production
spec:
type: redis
version: "7.2"
storage: "5Gi"
replicas: 1
Appliquer les ressources :
# Créer les namespaces si nécessaire
kubectl create namespace production
kubectl create namespace analytics
# Créer les databases
kubectl apply -f mysql-database.yaml
kubectl apply -f postgres-database.yaml
kubectl apply -f redis-database.yaml
# Lister toutes les databases
kubectl get databases --all-namespaces
# Utiliser le nom court
kubectl get db -n production
# Voir les détails
kubectl describe database mysql-prod -n production
Résultat :
NAMESPACE NAME AGE
production mysql-prod 30s
analytics postgres-analytics 25s
production redis-cache 20s
Les Custom Resources se manipulent exactement comme les ressources natives :
# GET - Lister
kubectl get databases
kubectl get databases -n production
kubectl get db --all-namespaces
# DESCRIBE - Détails
kubectl describe database mysql-prod -n production
# EDIT - Modifier
kubectl edit database mysql-prod -n production
# DELETE - Supprimer
kubectl delete database redis-cache -n production
# Créer de manière impérative (si supporté)
kubectl create -f new-database.yaml
# Récupérer en YAML
kubectl get database mysql-prod -n production -o yaml
# Récupérer en JSON
kubectl get database mysql-prod -n production -o json
# Utiliser jsonpath
kubectl get database mysql-prod -n production -o jsonpath='{.spec.type}'
# Watch
kubectl get databases -w
Le schéma OpenAPI dans le CRD valide automatiquement les Custom Resources :
# Exemple INVALIDE (sera rejeté)
apiVersion: mycompany.com/v1
kind: Database
metadata:
name: invalid-db
spec:
type: mongodb # ❌ Erreur : pas dans l'enum [mysql, postgres, redis]
version: "5.0"
storage: "10Gi"
replicas: 10 # ❌ Erreur : maximum 5
Résultat :
$ kubectl apply -f invalid-db.yaml
Error from server (BadRequest): error when creating "invalid-db.yaml":
Database.mycompany.com "invalid-db" is invalid:
- spec.type: Unsupported value: "mongodb": supported values: "mysql", "postgres", "redis"
- spec.replicas: Invalid value: 10: spec.replicas in body should be less than or equal to 5
Une CRD peut supporter plusieurs versions simultanément :
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: databases.mycompany.com
spec:
group: mycompany.com
versions:
- name: v1
served: true
storage: true
schema:
# Schéma v1
- name: v1beta1
served: true # Toujours accessible
storage: false # Mais pas stockée (convertie en v1)
schema:
# Schéma v1beta1
La conversion entre versions peut être :
Un Operator est un pattern qui combine :
Pattern Operator = CRD + Controller
Les Operators fonctionnent via une boucle de réconciliation :
Exemple avec notre Database CRD :
État désiré (CR): État actuel: Actions:
Database mysql-prod StatefulSet: 2 replicas → Scale StatefulSet to 3
replicas: 3 PVC: 10Gi → Expand PVC to 20Gi
storage: 20Gi ConfigMap: version 8.0 → No action needed
version: 8.0
┌─────────────────────────────────────────┐
│ Kubernetes API Server │
└───────────────┬─────────────────────────┘
│
│ Watch Custom Resources
▼
┌─────────────────────────────────────────┐
│ Operator (Pod) │
│ ┌─────────────────────────────────┐ │
│ │ Controller Logic │ │
│ │ - Watch CR events │ │
│ │ - Reconciliation loop │ │
│ │ - Business logic │ │
│ │ - Error handling │ │
│ └─────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ Create/Update/Delete │ │
│ │ Native K8s Resources │ │
│ │ - Deployments │ │
│ │ - Services │ │
│ │ - ConfigMaps │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
De nombreux Operators existent pour gérer des applications complexes :
| Operator | Usage | Fonctionnalités |
|---|---|---|
| Prometheus Operator | Monitoring | Gère Prometheus, AlertManager, ServiceMonitors |
| MySQL Operator | Base de données | Provisioning, backup, restore, scaling |
| PostgreSQL Operator | Base de données | Clustering, replication, failover |
| Cert-Manager | Certificats TLS | Émission, renouvellement automatique (Let's Encrypt) |
| Elastic Cloud on K8s | Elasticsearch | Cluster Elasticsearch + Kibana |
| Redis Operator | Cache/DB | Redis clusters, sentinel, persistence |
| Kafka Operator | Messaging | Kafka clusters, topics, security |
| Vault Operator | Secrets | HashiCorp Vault integration |
# Ajouter le repository Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# Installer le Prometheus Operator
helm install prometheus prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespace
# Vérifier les CRDs créés
kubectl get crd | grep monitoring
# Résultat : plusieurs CRDs installés
# prometheuses.monitoring.coreos.com
# servicemonitors.monitoring.coreos.com
# alertmanagers.monitoring.coreos.com
# prometheusrules.monitoring.coreos.com
# Lister les Custom Resources créées
kubectl get prometheus -n monitoring
kubectl get servicemonitor -n monitoring
kubectl get alertmanager -n monitoring
Maintenant vous pouvez créer des ServiceMonitors pour monitorer vos applications :
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app-monitor
namespace: production
spec:
selector:
matchLabels:
app: my-app
endpoints:
- port: metrics
interval: 30s
L'Operator Prometheus détectera ce ServiceMonitor et configurera automatiquement Prometheus pour scraper les métriques !
Points clés pour l'examen CKA 2025 :
Comprendre les concepts :
Savoir manipuler les CRDs :
kubectl applykubectl get crdkubectl describe crdUtiliser les Custom Resources :
kubectl get <resource-type>kubectl describe <resource-type> <name>kubectl delete <resource-type> <name>Troubleshooting :
Commandes essentielles :
# CRDs
kubectl get crd
kubectl describe crd <name>
kubectl get crd <name> -o yaml
# Custom Resources
kubectl get <resource-type>
kubectl get <resource-type> -A
kubectl describe <resource-type> <name>
kubectl get <resource-type> <name> -o yaml
kubectl delete <resource-type> <name>
# Validation
kubectl explain <resource-type>
kubectl explain <resource-type>.spec
Scénarios typiques d'examen :
L'extensibilité via CRDs et Operators est une fonctionnalité puissante qui permet à Kubernetes de s'adapter à n'importe quel cas d'usage. C'est maintenant un sujet officiel du CKA et un élément essentiel des architectures Kubernetes modernes.