Guide DBA Kubernetes Native

1. Vision générale — ce qu’est vraiment un DBA Kubernetes Native

Objectif du guide

Préparer une infrastructure de démonstration et une culture opérationnelle crédible pour une mission DBA où les bases de données sont déployées, sécurisées, surveillées et restaurées dans Kubernetes via opérateurs, GitOps et stockage persistant.

Dans cette fiche, le DBA n’est pas seulement responsable du moteur SQL ou NoSQL. Il devient responsable du cycle de vie complet de la donnée dans Kubernetes : manifeste déclaratif, opérateur, StatefulSet, PVC, snapshot, backup, restauration, failover, secret, certificats, RBAC, quotas, observabilité et montée de version.

Git

Source de vérité

→

ArgoCD / Flux

Réconciliation GitOps

→

Operators

CNPG, ECK, MariaDB, MongoDB

→

Stateful workloads

Pods, Services, PVC

→

Data protection

Backup, snapshot, restore, PITR

DBA

SQL, HA, backup, restauration, performance, volumétrie.

K8s

Namespaces, RBAC, PVC, StorageClass, StatefulSet, quotas.

GitOps

Manifests versionnés, ArgoCD/Flux, drift control, rollback.

SRE

Runbooks, alerting, incident response, RPO/RTO, postmortem.

Carte des responsabilités

Domaine	Responsabilité attendue	Preuve à préparer
Provisioning	Décrire les clusters DB via CRD, Helm, Kustomize et GitOps.	Repo Git structuré avec manifests par environnement.
Haute disponibilité	Comprendre failover, quorum, replicas, anti-affinity et PDB.	Démo suppression pod primary + validation service.
Sauvegarde	Choisir entre backup logique, physique, WAL, snapshot et object storage.	Backup automatique + restore testé.
Sécurité	Gérer secrets, TLS, RBAC, chiffrement volumes et accès moindre privilège.	Manifests RBAC, ExternalSecret, NetworkPolicy et TLS.
Exploitation	Surveiller métriques, logs, alertes, saturation PVC, erreurs backup.	Dashboards Prometheus/Grafana + règles Alertmanager.

Sommaire opérationnel

Préparer un lab local, VM ou cloud.
Installer un socle Kubernetes stateful.
Mettre en place GitOps avec ArgoCD ou Flux.
Déployer PostgreSQL avec CloudNativePG.
Déployer Elasticsearch avec ECK et OpenSearch avec son opérateur.
Déployer MariaDB/Galera et comprendre le quorum.
Déployer MongoDB replica set et comprendre le sharding.
Sécuriser secrets, TLS, RBAC, volumes et flux réseau.
Surveiller avec Prometheus, Grafana, Alertmanager et logs.
Écrire des runbooks de failover, restore, PITR, upgrade.
Préparer les questions client et les réponses entretien.

Phrase à retenir : “Je ne vois pas ce poste comme un DBA classique, mais comme un rôle DBA Platform : garantir le cycle de vie complet des moteurs de données dans Kubernetes, depuis Git jusqu’au restore testé.”

2. Infrastructure de lab à préparer

Il faut préparer une infrastructure qui permet de démontrer la maîtrise des sujets réels : pods stateful, volumes persistants, backups sur object storage, failover, restore et GitOps. Le lab doit être simple à expliquer, mais assez sérieux pour montrer une vraie démarche de production.

Les 3 niveaux de lab

Niveau	Objectif	Stack recommandée	Limite
Local	Apprendre les manifests et opérateurs.	kind ou k3d, MinIO, ArgoCD, CNPG, ECK, External Secrets.	Storage non représentatif d’une production.
VM sérieux	Tester failover, PVC, snapshots, quotas, anti-affinity.	1 control-plane, 3 workers, Longhorn/OpenEBS, MinIO, Prometheus.	Demande 32 à 48 Go de RAM pour être confortable.
Cloud	Se rapprocher du client final.	EKS/AKS/GKE, CSI cloud, S3/Blob/GCS, KMS, Vault, ArgoCD.	Coût et complexité plus élevés.

Architecture cible du lab VM

Control plane

API server, scheduler, controllers

Worker 1

PostgreSQL replica, ES data, Mongo secondary

Worker 2

PostgreSQL primary, MariaDB node, ES master

Worker 3

PostgreSQL replica, Mongo primary, backup jobs

Dimensionnement minimal conseillé

Composant	Minimum	Confortable	Remarque DBA
Control-plane	2 vCPU / 4 Go	2 vCPU / 8 Go	Éviter d’y placer les DB.
Workers	3 x 2 vCPU / 8 Go	3 x 4 vCPU / 12-16 Go	Anti-affinity et tests de perte de nœud.
Disque	200 Go SSD	500 Go SSD	Prévoir snapshots, WAL, index et backups.
Object storage	MinIO local	S3 compatible	Indispensable pour backup/restore réaliste.

Arborescence de travail

db-k8s-platform/
                clusters/
                local/
                staging/
                production/
                platform/
                namespaces/
                rbac/
                quotas/
                storage/
                network-policies/
                observability/
                secrets/
                operators/
                cloudnative-pg/
                eck/
                opensearch/
                mariadb/
                mongodb/
                databases/
                postgres/
                elasticsearch/
                opensearch/
                mariadb/
                mongodb/
                backup/
                minio/
                policies/
                restore-tests/
                runbooks/
                postgres-pitr.md
                elasticsearch-restore.md
                mariadb-galera-recovery.md
                mongodb-election.md
                operator-upgrade.md

Commandes simples de bootstrap local

#!/usr/bin/env bash
                set -euo pipefail

                kind create cluster --name db-lab --config kind-db-lab.yaml
                kubectl create namespace gitops
                kubectl create namespace db-operators
                kubectl create namespace db-postgres
                kubectl create namespace db-search
                kubectl create namespace db-mariadb
                kubectl create namespace db-mongodb
                kubectl create namespace observability
                kubectl create namespace security

