Générateur de Manifeste Kubernetes

Guidance pas à pas pour créer des manifestes Kubernetes prêts pour la production, incluant Deployments, Services, ConfigMaps, Secrets et PersistentVolumeClaims.

Objectif

Cette compétence fournit un guidance complet pour générer des manifestes Kubernetes bien structurés, sécurisés et prêts pour la production, en suivant les bonnes pratiques cloud-native et les conventions Kubernetes.

Quand utiliser cette compétence

Utilisez cette compétence quand vous avez besoin de :

• Créer de nouveaux manifestes Kubernetes Deployment
• Définir des ressources Service pour la connectivité réseau
• Générer des ressources ConfigMap et Secret pour la gestion de configuration
• Créer des manifestes PersistentVolumeClaim pour les workloads stateful
• Suivre les bonnes pratiques Kubernetes et les conventions de nommage
• Implémenter des limites de ressources, des health checks et des contextes de sécurité
• Concevoir des manifestes pour des déploiements multi-environnement

Workflow étape par étape

1. Rassembler les exigences

Comprendre la workload :

• Type d'application (stateless/stateful)
• Image conteneur et version
• Besoins en variables d'environnement et configuration
• Exigences de stockage
• Exigences d'exposition réseau (interne/externe)
• Exigences en ressources (CPU, mémoire)
• Exigences d'évolutivité
• Points d'accès pour les health checks

Questions à poser :

• Quel est le nom et l'objectif de l'application ?
• Quelle image conteneur et quel tag seront utilisés ?
• L'application a-t-elle besoin de stockage persistant ?
• Quels ports l'application expose-t-elle ?
• Y a-t-il des secrets ou des fichiers de configuration nécessaires ?
• Quelles sont les exigences en CPU et mémoire ?
• L'application doit-elle être exposée en externe ?

2. Créer le manifeste Deployment

Suivez cette structure :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <app-name>
  namespace: <namespace>
  labels:
    app: <app-name>
    version: <version>
spec:
  replicas: 3
  selector:
    matchLabels:
      app: <app-name>
  template:
    metadata:
      labels:
        app: <app-name>
        version: <version>
    spec:
      containers:
        - name: <container-name>
          image: <image>:<tag>
          ports:
            - containerPort: <port>
              name: http
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: http
            initialDelaySeconds: 5
            periodSeconds: 5
          env:
            - name: ENV_VAR
              value: "value"
          envFrom:
            - configMapRef:
                name: <app-name>-config
            - secretRef:
                name: <app-name>-secret

Bonnes pratiques à appliquer :

• Définissez toujours les demandes et limites de ressources
• Implémentez les probes liveness et readiness
• Utilisez des tags d'image spécifiques (jamais :latest)
• Appliquez un contexte de sécurité pour les utilisateurs non-root
• Utilisez des labels pour l'organisation et la sélection
• Définissez un nombre de réplicas approprié en fonction des besoins de disponibilité

Référence : Voir references/deployment-spec.md pour les options de deployment détaillées

3. Créer le manifeste Service

Choisissez le type de Service approprié :

ClusterIP (interne uniquement) :

apiVersion: v1
kind: Service
metadata:
  name: <app-name>
  namespace: <namespace>
  labels:
    app: <app-name>
spec:
  type: ClusterIP
  selector:
    app: <app-name>
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

LoadBalancer (accès externe) :

apiVersion: v1
kind: Service
metadata:
  name: <app-name>
  namespace: <namespace>
  labels:
    app: <app-name>
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
spec:
  type: LoadBalancer
  selector:
    app: <app-name>
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

Référence : Voir references/service-spec.md pour les types de services et les détails de mise en réseau

4. Créer ConfigMap

Pour la configuration de l'application :

apiVersion: v1
kind: ConfigMap
metadata:
  name: <app-name>-config
  namespace: <namespace>
data:
  APP_MODE: production
  LOG_LEVEL: info
  DATABASE_HOST: db.example.com
  # Pour les fichiers de config
  app.properties: |
    server.port=8080
    server.host=0.0.0.0
    logging.level=INFO

Bonnes pratiques :

