Kubernetes Patterns

Ce skill couvre les patterns concrets pour déployer et opérer des applications sur Kubernetes en production. La provisioning du cluster lui-même (EKS, GKE, AKS) est couvert par terraform-patterns.

1. Workload types — décision

Type d'application
├── Stateless web service (API REST, frontend)
│   └── Deployment + Service (ClusterIP) + Ingress
├── Stateful (database, queue, search engine)
│   └── StatefulSet + Headless Service + PersistentVolumeClaim
├── Run on every node (logging agent, CNI, monitoring)
│   └── DaemonSet
├── One-off task (DB migration, batch ingestion)
│   └── Job
├── Periodic task (cron, cleanup, reports)
│   └── CronJob
└── User-facing batch processing
    └── KEDA + Job avec event-driven scaling

2. Deployment canonique

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
  labels:
    app: api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      serviceAccountName: api
      containers:
        - name: api
          image: ghcr.io/myorg/api:1.2.3
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
              name: http
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: api-secrets
                  key: database_url
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            initialDelaySeconds: 5
            periodSeconds: 5
          startupProbe:
            httpGet:
              path: /health/live
              port: http
            failureThreshold: 30
            periodSeconds: 10
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: production
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - port: 80
      targetPort: http
      name: http
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  namespace: production
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts: [api.example.com]
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  name: http

3. Resource requests + limits

QoS Class	Conditions	Use case
Guaranteed	requests == limits pour CPU + memory	Workloads critiques (DBs, payment processors)
Burstable	requests < limits	La majorité des web apps
BestEffort	Pas de requests ni limits	Jobs non-critiques uniquement

Règles :

• Toujours définir des requests (sans elles, le scheduler ne peut pas placer le pod intelligemment)
• Limit memory = 1.5-2x le requests (kill OOM si dépassé, pas de throttle)
• Limit CPU = controversé (CPU throttling peut causer plus de problèmes qu'il n'en résout) — souvent on omet le limit CPU en prod

4. HorizontalPodAutoscaler

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 100
          periodSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

KEDA (event-driven scaling)

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker
spec:
  scaleTargetRef:
    name: worker
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
    - type: rabbitmq
      metadata:
        queueName: jobs
        host: amqp://rabbit:5672
        queueLength: "10"

KEDA supporte 70+ event sources (Kafka, Redis, AWS SQS, GCP Pub/Sub, Azure Service Bus, MongoDB, Postgres, etc.).

5. PodDisruptionBudget

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api
  namespace: production
spec:
  minAvailable: 2  # ou maxUnavailable: 1
  selector:
    matchLabels:
      app: api

Empêche les drains de node de descendre en-dessous de 2 replicas.

6. ConfigMaps + Secrets

Configuration via env vars

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
data:
  LOG_LEVEL: info
  REDIS_URL: redis://redis:6379
---
apiVersion: v1
kind: Secret
metadata:
  name: api-secrets
type: Opaque
stringData:
  database_url: postgres://user:pass@db:5432/app
  jwt_secret: supersecret

# Dans le Deployment
envFrom:
  - configMapRef:
      name: api-config
  - secretRef:
      name: api-secrets

Secrets en GitOps

Le problème : un Secret est juste base64 (pas chiffré). Solutions :

Solution	Comment
Sealed Secrets	kubeseal chiffre avec la pubkey du controller. Le Secret chiffré est commitable en Git.
External Secrets Operator	Pull les secrets depuis AWS SSM / Vault / GCP Secret Manager / Azure Key Vault au runtime.
SOPS + KMS	Encrypt YAML files avec AWS KMS / GCP KMS, decrypt au déploiement.

# ExternalSecret avec AWS Parameter Store
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-parameter-store
    kind: ClusterSecretStore
  target:
    name: api-secrets
    creationPolicy: Owner
  data:
    - secretKey: database_url
      remoteRef:
        key: /prod/api/database_url

7. NetworkPolicies (zero-trust)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-from-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

Important : par défaut, K8s autorise tout. Une fois qu'au moins une NetworkPolicy match un pod, elle devient default-deny pour les directions listées. Donc commencer par une deny-all puis ajouter des allow-from.

8. RBAC

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: api-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["configmaps", "secrets"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-reader
  namespace: production
subjects:
  - kind: ServiceAccount
    name: api
    namespace: production
roleRef:
  kind: Role
  name: api-reader
  apiGroup: rbac.authorization.k8s.io

9. Helm chart structure

charts/api/
├── Chart.yaml
├── values.yaml
├── values.prod.yaml
├── templates/
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   ├── hpa.yaml
│   └── pdb.yaml
└── README.md

Chart.yaml

apiVersion: v2
name: api
description: My API
type: application
version: 1.2.3       # Chart version
appVersion: "2.5.0"  # App version

dependencies:
  - name: postgresql
    version: "13.x.x"
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled

Template avec helpers

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "api.fullname" . }}
  labels:
    {{- include "api.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "api.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "api.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

helm install api ./charts/api -f values.prod.yaml
helm upgrade api ./charts/api -f values.prod.yaml
helm rollback api 1

10. GitOps avec ArgoCD

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/production/api
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

ArgoCD watch le repo Git → toute modif est synced automatiquement. La source de vérité est Git, pas l'état du cluster.

11. Pod Security Standards (PSS)

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

3 niveaux : privileged (no restriction), baseline (raisonnable), restricted (strict). Production = restricted.

12. Anti-patterns

1. Pas de resource requests — scheduler aveugle
2. CPU limit serré → throttling intempestif
3. latest tag → impossible de rollback proprement
4. runAsRoot: true ou pas de securityContext → escalade facile
5. Pas de NetworkPolicies → tout pod peut tout joindre
6. Secrets en clair dans Git → game over
7. Pas de PDB → tous les replicas peuvent partir en même temps lors d'un drain
8. Pas de readiness probe → traffic envoyé à un pod pas prêt
9. Liveness == Readiness probe → restart loop
10. Helm release sans values pinned per env → drift
11. kubectl apply direct en prod au lieu de GitOps → pas de traçabilité
12. Pas de monitoring du cluster lui-même (etcd, kubelet, nodes) — incident invisible
13. Pas de PSS → containers privilégiés possibles

Checklist livraison

• Resource requests + limits raisonnables
• Liveness + Readiness + Startup probes
• securityContext avec runAsNonRoot
• PDB avec minAvailable
• HPA basé sur CPU + métriques custom
• NetworkPolicy default-deny + allow-from précis
• RBAC minimal (1 ServiceAccount par service)
• Secrets via External Secrets / Sealed Secrets / SOPS
• Ingress + cert-manager pour TLS auto
• PSS restricted sur les namespaces user
• GitOps (ArgoCD ou FluxCD)
• Observability (Prometheus + Grafana + Loki + Tempo)
• Backup etcd + persistent volumes
• DR plan testé

Quand déléguer

• Cluster provisioning → skill terraform-patterns (ce plugin)
• CI/CD pipelines → agent ci-cd-engineer (atum-stack-backend)
• Container hardening → agent security-expert (atum-compliance)
• Architecture cloud → skill cloud-architecture (ce plugin)

Ressources

• https://kubernetes.io/docs/
• https://helm.sh/docs/
• https://argo-cd.readthedocs.io/
• https://keda.sh/
• https://kubernetes.io/docs/concepts/security/pod-security-standards/