Conseil entretien : explique que ton lab local sert à valider les manifests et les procédures, mais que les sujets critiques comme IOPS, snapshots CSI, multi-AZ et chiffrement doivent être validés sur un vrai cluster.

3. Socle Kubernetes indispensable aux bases de données

Les bases de données sur Kubernetes reposent sur des primitives essentielles : namespace, RBAC, quotas, StatefulSet, PersistentVolumeClaim, StorageClass, VolumeSnapshot, NetworkPolicy, Secret et Service. Un DBA Kubernetes Native doit être capable de lire et diagnostiquer ces objets sans dépendre entièrement de l’équipe plateforme.

Objets Kubernetes à connaître

Objet	Rôle	Risque si mal configuré
Namespace	Isolation logique des workloads et politiques.	Mélange prod/dev, RBAC trop large, quotas absents.
StatefulSet	Identité stable des pods stateful.	Perte d’ordre, mauvais rolling update, stockage incohérent.
PVC	Demande de stockage persistant.	Suppression accidentelle, saturation, mauvais IOPS.
StorageClass	Type de stockage offert au cluster.	Stockage lent, non chiffré, non snapshotable.
RBAC	Contrôle des droits API Kubernetes.	Accès secrets ou suppression PVC par erreur.
ResourceQuota	Limite de consommation par namespace.	Un moteur consomme tout le cluster.
NetworkPolicy	Contrôle des flux réseau entre pods.	Base exposée à trop de workloads.
VolumeSnapshot	Snapshot CSI d’un volume persistant.	Fausse impression de backup si non testé.

Namespaces recommandés

apiVersion: v1
                kind: Namespace
                metadata:
                name: db-postgres
                labels:
                platform.ideo-lab.com/domain: database
                platform.ideo-lab.com/engine: postgres
                ---
                apiVersion: v1
                kind: Namespace
                metadata:
                name: db-search
                labels:
                platform.ideo-lab.com/domain: search
                ---
                apiVersion: v1
                kind: Namespace
                metadata:
                name: db-mariadb
                labels:
                platform.ideo-lab.com/domain: database
                platform.ideo-lab.com/engine: mariadb
                ---
                apiVersion: v1
                kind: Namespace
                metadata:
                name: db-mongodb
                labels:
                platform.ideo-lab.com/domain: database
                platform.ideo-lab.com/engine: mongodb

Quota namespace database

apiVersion: v1
                kind: ResourceQuota
                metadata:
                name: db-namespace-quota
                namespace: db-postgres
                spec:
                hard:
                requests.cpu: "8"
                limits.cpu: "16"
                requests.memory: 32Gi
                limits.memory: 48Gi
                requests.storage: 500Gi
                persistentvolumeclaims: "20"
                pods: "40"
                secrets: "80"
                services: "20"

StorageClass production

apiVersion: storage.k8s.io/v1
                kind: StorageClass
                metadata:
                name: db-fast-retain
                provisioner: csi.example.com
                reclaimPolicy: Retain
                allowVolumeExpansion: true
                volumeBindingMode: WaitForFirstConsumer
                parameters:
                type: fast-ssd
                encrypted: "true"

RBAC DBA read-only

apiVersion: rbac.authorization.k8s.io/v1
                kind: Role
                metadata:
                name: dba-readonly
                namespace: db-postgres
                rules:
                - apiGroups: [""]
                resources: ["pods", "services", "events", "persistentvolumeclaims", "configmaps"]
                verbs: ["get", "list", "watch"]
                - apiGroups: ["postgresql.cnpg.io"]
                resources: ["clusters", "backups", "scheduledbackups"]
                verbs: ["get", "list", "watch"]
                ---
                apiVersion: rbac.authorization.k8s.io/v1
                kind: RoleBinding
                metadata:
                name: dba-readonly-binding
                namespace: db-postgres
                subjects:
                - kind: Group
                name: dba-team
                apiGroup: rbac.authorization.k8s.io
                roleRef:
                kind: Role
                name: dba-readonly
                apiGroup: rbac.authorization.k8s.io

Point critique : pour les bases de données, reclaimPolicy: Retain est souvent préférable à Delete. La suppression d’un cluster ne doit pas détruire les volumes sans décision explicite.

4. GitOps — ArgoCD / Flux pour les bases de données

En GitOps, Git devient la source de vérité. Les opérateurs Kubernetes réconcilient l’état désiré depuis les manifests. Cela apporte auditabilité, rollback, revue de code, séparation des environnements et contrôle du drift.

Principe de flux

Pull request

Review manifests

→

Merge Git

Desired state

→

ArgoCD / Flux

Sync controller

→

Operator

Database lifecycle

→

Cluster DB

Pods, PVC, backups

Arborescence GitOps recommandée

clusters/
                production/
                kustomization.yaml
                apps.yaml
                policies.yaml
                staging/
                kustomization.yaml
                operators/
                cloudnative-pg/
                base/
                overlays/production/
                eck/
                base/
                overlays/production/
                databases/
                postgres/payments/
                base/cluster.yaml
                base/scheduled-backup.yaml
                overlays/production/kustomization.yaml
                search/logs/
                base/elasticsearch.yaml
                base/kibana.yaml
                mongodb/customer360/
                base/replica-set.yaml
                policies/
                rbac/
                network/
                quotas/
                storage/

Exemple ArgoCD Application

apiVersion: argoproj.io/v1alpha1
                kind: Application
                metadata:
                name: postgres-payments
                namespace: argocd
                spec:
                project: databases
                source:
                repoURL: https://git.example.com/platform/db-k8s-platform.git
                targetRevision: main
                path: databases/postgres/payments/overlays/production
                destination:
                server: https://kubernetes.default.svc
                namespace: db-postgres
                syncPolicy:
                automated:
                prune: false
                selfHeal: true
                syncOptions:
                - CreateNamespace=false
                - ApplyOutOfSyncOnly=true

Exemple Flux HelmRelease