• Utilisez ConfigMaps pour les données non-sensibles uniquement
• Organisez les configurations associées ensemble
• Utilisez des noms significatifs pour les clés
• Envisagez d'utiliser une ConfigMap par composant
• Versionner les ConfigMaps lors des modifications

Référence : Voir assets/configmap-template.yaml pour des exemples

5. Créer Secret

Pour les données sensibles :

apiVersion: v1
kind: Secret
metadata:
  name: <app-name>-secret
  namespace: <namespace>
type: Opaque
stringData:
  DATABASE_PASSWORD: "changeme"
  API_KEY: "secret-api-key"
  # Pour les fichiers de certificat
  tls.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tls.key: |
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

Considérations de sécurité :

• Ne validez jamais les secrets en texte brut dans Git
• Utilisez Sealed Secrets, External Secrets Operator ou Vault
• Rotatez les secrets régulièrement
• Utilisez RBAC pour limiter l'accès aux secrets
• Envisagez d'utiliser le type Secret kubernetes.io/tls pour les secrets TLS

6. Créer PersistentVolumeClaim (si nécessaire)

Pour les applications stateful :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <app-name>-data
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3
  resources:
    requests:
      storage: 10Gi

Monter dans Deployment :

spec:
  template:
    spec:
      containers:
        - name: app
          volumeMounts:
            - name: data
              mountPath: /var/lib/app
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: <app-name>-data

Considérations de stockage :

• Choisissez une StorageClass appropriée pour les besoins de performance
• Utilisez ReadWriteOnce pour l'accès à un seul pod
• Utilisez ReadWriteMany pour le stockage partagé multi-pod
• Envisagez les stratégies de sauvegarde
• Définissez des politiques de rétention appropriées

7. Appliquer les bonnes pratiques de sécurité

Ajouter un contexte de sécurité au Deployment :

spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL

Checklist de sécurité :

• [ ] Exécuter en tant qu'utilisateur non-root
• [ ] Supprimer toutes les capabilities
• [ ] Utiliser un filesystem racine en lecture seule
• [ ] Désactiver l'escalade de privilèges
• [ ] Définir un profil seccomp
• [ ] Utiliser Pod Security Standards

8. Ajouter Labels et Annotations

Labels standard (recommandés) :

metadata:
  labels:
    app.kubernetes.io/name: <app-name>
    app.kubernetes.io/instance: <instance-name>
    app.kubernetes.io/version: "1.0.0"
    app.kubernetes.io/component: backend
    app.kubernetes.io/part-of: <system-name>
    app.kubernetes.io/managed-by: kubectl

Annotations utiles :

metadata:
  annotations:
    description: "Application description"
    contact: "team@example.com"
    prometheus.io/scrape: "true"
    prometheus.io/port: "9090"
    prometheus.io/path: "/metrics"

9. Organiser les manifestes multi-ressources

Options d'organisation des fichiers :

Option 1 : Fichier unique avec séparateur ---

# app-name.yaml
---
apiVersion: v1
kind: ConfigMap
...
---
apiVersion: v1
kind: Secret
...
---
apiVersion: apps/v1
kind: Deployment
...
---
apiVersion: v1
kind: Service
...

Option 2 : Fichiers séparés

manifests/
├── configmap.yaml
├── secret.yaml
├── deployment.yaml
├── service.yaml
└── pvc.yaml

Option 3 : Structure Kustomize

base/
├── kustomization.yaml
├── deployment.yaml
├── service.yaml
└── configmap.yaml
overlays/
├── dev/
│   └── kustomization.yaml
└── prod/
    └── kustomization.yaml

10. Valider et tester

Étapes de validation :

# Validation dry-run
kubectl apply -f manifest.yaml --dry-run=client

# Validation côté serveur
kubectl apply -f manifest.yaml --dry-run=server

# Valider avec kubeval
kubeval manifest.yaml

# Valider avec kube-score
kube-score score manifest.yaml

# Vérifier avec kube-linter
kube-linter lint manifest.yaml

Checklist de test :

• [ ] Le manifeste passe la validation dry-run
• [ ] Tous les champs requis sont présents
• [ ] Les limites de ressources sont raisonnables
• [ ] Les health checks sont configurés
• [ ] Le contexte de sécurité est défini
• [ ] Les labels suivent les conventions
• [ ] L'espace de noms existe ou est créé

