Configurer ses pods Kubernetes

Configurer ses pods Kubernetes

Sommaire

La configuration des pods Kubernetes est un élément clé pour déployer des applications de manière fiable et flexible. Entre les ConfigMaps, les Secrets et l’injection de variables d’environnement, il existe plusieurs façons de transmettre les paramètres nécessaires à vos conteneurs. Bien maîtriser ces mécanismes permet d’éviter les mauvaises pratiques (comme coder en dur des secrets) et d’optimiser le comportement de vos applications, notamment en termes de consommation de ressources.

Les configMaps

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: app-ns # attention les configMaps ne sont visibles que sur le même namespace
data:
  APP_NAME: "catalog"
  APP_PORT: "8080"
  LOG_LEVEL: "info"

kubectl apply -f app-config.yml

Les secrets

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  namespace: app-ns # attention les secrets ne sont visibles que sur le même namespace
type: Opaque
stringData: # pratique en YAML : pas besoin de base64 ici
  DB_USER: "catalog_user"
  DB_PASS: "S3cr3t!"

kubectl apply -f app-secret.yml

kubectl create secret generic app-secrets \
  --from-literal=KEY1=secretValue1 \ 
  --from-literal=KEY2=secretValue2

Injection dans le pod

En bloc avec envFrom

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalog
spec:
  replicas: 1
  selector:
    matchLabels: { app: catalog }
  template:
    metadata:
      labels: { app: catalog }
    spec:
      containers:
        - name: api
          image: ghcr.io/example/catalog:1.0.0
          envFrom:
            - configMapRef:
                name: app-config
              # optional: true
            - secretRef:
                name: app-secrets
              # optional: true
          ports:
            - containerPort: 8080

Au détail avec env[].valueFrom

env:
  - name: APP_PORT
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_PORT
        optional: false
  - name: DB_USER
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: DB_USER
  - name: DB_PASS
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: DB_PASS
  - name: LOG_LEVEL
    value: "debug"   # valeur explicite qui écrase toute autre source

Règle de priorité

  1. Les entrées explicites dans env: (avec value ou valueFrom) prennent le dessus sur envFrom.
  2. Entre plusieurs envFrom, l’ordre compte : les éléments listés après peuvent écraser des clés définies par les éléments listés avant (utile pour définir des valeurs par défaut puis les surcharger avec des secrets).

Les limites de ressources

Mise en place

apiVersion: v1
kind: Pod
metadata:
  name: mon-pod
spec:
  containers:
  - name: mon-container
    image: nginx:latest
    resources:
      requests:
        memory: "256Mi"   # mémoire minimum garantie
        cpu: "250m"       # 0.25 vCPU garanti
      limits:
        memory: "512Mi"   # mémoire maximum autorisée
        cpu: "500m"       # 0.5 vCPU maximum

Explications

Requests

Quantité de ressources que Kubernetes garantit au conteneur.

Sert au scheduler pour placer le Pod sur un nœud disposant des ressources nécessaires.

Limits

Quantité maximale que le conteneur peut consommer. Si le conteneur dépasse :

  • CPU : il est limité (throttling).
  • Mémoire : il est killé (OOMKilled) par le kernel.

Cas Particuliers: Les Pods Java

Java < 10

Laisser 20–25% de la mémoire pour :

  • Metaspace
  • Direct buffers (notamment avec Netty, gRPC, etc.)
  • Threads (stack memory)
  • Overhead du GC

Exemple : si limit.memory = 1Gi, mets -Xmx750m.

Java >= 10

Pour la RAM

Depuis Java 10, la JVM est container-aware grâce à UseContainerSupport. Cela permet à la JVM de détecter la limite mémoire cgroup (Kubernetes) et d’ajuster automatiquement Xmx.

Exemple :

java -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -jar app.jar

Ici, Xmx sera automatiquement fixé à 75% de la limite mémoire du Pod.

Pour le CPU

On peut aussi ajouter une option pour forcer le nombre de threads utilisables en cohérence avec cpu.limits.

java -XX:ActiveProcessorCount -jar app.jar

Sinon, la JVM peut croire qu’elle a accès à tous les cores du nœud, et créer trop de threads ce qui peut mener à une contention.

Conclusion

Configurer correctement vos pods n’est pas seulement une question de syntaxe, mais un véritable levier de stabilité et de performance. En combinant ConfigMaps, Secrets, et bonnes pratiques d’injection, vous obtenez des déploiements reproductibles et sécurisés. Et en ajustant les limites de ressources et les réglages spécifiques (comme pour les applications Java), vous vous assurez que vos services tournent de façon optimale dans tous les environnements.

Tags :
Partager :