apiVersion: source.toolkit.fluxcd.io/v1
                kind: HelmRepository
                metadata:
                name: cnpg
                namespace: flux-system
                spec:
                interval: 1h
                url: https://cloudnative-pg.github.io/charts
                ---
                apiVersion: helm.toolkit.fluxcd.io/v2
                kind: HelmRelease
                metadata:
                name: cloudnative-pg
                namespace: db-operators
                spec:
                interval: 30m
                chart:
                spec:
                chart: cloudnative-pg
                version: "0.x.x"
                sourceRef:
                kind: HelmRepository
                name: cnpg
                namespace: flux-system
                install:
                crds: Create
                upgrade:
                crds: CreateReplace

Règles GitOps à défendre

Règle	Pourquoi	Exception possible
Pas de modification manuelle en production	Évite le drift invisible.	Incident critique avec ticket et réconciliation ensuite.
Un changement DB = une pull request	Trace, review, rollback.	Rotation urgente de secret via processus sécurité.
Les CRD sont gérées séparément	Un upgrade CRD peut casser des ressources existantes.	Lab ou staging uniquement.
Prune contrôlé	Supprimer un manifest peut supprimer des ressources sensibles.	Namespaces non stateful ou composants stateless.

Attention : activer prune: true sans stratégie claire sur des ressources stateful peut provoquer la suppression d’objets critiques. Même si les PVC sont en Retain, l’incident opérationnel peut être sévère.

5. PostgreSQL via CloudNativePG

PostgreSQL avec CloudNativePG est probablement le cœur de cette mission. Le sujet ne se limite pas à créer un cluster : il faut maîtriser réplication, failover, backups physiques, WAL archiving, PITR, switchover, services read/write, rolling upgrade et restauration testée.

Topologie cible

App write

Service rw

→

Primary

PostgreSQL instance 1 + PVC

↔

Replica 1

Streaming replication + PVC

↔

Replica 2

Read-only service + PVC

→

Object store

Base backup + WAL

Manifeste CNPG — cluster 3 instances

apiVersion: postgresql.cnpg.io/v1
                kind: Cluster
                metadata:
                name: pg-payments
                namespace: db-postgres
                spec:
                instances: 3
                imageName: ghcr.io/cloudnative-pg/postgresql:16

                primaryUpdateStrategy: unsupervised

                postgresql:
                parameters:
                max_connections: "300"
                shared_buffers: 512MB
                wal_compression: "on"
                log_min_duration_statement: "500"

                bootstrap:
                initdb:
                database: payments
                owner: payments_app
                secret:
                name: pg-payments-app-secret

                storage:
                size: 50Gi
                storageClass: db-fast-retain

                resources:
                requests:
                cpu: "1"
                memory: 2Gi
                limits:
                cpu: "2"
                memory: 4Gi

                monitoring:
                enablePodMonitor: true

Secret applicatif

apiVersion: v1
                kind: Secret
                metadata:
                name: pg-payments-app-secret
                namespace: db-postgres
                type: kubernetes.io/basic-auth
                stringData:
                username: payments_app
                password: change-me-in-vault

ScheduledBackup CNPG

apiVersion: postgresql.cnpg.io/v1
                kind: ScheduledBackup
                metadata:
                name: pg-payments-nightly
                namespace: db-postgres
                spec:
                schedule: "0 0 2 * * *"
                backupOwnerReference: self
                cluster:
                name: pg-payments
                method: barmanObjectStore

Note version : CNPG a historiquement supporté Barman object store dans le manifeste du cluster. Les versions récentes introduisent le plugin Barman Cloud. En entretien, il faut dire : “je vérifie la matrice operator/version/plugin avant d’écrire le manifeste final”.

Tests indispensables

Test	Commande / action	Validation attendue
État cluster	`kubectl get cluster -n db-postgres`	3 instances, primary identifié.
Failover	Supprimer le pod primary.	Nouveau primary élu, service rw toujours disponible.
Backup	Créer un Backup ou attendre ScheduledBackup.	Backup présent dans object storage.
PITR	Restaurer à un timestamp précis.	Données restaurées avant l’erreur simulée.
Upgrade mineur	Changer image PostgreSQL patch/minor compatible.	Rolling update sans perte de service majeure.

Runbook express : perte du primary

Identifier le primary courant avec kubectl get pods -n db-postgres -L role.
Supprimer le pod primary pour simuler une panne.
Observer les events du cluster CNPG.
Valider que le service read-write pointe vers le nouveau primary.
Mesurer le délai d’indisponibilité applicative.
Vérifier la réplication des anciennes replicas.

#!/usr/bin/env bash
                set -euo pipefail

                kubectl get pods -n db-postgres
                kubectl get cluster pg-payments -n db-postgres

                PRIMARY_POD=$(kubectl get pods -n db-postgres -l cnpg.io/cluster=pg-payments,role=primary -o jsonpath='{.items[0].metadata.name}')
                echo "Primary pod: ${PRIMARY_POD}"

                kubectl delete pod "${PRIMARY_POD}" -n db-postgres
                kubectl wait --for=condition=Ready cluster/pg-payments -n db-postgres --timeout=300s
                kubectl get pods -n db-postgres

Réponse entretien : “Pour PostgreSQL, je considère qu’un backup n’existe pas tant que je n’ai pas testé une restauration complète et, si possible, un PITR sur un cluster séparé.”

6. Elasticsearch / OpenSearch — ECK, index lifecycle et snapshots

La fiche mélange “Elasticsearch / OpenSearch via ECK”. Il faut être précis : ECK est l’opérateur Elastic pour Elasticsearch et son écosystème. OpenSearch a son propre opérateur ou ses propres charts. Cette nuance est importante en entretien car elle montre que tu ne confonds pas les deux distributions.

Elasticsearch avec ECK

NodeSets, PVC, Kibana, TLS, snapshots, SLM, ILM, rolling upgrades.

OpenSearch avec OpenSearch Operator

Node pools, ISM, snapshots, Dashboards, security plugin, rolling operations.

