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 plus
• readinessProbe : 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

---

🛠️ Essayez maintenant : YAML Formatter | YAML Linter — 100% gratuit, tout est traité dans votre navigateur. Aucune donnée envoyée.

---