Patterns courants

Pattern 1 : Application web stateless simple

Cas d'usage : API web standard ou microservice

Composants nécessaires :

• Deployment (3 réplicas pour HA)
• Service ClusterIP
• ConfigMap pour la configuration
• Secret pour les clés API
• HorizontalPodAutoscaler (optionnel)

Référence : Voir assets/deployment-template.yaml

Pattern 2 : Application stateful (base de données)

Cas d'usage : Application de base de données ou de stockage persistant

Composants nécessaires :

• StatefulSet (pas Deployment)
• Service headless
• Modèle PersistentVolumeClaim
• ConfigMap pour la configuration DB
• Secret pour les credentials

Pattern 3 : Job ou Cron en arrière-plan

Cas d'usage : Tâches planifiées ou traitement batch

Composants nécessaires :

• CronJob ou Job
• ConfigMap pour les paramètres du job
• Secret pour les credentials
• ServiceAccount avec RBAC

Pattern 4 : Pod multi-conteneur

Cas d'usage : Application avec conteneurs sidecar

Composants nécessaires :

• Deployment avec plusieurs conteneurs
• Volumes partagés entre conteneurs
• Init containers pour la configuration
• Service (si nécessaire)

Templates

Les templates suivants sont disponibles dans le répertoire assets/ :

• deployment-template.yaml - Deployment standard avec bonnes pratiques
• service-template.yaml - Configurations de Service (ClusterIP, LoadBalancer, NodePort)
• configmap-template.yaml - Exemples de ConfigMap avec différents types de données
• secret-template.yaml - Exemples de Secret (à générer, pas à valider)
• pvc-template.yaml - Templates de PersistentVolumeClaim

Documentation de référence

• references/deployment-spec.md - Spécification Deployment détaillée
• references/service-spec.md - Types de Services et détails de mise en réseau

Résumé des bonnes pratiques

1. Définissez toujours les demandes et limites de ressources - Prévient la famine de ressources
2. Implémentez les health checks - Permet à Kubernetes de gérer votre application
3. Utilisez des tags d'image spécifiques - Évitez les déploiements imprévisibles
4. Appliquez des contextes de sécurité - Exécutez en non-root, supprimez les capabilities
5. Utilisez ConfigMaps et Secrets - Séparez la configuration du code
6. Libellisez tout - Permet le filtrage et l'organisation
7. Suivez les conventions de nommage - Utilisez les labels Kubernetes standard
8. Validez avant d'appliquer - Utilisez les outils dry-run et validation
9. Versionnez vos manifestes - Conservez-les dans Git avec le contrôle de version
10. Documentez avec des annotations - Ajoutez du contexte pour les autres développeurs

Dépannage

Les pods ne démarrent pas :

• Vérifiez les erreurs de pull d'image : kubectl describe pod <pod-name>
• Vérifiez la disponibilité des ressources : kubectl get nodes
• Vérifiez les événements : kubectl get events --sort-by='.lastTimestamp'

Le Service n'est pas accessible :

• Vérifiez que le sélecteur correspond aux labels des pods : kubectl get endpoints <service-name>
• Vérifiez le type de service et la configuration des ports
• Testez depuis le cluster : kubectl run debug --rm -it --image=busybox -- sh

ConfigMap/Secret ne se charge pas :

• Vérifiez que les noms correspondent dans le Deployment
• Vérifiez l'espace de noms
• Assurez-vous que les ressources existent : kubectl get configmap,secret

Étapes suivantes

Après la création des manifestes :

1. Stockez dans un repository Git
2. Configurez un pipeline CI/CD pour le déploiement
3. Envisagez d'utiliser Helm ou Kustomize pour le templating
4. Implémentez GitOps avec ArgoCD ou Flux
5. Ajoutez la monitoring et l'observabilité

Compétences associées

• helm-chart-scaffolding - Pour le templating et l'empaquetage
• gitops-workflow - Pour les déploiements automatisés
• k8s-security-policies - Pour les configurations de sécurité avancées