Manifeste ECK multi-node

apiVersion: elasticsearch.k8s.elastic.co/v1
                kind: Elasticsearch
                metadata:
                name: es-logs
                namespace: db-search
                spec:
                version: 8.15.0
                nodeSets:
                - name: masters
                count: 3
                config:
                node.roles: ["master"]
                volumeClaimTemplates:
                - metadata:
                name: elasticsearch-data
                spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: db-fast-retain
                resources:
                requests:
                storage: 20Gi
                - name: data-hot
                count: 3
                config:
                node.roles: ["data_hot", "data_content", "ingest"]
                volumeClaimTemplates:
                - metadata:
                name: elasticsearch-data
                spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: db-fast-retain
                resources:
                requests:
                storage: 100Gi
                http:
                tls:
                selfSignedCertificate:
                disabled: false

ILM policy exemple

{
                "policy": {
                "phases": {
                "hot": {
                "actions": {
                "rollover": {
                "max_age": "7d",
                "max_primary_shard_size": "40gb"
                }
                }
                },
                "warm": {
                "min_age": "14d",
                "actions": {
                "forcemerge": { "max_num_segments": 1 }
                }
                },
                "delete": {
                "min_age": "90d",
                "actions": { "delete": {} }
                }
                }
                }
                }

Snapshot repository S3/MinIO

{
                "type": "s3",
                "settings": {
                "bucket": "es-snapshots",
                "client": "default",
                "base_path": "production/es-logs",
                "compress": true
                }
                }

OpenSearch — ISM policy exemple

{
                "policy": {
                "description": "Hot to delete lifecycle for logs",
                "default_state": "hot",
                "states": [
                {
                "name": "hot",
                "actions": [
                { "rollover": { "min_index_age": "7d", "min_size": "40gb" } }
                ],
                "transitions": [
                { "state_name": "delete", "conditions": { "min_index_age": "90d" } }
                ]
                },
                {
                "name": "delete",
                "actions": [ { "delete": {} } ],
                "transitions": []
                }
                ]
                }
                }

Diagnostics essentiels

Signal	Diagnostic	Action DBA/SRE
Cluster red	Shards primaires indisponibles.	Identifier index, node, allocation explain, restore si nécessaire.
Cluster yellow	Replicas non allouées.	Vérifier capacité, anti-affinity, disk watermarks.
Heap JVM élevée	Pression mémoire ou requêtes coûteuses.	Vérifier queries, shards, mappings, fielddata.
Disk watermark	Disques trop pleins.	Rollover, suppression, ajout capacité, relocation.
Snapshot failed	Risque PRA immédiat.	Corriger repository, droits, réseau, espace, relancer test restore.

Question entretien possible : “Pourquoi trop de shards est dangereux ?” Réponse : surcharge cluster state, heap, allocation, recovery plus lente, overhead fichier et latence. Le design d’index est une décision d’architecture.

7. MariaDB — opérateur, Helm, Galera et PVC

MariaDB dans Kubernetes peut être déployé via opérateur ou via Helm. Le point le plus important est la compréhension du stockage persistant, du quorum Galera, des synchronisations SST/IST, des backups et du risque multi-primary.

Topologies MariaDB

Topologie	Usage	Risque principal
Single primary + replicas	Lecture scalable, modèle classique.	Failover et réplication à superviser.
Galera 3 nœuds	HA synchrone multi-primary.	Quorum, conflits d’écriture, latence réseau.
Galera + MaxScale	Routage, read/write split, HA plus propre.	Composant supplémentaire à exploiter.
Helm chart simple	Lab ou environnement non critique.	Moins de logique opérateur.

Valeurs Helm Galera simplifiées

replicaCount: 3

                rootUser:
                password: change-me-in-vault

                persistence:
                enabled: true
                storageClass: db-fast-retain
                size: 50Gi

                resources:
                requests:
                cpu: 1000m
                memory: 2Gi
                limits:
                cpu: 2000m
                memory: 4Gi

                podAntiAffinityPreset: hard

                mariadbConfiguration: |
                [mysqld]
                innodb_buffer_pool_size=1G
                max_connections=300
                slow_query_log=1
                long_query_time=1
                wsrep_provider_options="gcache.size=2G"

Contrôles Galera à connaître

SHOW STATUS LIKE 'wsrep_cluster_size';
                SHOW STATUS LIKE 'wsrep_cluster_status';
                SHOW STATUS LIKE 'wsrep_local_state_comment';
                SHOW STATUS LIKE 'wsrep_ready';
                SHOW STATUS LIKE 'wsrep_connected';
                SHOW STATUS LIKE 'wsrep_flow_control_paused';

Lecture opérationnelle

Variable	Valeur saine	Interprétation
`wsrep_cluster_size`	3	Les 3 nœuds sont membres du cluster.
`wsrep_cluster_status`	Primary	Le cluster a le quorum.
`wsrep_ready`	ON	Le nœud accepte les requêtes.
`wsrep_local_state_comment`	Synced	Le nœud est synchronisé.
`wsrep_flow_control_paused`	Bas	Un niveau élevé signale une pression cluster.

Plan de test MariaDB

Déployer le cluster 3 nœuds.
Créer une base et une table de test.
Écrire sur le point d’entrée applicatif.
Supprimer un pod MariaDB.
Vérifier le retour à wsrep_cluster_size = 3.
Provoquer un backup logique ou physique.
Restaurer dans un namespace séparé.

Important : Galera permet le multi-primary, mais ce n’est pas une invitation à écrire n’importe où. Beaucoup d’architectures gardent un writer contrôlé pour limiter les conflits et simplifier l’exploitation.

8. MongoDB — replica sets, sharding, secrets et opérateurs

MongoDB dans Kubernetes est généralement piloté via un opérateur. Il faut connaître les différences entre Community, Enterprise et Percona Operator, car les fonctions de backup, Ops Manager, monitoring ou sharding varient selon le choix.

Choix opérateur

