YAML pour Kubernetes : Patrons Essentiels de Manifestes
Kubernetes est entièrement configuré via des manifestes YAML. Chaque pod, deployment, service et ingress est défini en YAML. Maîtriser ces patrons est essentiel pour quiconque travaille avec l'orchestration de conteneurs. Ce guide couvre les types de ressources les plus importants avec des exemples prêts pour la production.
Les Quatre Champs Obligatoires
Chaque manifeste Kubernetes nécessite :
apiVersion: apps/v1 # API version for this resource type
kind: Deployment # Resource type
metadata: # Resource identification
name: my-app
namespace: production
labels:
app: my-app
spec: # Desired state specification
# ... resource-specific configuration
Deployment
La ressource la plus courante — gère un ensemble de pods identiques :
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
labels:
app: api-server
environment: production
spec:
replicas: 3
selector:
matchLabels:
app: api-server
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: api-server
spec:
containers:
- name: api
image: myapp/api:v1.2.3
ports:
- containerPort: 8080
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: db-credentials
key: url
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
Patrons Clés
Définissez toujours les demandes et limites de ressources : Sans elles, un seul pod peut consommer toutes les ressources du nœud.
Configurez toujours les sondes de santé :
livenessProbe: Redémarre le pod s'il ne répond plusreadinessProbe: Arrête d'envoyer du trafic jusqu'à ce que le pod soit prêt
Utilisez des tags d'image spécifiques : N'utilisez jamais latest en production — cela rend les retours en arrière impossibles.
Service
Expose les pods au trafic réseau :
apiVersion: v1
kind: Service
metadata:
name: api-server
spec:
type: ClusterIP
selector:
app: api-server
ports:
- port: 80
targetPort: 8080
protocol: TCP
Types de services :
- ClusterIP (par défaut) : Accès interne au cluster uniquement
- NodePort : Expose sur chaque IP de nœud à un port statique
- LoadBalancer : Provisionne un équilibreur de charge cloud
- ExternalName : Mappe vers un nom DNS
ConfigMap et Secret
ConfigMap (données non sensibles)
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
MAX_CONNECTIONS: "100"
config.yaml: |
server:
port: 8080
timeout: 30s
Secret (données sensibles)
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
stringData:
url: "postgres://user:password@db:5432/myapp"
api-key: "sk-1234567890"
Utilisation dans les Pods
# As environment variables
env:
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config
key: LOG_LEVEL
# As a mounted file
volumes:
- name: config
configMap:
name: app-config
Ingress
Route le trafic HTTP externe vers les services :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-ingress
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
ingressClassName: nginx
tls:
- hosts:
- api.example.com
secretName: tls-secret
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-server
port:
number: 80
Horizontal Pod Autoscaler
Met à l'échelle les pods en fonction du CPU ou de métriques personnalisées :
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api-server-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api-server
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Erreurs Courantes
1. Erreurs d'Indentation
L'indentation YAML est critique dans Kubernetes. Un espace mal placé change entièrement la structure. Validez vos manifestes avec notre Validateur YAML.
2. Discordance de Labels
Le sélecteur du Service doit correspondre exactement aux labels du Pod. Une discordance signifie que le Service ne peut trouver aucun pod vers lequel router le trafic.
3. Limites de Ressources Manquantes
Les pods sans limites de ressources peuvent priver les autres charges de travail. Incluez toujours à la fois les demandes (minimum garanti) et les limites (maximum autorisé).
4. Tags d'Image Mutables
Utiliser latest ou d'autres tags mutables rend les retours en arrière impossibles et les déploiements imprévisibles. Fixez des versions spécifiques ou utilisez des digests immuables.
Manifestes Multi-Documents
Combinez des ressources liées dans un seul fichier en utilisant --- comme séparateur de document :
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
# ... deployment spec
---
apiVersion: v1
kind: Service
metadata:
name: api-server
spec:
# ... service spec
Pour en savoir plus sur les patrons de syntaxe YAML, consultez notre tutoriel de syntaxe YAML.
FAQ
Dois-je écrire le YAML Kubernetes à la main ou utiliser des générateurs ?
Commencez par écrire le YAML à la main pour comprendre la structure. Pour la production, utilisez des outils comme Helm (manifestes avec templates), Kustomize (personnalisation par couches) ou CDK8s (génération basée sur le code). Ces outils réduisent la répétition et permettent une configuration spécifique à l'environnement sans dupliquer les manifestes.
Comment déboguer les erreurs YAML Kubernetes ?
Utilisez kubectl apply --dry-run=client -f manifest.yaml pour valider sans appliquer. Pour les erreurs de syntaxe, kubectl explain deployment.spec.template.spec.containers montre la structure attendue. Les outils kubeval et kubeconform valident contre les schémas API Kubernetes avant le déploiement.
Ressources Connexes
- Validateur YAML — Validez les manifestes Kubernetes
- YAML pour Docker Compose — Patrons YAML Docker
- Bonnes Pratiques de Linting YAML — Détectez les erreurs avant le déploiement