Option	Usage	À vérifier
MongoDB Community Operator	Replica sets Community.	Fonctions avancées backup/ops limitées.
MongoDB Enterprise Operator	Entreprise, Ops Manager, Cloud Manager.	Licences, backup, TLS, sharding.
Percona Operator for MongoDB	Alternative open source orientée production.	Compatibilité version, backup, PITR.

Architecture replica set

Application

Connection string replica set

→

Primary

Writes + oplog

↔

Secondary 1

Replication + reads optional

↔

Secondary 2

Election candidate

Exemple conceptuel MongoDBCommunity

apiVersion: mongodbcommunity.mongodb.com/v1
                kind: MongoDBCommunity
                metadata:
                name: customer360
                namespace: db-mongodb
                spec:
                members: 3
                type: ReplicaSet
                version: "7.0.0"
                security:
                authentication:
                modes: ["SCRAM"]
                users:
                - name: app_user
                db: admin
                passwordSecretRef:
                name: customer360-app-password
                roles:
                - name: readWrite
                db: customer360
                scramCredentialsSecretName: customer360-app-scram
                statefulSet:
                spec:
                volumeClaimTemplates:
                - metadata:
                name: data-volume
                spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: db-fast-retain
                resources:
                requests:
                storage: 50Gi

Sharding — composants à expliquer

Composant	Rôle	Point d’attention
Shard replica set	Stocke une partie des données.	Chaque shard doit être HA.
Config servers	Stockent la metadata du cluster sharded.	Critiques, doivent être replica set.
mongos	Routeur de requêtes.	Point d’entrée applicatif scalable.
Shard key	Détermine la distribution.	Mauvais choix = hotspot ou déséquilibre.
Balancer	Déplace les chunks.	Surveiller impact performance.

Commandes MongoDB utiles

rs.status()
                rs.printReplicationInfo()
                rs.printSecondaryReplicationInfo()
                db.adminCommand({ replSetGetStatus: 1 })
                db.serverStatus().connections
                db.serverStatus().wiredTiger.cache
                sh.status()
                db.adminCommand({ balancerStatus: 1 })

Plan de test MongoDB

Déployer un replica set 3 membres.
Créer un user applicatif via Secret.
Tester l’élection en supprimant le primary.
Contrôler la réplication et le retard secondaire.
Activer TLS si l’opérateur et l’environnement le permettent.
Tester backup et restore dans un namespace séparé.
Déployer un sharded cluster en lab si la fiche insiste sur le sharding.

Question entretien possible : “Quel est le risque d’une mauvaise shard key ?” Réponse : mauvaise distribution, hotspot d’écriture, chunks déséquilibrés, migrations coûteuses et performance imprévisible.

9. Sécurité des données — secrets, Vault, TLS, chiffrement

La sécurité est transverse : secrets Kubernetes, Vault, External Secrets, TLS client/serveur, chiffrement au repos, chiffrement en transit, RBAC, NetworkPolicy, audit logs et rotation des credentials.

Les 4 couches de sécurité

Couche	Objectif	Exemples
Kubernetes API	Protéger les Secrets et les actions API.	RBAC, audit, encryption config, least privilege.
Storage	Chiffrer les volumes et snapshots.	StorageClass encrypted, KMS, CSI cloud.
Database	Contrôler utilisateurs, rôles, audit et TLS.	pg_hba, roles, SCRAM, x509, audit logs.
Network	Limiter les flux clients et inter-nœuds.	NetworkPolicy, mTLS, namespace isolation.

ExternalSecret avec Vault

apiVersion: external-secrets.io/v1beta1
                kind: SecretStore
                metadata:
                name: vault-db-store
                namespace: db-postgres
                spec:
                provider:
                vault:
                server: https://vault.security.svc:8200
                path: secret
                version: v2
                auth:
                kubernetes:
                mountPath: kubernetes
                role: db-postgres-reader
                serviceAccountRef:
                name: external-secrets
                ---
                apiVersion: external-secrets.io/v1beta1
                kind: ExternalSecret
                metadata:
                name: pg-payments-app-secret
                namespace: db-postgres
                spec:
                refreshInterval: 1h
                secretStoreRef:
                name: vault-db-store
                kind: SecretStore
                target:
                name: pg-payments-app-secret
                creationPolicy: Owner
                data:
                - secretKey: username
                remoteRef:
                key: postgres/payments/app
                property: username
                - secretKey: password
                remoteRef:
                key: postgres/payments/app
                property: password

NetworkPolicy restrictive

apiVersion: networking.k8s.io/v1
                kind: NetworkPolicy
                metadata:
                name: allow-app-to-postgres
                namespace: db-postgres
                spec:
                podSelector:
                matchLabels:
                cnpg.io/cluster: pg-payments
                policyTypes:
                - Ingress
                ingress:
                - from:
                - namespaceSelector:
                matchLabels:
                platform.ideo-lab.com/domain: application
                ports:
                - protocol: TCP
                port: 5432

Checklist sécurité

Activer le chiffrement des Secrets au niveau API server/etcd.
Utiliser Vault, External Secrets ou Secret Store CSI Driver pour les secrets sensibles.
Limiter les droits get/list/watch secrets aux seuls composants nécessaires.
Chiffrer les volumes via StorageClass ou fournisseur cloud.
Activer TLS côté client et, si possible, entre nœuds du cluster DB.
Utiliser NetworkPolicy pour limiter les flux aux namespaces applicatifs autorisés.
Préparer une procédure de rotation credentials et certificats.
Ne jamais afficher de mot de passe dans Git, logs, Helm values ou dashboards.

Erreur classique : croire qu’un Kubernetes Secret est automatiquement chiffré de bout en bout. Il faut vérifier l’encryption at rest, les droits RBAC, les logs applicatifs et la manière dont le secret est monté dans le pod.

10. Observabilité — métriques, logs, alertes et dashboards

L’observabilité d’une plateforme DBA Kubernetes doit couvrir à la fois Kubernetes, les opérateurs, le stockage, les moteurs de base, les backups et les restaurations. Une base “verte” côté pod peut être dégradée côté moteur.

Stack recommandée

Prometheus

Collecte métriques Kubernetes, DB, opérateurs et storage.

Grafana

Dashboards DBA : lag, WAL, heap, disque, connexions, backups.

Alertmanager

Routage alertes vers mail, Slack, Teams, PagerDuty.

Loki / OpenSearch

Logs opérateurs, pods DB, events Kubernetes et traces incident.

Exporters

postgres-exporter, mysqld-exporter, mongodb-exporter, elastic metrics.

Dashboards opérateurs

CNPG, ECK, MongoDB, MariaDB, CSI driver, object storage.

Alertes prioritaires par moteur

Moteur	Alertes critiques	Pourquoi
PostgreSQL	Primary down, replica lag, WAL archive failed, backup failed, disk > 80%.	Risque HA, perte RPO, saturation WAL.
Elasticsearch/OpenSearch	Cluster red, unassigned shards, disk watermark, heap > 75%, snapshot failed.	Risque perte index, indisponibilité recherche.
MariaDB/Galera	Cluster size incorrect, wsrep not primary, SST long, slow queries, backup failed.	Risque quorum et cohérence.
MongoDB	No primary, replication lag, oplog window small, cache pressure, backup failed.	Risque indisponibilité et perte capacité PITR.
Kubernetes	PVC nearly full, pod crashloop, node pressure, CSI errors, quota exceeded.	Risque plateforme sous-jacent.

PrometheusRule PostgreSQL exemple

apiVersion: monitoring.coreos.com/v1
                kind: PrometheusRule
                metadata:
                name: postgres-critical-alerts
                namespace: observability
                spec:
                groups:
                - name: postgres.rules
                rules:
                - alert: PostgresReplicationLagHigh
                expr: cnpg_pg_replication_lag_seconds > 60
                for: 5m
                labels:
                severity: warning
                annotations:
                summary: PostgreSQL replication lag is high
                description: Replica lag is above 60 seconds for more than 5 minutes.
                - alert: PostgresBackupFailed
                expr: cnpg_collector_last_available_backup_timestamp == 0
                for: 10m
                labels:
                severity: critical
                annotations:
                summary: PostgreSQL backup is not available
                description: No valid backup timestamp was reported by the cluster.

Dashboard minimal DBA

Panneau	Mesure	Décision possible
Disponibilité	Pods ready, primary, replicas, cluster health.	Incident ou dégradation.
Stockage	PVC usage, IOPS, latency, disk pressure.	Extension volume ou purge.
Backup	Dernier backup, durée, taille, erreurs.	Blocage release si backup absent.
Performance	Connexions, requêtes lentes, heap/cache, locks.	Tuning ou investigation applicative.
Réplication	Lag, oplog, WAL, cluster size.	Risque RPO ou failover.

Bonne pratique : associer chaque alerte critique à un runbook. Une alerte sans procédure crée du bruit, pas de la résilience.

11. Runbooks — procédures d’exploitation à préparer

Les runbooks sont une preuve de maturité. Ils montrent que tu ne te contentes pas de déployer des bases, mais que tu sais les opérer, diagnostiquer, restaurer et sécuriser sous pression.

Structure standard d’un runbook

# Runbook title

                ## Scope
                Database engine, namespace, environment, owner.

                ## Symptoms
                Observable signals, alerts, logs, metrics.

                ## Impact
                Application impact, data risk, RPO/RTO risk.

                ## Immediate checks
                Commands and dashboards to open first.

                ## Decision matrix
                Go/no-go conditions and escalation path.

                ## Procedure
                Step-by-step remediation.

                ## Rollback
                How to return to the previous safe state.

                ## Validation
                Technical and business checks.

                ## Post-incident
                Evidence, timeline, root cause and preventive actions.

Runbooks minimum à écrire

Runbook	Objectif	Test associé
PostgreSQL failover	Perte primary CNPG.	Suppression pod primary.
PostgreSQL PITR	Restauration à un timestamp précis.	Créer erreur, restaurer avant erreur.
Elasticsearch snapshot restore	Restaurer un index supprimé.	Delete index puis restore snapshot.
MariaDB Galera recovery	Récupérer quorum ou nœud désynchronisé.	Perte d’un pod, resync IST/SST.
MongoDB election	Gérer perte du primary.	Suppression primary et validation election.
PVC full	Saturation disque DB.	Remplissage contrôlé en lab.
Secret rotation	Rotation mot de passe/certificat.	Changer secret et valider app.
Operator upgrade	Upgrade opérateur sans rupture.	Staging puis production.

Exemple : runbook PVC presque plein

Identifier le PVC, le pod et le moteur impacté.
Vérifier si la StorageClass autorise l’expansion.
Vérifier si le moteur supporte l’extension à chaud.
Contrôler la cause : WAL, index, snapshots internes, logs, données applicatives.
Étendre le PVC ou purger selon procédure moteur.
Valider métriques après action.
Créer une action préventive : seuil alerting, lifecycle, purge, capacité.

apiVersion: v1
                kind: PersistentVolumeClaim
                metadata:
                name: pg-payments-1
                namespace: db-postgres
                spec:
                resources:
                requests:
                storage: 100Gi

Règle : un runbook de restauration doit être testé avant l’incident. Le jour de la panne, on exécute une procédure validée, on n’improvise pas une stratégie de récupération.

12. Montées de version — moteurs, opérateurs, CRD et Kubernetes

Les upgrades sont un sujet central. Il faut séparer l’upgrade de l’opérateur, des CRD, du moteur de base, des images conteneur, du chart Helm, du CSI driver et du cluster Kubernetes lui-même.

Ce qu’il ne faut jamais mélanger

Élément	Exemple	Risque
Operator	CNPG 1.x, ECK 2.x.	Changement de logique de réconciliation.
CRD	Nouvelle version d’API custom resource.	Incompatibilité manifest existant.
Moteur DB	PostgreSQL 16.x, ES 8.x, MongoDB 7.x.	Migration de format, compatibilité client.
Chart Helm	Templates et values.	Ressources renommées ou options supprimées.
Storage/CSI	Driver volume, snapshot controller.	Impact PVC/snapshot/restore.
Kubernetes	1.29 vers 1.30, etc.	Compatibilité API, PodSecurity, scheduler.

Procédure d’upgrade saine

Lire release notes opérateur, moteur, chart et Kubernetes.
Vérifier matrice de compatibilité.
Valider que les backups récents sont restaurables.
Rejouer l’upgrade en lab puis staging.
Upgrader l’opérateur seul.
Observer la réconciliation sans changement moteur.
Upgrader le moteur en suivant la procédure officielle.
Contrôler métriques, logs, performances, backup post-upgrade.
Documenter rollback et points de non-retour.

Matrice go / no-go

Condition	Go	No-go
Backup	Dernier backup validé et restore testé.	Backup absent ou restore jamais testé.
Compatibilité	Matrice confirmée.	Version opérateur/moteur incertaine.
Staging	Upgrade rejoué avec succès.	Pas de staging iso-prod.
Monitoring	Dashboards et alertes actifs.	Pas de visibilité pendant opération.
Rollback	Plan écrit et validé.	Rollback impossible ou non compris.

Exemple de checklist release

# Upgrade checklist

                - [ ] Target operator version identified
                - [ ] Target engine version identified
                - [ ] CRD changes reviewed
                - [ ] Backup completed
                - [ ] Restore test completed
                - [ ] Staging upgrade completed
                - [ ] Application smoke tests completed
                - [ ] Metrics baseline captured
                - [ ] Rollback procedure reviewed
                - [ ] Change window approved
                - [ ] Post-upgrade backup scheduled

Phrase entretien : “Je n’upgrade jamais opérateur, CRD, moteur et Kubernetes dans la même fenêtre. Je découpe, je teste, je mesure, puis je documente le rollback.”

13. Questions à poser au recruteur ou au client

Ces questions montrent une compréhension production. Elles permettent aussi d’identifier si le poste est plutôt DBA, SRE, Platform Engineer, DevOps ou un mélange des quatre.

Questions infrastructure

Question	Pourquoi la poser
Kubernetes est-il on-prem, EKS, AKS, GKE ou OpenShift ?	Impact storage, IAM, réseau, upgrades, sécurité.
Quel CSI driver et quelles StorageClasses sont utilisés ?	Détermine performance, snapshots, expansion, chiffrement.
Les VolumeSnapshots sont-ils supportés et testés ?	Crucial pour PRA et clones rapides.
Les bases sont-elles multi-AZ ou mono-cluster ?	Impact HA réel et tolérance panne zone.
Existe-t-il un staging iso-prod ?	Indispensable pour upgrades et restore tests.

Questions DBA/PRA

Question	Lecture attendue
Quels sont les RPO/RTO par moteur ?	Sans RPO/RTO, la stratégie backup est floue.
Les restores sont-ils testés régulièrement ?	Un backup non restauré n’est pas une garantie.
Qui est owner des index Elasticsearch/OpenSearch ?	DBA, dev, data, plateforme ou équipe logs.
MongoDB utilise-t-il Community, Enterprise ou Percona ?	Change la stratégie backup/opérateur.
MariaDB est-il Galera, primary/replica ou MaxScale ?	Change complètement le modèle d’exploitation.

Questions sécurité/GitOps

Question	Pourquoi
GitOps est-il ArgoCD ou Flux ?	Différence de modèle, Helm, sync, drift.
Qui peut merger les manifests database ?	Gouvernance des changements production.
Vault, External Secrets ou K8s Secrets simples ?	Risque sécurité et rotation.
Les volumes sont-ils chiffrés par défaut ?	Compliance et données sensibles.
Les accès DBA sont-ils namespace-only ou cluster-wide ?	Responsabilité et limites d’intervention.

Question très utile : “Quelle est la dernière restauration réellement testée en staging ou production-like ?” Cette question montre immédiatement une maturité PRA.

14. Priorités de préparation

Pour être prêt rapidement, il faut prioriser. Tu n’as pas besoin de maîtriser tout au même niveau dès le premier jour. En revanche, tu dois être solide sur le socle Kubernetes stateful, PostgreSQL/CNPG, GitOps, sécurité et restauration.

Plan 10 jours de préparation intensive

Jour	Objectif	Livrable
1	Installer lab Kubernetes + namespaces + storage.	Cluster prêt, StorageClass, quotas.
2	Installer ArgoCD ou Flux.	Repo GitOps synchronisé.
3	Installer CNPG et PostgreSQL 3 nœuds.	Cluster Postgres fonctionnel.
4	Backups CNPG vers MinIO et restore.	Runbook backup/restore.
5	Failover CNPG et PITR.	Preuves de tests et logs.
6	ECK Elasticsearch + ILM + snapshots.	Cluster search + restore index.
7	MariaDB/Galera.	Contrôles wsrep + test perte pod.
8	MongoDB replica set.	Élection primary + secrets.
9	Sécurité : Vault/External Secrets/TLS/RBAC.	Manifests sécurité.
10	Observabilité + runbooks + simulation entretien.	Dashboards et réponses prêtes.

Compétences à classer

Priorité absolue

StatefulSet, PVC, StorageClass, CNPG, backup/restore, RBAC, GitOps.

Priorité forte

ECK, ILM, snapshots, MariaDB Galera, MongoDB replica set, Prometheus.

Priorité complémentaire

Sharding MongoDB, OpenSearch Operator avancé, Vault avancé, multi-cluster.

Tableau de maturité personnelle

Domaine	Niveau attendu	Preuve concrète
Kubernetes storage	Très bon	Créer PVC, StorageClass, snapshot, extension volume.
CNPG	Très bon	Failover, backup, restore, PITR.
GitOps	Bon	ArgoCD/Flux synchronise un cluster DB.
Elasticsearch/OpenSearch	Bon	Cluster health, ILM/ISM, snapshot restore.
MariaDB	Intermédiaire+	Galera status, quorum, backup/restore.
MongoDB	Intermédiaire+	Replica set, election, lag, secrets.
Sécurité	Bon	Vault/ExternalSecret, RBAC, NetworkPolicy, TLS.

Stratégie réaliste : sois très fort sur PostgreSQL/CNPG et Kubernetes stateful. Pour MariaDB/MongoDB/Search, montre une compréhension opérationnelle solide et une capacité à lire la documentation opérateur/version.

15. Préparation entretien — discours, questions et réponses

L’objectif en entretien est de montrer que tu as une vision production, pas seulement une connaissance des commandes. Il faut parler risque, RPO/RTO, restore, sécurité, storage, GitOps et procédures.

Pitch de 60 secondes

Je vois ce poste comme une fonction DBA Platform. Mon rôle n'est pas seulement
                installer un moteur de base de données, mais garantir son cycle de vie complet
                dans Kubernetes : provisioning déclaratif, stockage persistant, haute disponibilité,
                backup, restauration testée, sécurité, observabilité, GitOps et upgrades contrôlés.

                Je sépare toujours les sujets : opérateur, CRD, moteur, storage, secrets et cluster
                Kubernetes. Et je considère qu'un backup n'existe pas tant qu'une restauration n'a
                pas été testée dans un environnement séparé.

Questions classiques et réponses

Question	Réponse courte attendue
Pourquoi utiliser un opérateur DB ?	Pour automatiser le cycle de vie : provisioning, failover, backup, upgrade, monitoring et réconciliation.
Pourquoi un StatefulSet ?	Identité stable des pods et association durable pod/PVC.
Différence PVC et backup ?	Un PVC stocke les données courantes ; un backup est une copie récupérable, idéalement testée et indépendante.
Que fais-tu avant un upgrade ?	Release notes, compatibilité, backup, restore staging, plan rollback, monitoring.
Comment sécuriser les secrets ?	RBAC strict, encryption at rest, Vault/External Secrets, rotation, pas de secrets en Git.
Comment valider un PRA ?	Restaurer dans un environnement séparé, mesurer RTO/RPO et documenter la procédure.
ECK pour OpenSearch ?	ECK est pour Elastic Stack ; OpenSearch utilise plutôt OpenSearch Operator ou Helm dédié.

Exemples de réponses fortes

Sur les backups

“Je distingue snapshot volume, backup physique, backup logique et PITR. Le choix dépend du RPO/RTO et du moteur.”

Sur GitOps

“Git est la source de vérité. En production, je limite les modifications manuelles et je réconcilie toute correction d’urgence.”

Sur le stockage

“Je vérifie StorageClass, reclaimPolicy, expansion, snapshots, encryption, latency et IOPS avant de parler production.”

Sur les upgrades

“Je n’upgrade jamais tout en même temps. Je découpe opérateur, CRD, moteur, storage et Kubernetes.”

Posture : parle comme quelqu’un qui protège la donnée. Le recruteur doit sentir que tu penses incident, rollback, preuve, restauration et responsabilité production.

16. Synthèse — plateforme cible et livrables

La préparation idéale consiste à construire une mini plateforme DBA Kubernetes Native, documentée, testée et présentable. Elle doit prouver que tu sais déployer, sauvegarder, restaurer, sécuriser, surveiller et upgrader des bases dans Kubernetes.

Plateforme cible

Bloc	Livrable	Statut attendu
Kubernetes	Namespaces, RBAC, quotas, StorageClasses, snapshots.	Obligatoire
GitOps	Repo ArgoCD ou Flux synchronisé.	Obligatoire
PostgreSQL	CNPG 3 instances + backup + restore + failover.	Obligatoire
Search	ECK Elasticsearch + ILM + snapshot restore.	Fortement conseillé
OpenSearch	Nuance opérateur OpenSearch + ISM.	À savoir expliquer
MariaDB	Galera 3 nœuds + contrôles wsrep.	Conseillé
MongoDB	Replica set + election + secrets.	Conseillé
Sécurité	Vault/External Secrets, TLS, RBAC, NetworkPolicy.	Obligatoire
Observabilité	Prometheus, Grafana, Alertmanager, logs.	Obligatoire
Runbooks	Failover, restore, PITR, upgrade, PVC full.	Obligatoire

Checklist finale avant entretien

Je sais expliquer la différence entre opérateur, CRD, StatefulSet, PVC et StorageClass.
Je sais déployer un cluster PostgreSQL CNPG 3 instances.
Je sais expliquer failover, switchover, backup physique, WAL et PITR.
Je sais expliquer ECK, ILM, snapshot repository et cluster health.
Je sais expliquer la nuance entre Elasticsearch/ECK et OpenSearch Operator.
Je sais diagnostiquer Galera avec les variables wsrep.
Je sais expliquer MongoDB replica set, election, oplog et sharding.
Je sais défendre une stratégie de secrets avec Vault/External Secrets.
Je sais parler RPO/RTO et restauration testée.
Je sais expliquer pourquoi un upgrade doit être découpé.
Je dispose de runbooks écrits et de manifests exemples.

Conclusion opérationnelle

Le poste vise un profil DBA capable de travailler avec les équipes plateforme. Le cœur de la valeur n’est pas seulement la connaissance des moteurs, mais la capacité à garantir la donnée dans un environnement Kubernetes déclaratif, automatisé, sécurisé, observable et restaurable.

Dernière phrase à retenir : “Mon objectif n’est pas de faire tourner des pods de base de données. Mon objectif est de garantir que la donnée est disponible, cohérente, sauvegardée, restaurable, sécurisée et opérable.”

Ce guide est imprimable. Le bouton “Imprimer” affiche tous les onglets dans l’ordre pour produire une documentation complète.

Guide complet — Exploitation et administration DBA Kubernetes Native