Déployer Pulp sur Kubernetes avec l'operator

Ce guide déploie Pulp sur Kubernetes avec l'operator officiel : on installe le contrôleur avec Helm, puis on décrit l'instance dans une custom resource Pulp, et l'operator provisionne toute la pile (API, contenu, workers, PostgreSQL, Redis, reverse proxy). Public visé : équipes plateforme qui veulent un gestionnaire d'artefacts déclaratif et scalable. Prérequis : un cluster Kubernetes, kubectl et helm. Vous verrez l'installation en épinglant les bonnes versions, la ressource Pulp, l'accès à l'instance, et le réglage de version PostgreSQL qui conditionne aussi bien le démarrage que la sauvegarde.

Sur Kubernetes, on n'installe pas Pulp à la main : on installe le Pulp Operator, un contrôleur qui surveille des ressources Pulp et réconcilie le cluster pour les faire correspondre. C'est le modèle operator, déclaratif et auto-réparateur.

Ce que vous allez apprendre

• Installer le Pulp Operator avec Helm, en épinglant les bonnes versions.
• Décrire une instance avec une custom resource Pulp.
• Accéder à l'API et récupérer le mot de passe admin.
• Choisir la version PostgreSQL compatible avec la sauvegarde.

Prérequis

• Un cluster Kubernetes fonctionnel et kubectl configuré.
• Helm 3+ installé.
• Une StorageClass disponible. Sur un cluster mono-nœud (k3d, Minikube), la classe local-path en ReadWriteOnce suffit.

Stockage partagé en production multi-nœuds

Les composants api, content et worker partagent le même volume d'artefacts. Sur un cluster multi-nœuds, ces pods atterrissent sur des nœuds différents : un volume ReadWriteOnce ne suffit plus. Prévoyez un stockage ReadWriteMany (NFS, CephFS) ou, mieux, un stockage objet S3 configuré dans la ressource Pulp. Le ReadWriteOnce local n'est valable que pour un lab mono-nœud.

Installer l'operator

L'operator se déploie via son chart Helm. Il installe le contrôleur et les custom resource definitions (pulps, pulpbackups, pulprestores).

Un point mérite d'être posé d'emblée : le chart Helm publié épingle des versions par défaut anciennes (l'operator 1.3 et PostgreSQL 13). Or pulpcore exige PostgreSQL 14 ou plus. On installe donc en surchargeant l'image de l'operator (dernière version, ici 2.0) et l'image PostgreSQL (version 15).

1. Ajouter le dépôt Helm et créer un namespace :

   helm repo add pulp-operator https://github.com/pulp/pulp-k8s-resources/raw/main/helm-charts/ --force-update
   kubectl create namespace pulp

2. Installer l'operator en épinglant les versions :

   helm -n pulp install pulp pulp-operator/pulp-operator \
     --set image=quay.io/pulp/pulp-operator:v2.0.0 \
     --set operator.relatedImages.postgres=docker.io/library/postgres:15

3. Vérifier que le contrôleur tourne :

   kubectl -n pulp rollout status deploy/pulp-operator-controller-manager
   kubectl get crd | grep pulpproject

   Les trois CRD pulps, pulpbackups et pulprestores doivent apparaître : l'operator est prêt à recevoir une ressource Pulp.

Pourquoi PostgreSQL 15 précisément ?

Le choix de PostgreSQL 15 n'est pas arbitraire. L'outillage de sauvegarde de l'operator embarque un pg_dump d'une version figée (15 dans l'operator 2.0), et un pg_dump ne peut pas dumper un serveur d'une version supérieure. En choisissant 15 pour la base, vous satisfaisez à la fois pulpcore (qui veut 14 ou plus) et l'outil de sauvegarde. Une base en 16 démarrerait, mais PulpBackup échouerait.

Déployer Pulp avec une custom resource

L'instance se décrit dans un objet Pulp. L'operator lit cette ressource et crée les deployments, services, secrets et volumes correspondants.

pulp.yaml

apiVersion: repo-manager.pulpproject.org/v1
kind: Pulp
metadata:
  name: pulp
  namespace: pulp
spec:
  image_version: stable
  ingress_type: nodeport
  api:
    replicas: 1
  content:
    replicas: 1
  worker:
    replicas: 1
  file_storage_access_mode: "ReadWriteOnce"
  file_storage_size: "10Gi"
  file_storage_storage_class: local-path
  database:
    postgres_storage_class: local-path
    postgres_image: docker.io/library/postgres:15

kubectl apply -f pulp.yaml

Deux réglages de la partie database sont déterminants :

• postgres_storage_class est obligatoire. Sans lui, l'operator s'arrête avec l'erreur could not find any storage definition for Database.
• postgres_image: postgres:15 aligne la base sur la même version que l'outillage de sauvegarde (voir l'encadré ci-dessus). Gardez cette valeur cohérente avec le --set operator.relatedImages.postgres de l'installation.

Changer la version majeure de PostgreSQL

Si vous avez déjà déployé avec une autre version majeure, changer l'image ne suffit pas : les données existantes sont incompatibles entre versions majeures. Supprimez la ressource Pulp et la PVC de la base avant de redéployer, sinon PostgreSQL refuse de démarrer sur un répertoire initialisé par une autre version.

Suivre le déploiement et se connecter

L'operator provisionne les composants dans l'ordre : base, migrations, contenu, API, workers, reverse proxy. Le premier déploiement télécharge des images volumineuses, comptez quelques minutes.

1. Attendre que les pods soient prêts :

   kubectl -n pulp get pods -w

   Vous devez voir pulp-database-0, pulp-api, pulp-content et pulp-worker en Running, et les jobs migration et reset-admin-password en Completed.

2. Récupérer le mot de passe admin, généré automatiquement dans un secret :

   kubectl -n pulp get secret pulp-admin-password \
     -o jsonpath='{.data.password}' | base64 -d

3. Tester l'API. Le service pulp-web-svc (ici en NodePort) expose l'instance ; pour un test rapide, un port-forward suffit :

   kubectl -n pulp port-forward svc/pulp-api-svc 24817:24817 &
   curl -s http://localhost:24817/pulp/api/v3/status/ | head

   La réponse en 200 listant les composants (core, file, container...) confirme que l'instance est opérationnelle.

Exposer l'instance proprement

Le ingress_type: nodeport convient pour tester. En production, passez à ingress_type: ingress (ou route sur OpenShift) avec un nom d'hôte et un certificat TLS, comme pour l'installation en conteneur. Le paramètre équivalent à CONTENT_ORIGIN est géré par l'operator à partir de cet hôte. Voir Installer Pulp pour le raisonnement sur l'exposition HTTPS.

Dépannage

Symptôme	Cause	Solution
Operator bloqué, could not find any storage definition for Database	postgres_storage_class absent	L'ajouter sous database: dans la ressource Pulp
pulp-api en CrashLoopBackOff, log PostgreSQL 14 or later is required	Image PostgreSQL 13 par défaut du chart	Épingler postgres:15 à l'installation et dans le CR
pulp-database en CrashLoop, data directory ... version X ... not compatible	PVC résiduelle d'une autre version majeure	Supprimer la ressource Pulp et la PVC, redéployer
PulpBackup échoue, Failed to run pg_dump	Base en 16 face à un pg_dump 15	Utiliser PostgreSQL 15 pour la base
Pods api/worker Pending sur volume	ReadWriteOnce sur cluster multi-nœuds	Passer à ReadWriteMany ou au stockage objet S3

Glissez pour voir

À retenir

• Sur Kubernetes, Pulp se déploie via le Pulp Operator et une custom resource Pulp déclarative.
• Le chart Helm épingle des versions anciennes : surchargez l'image de l'operator (2.0) et PostgreSQL (15) à l'installation.
• L'operator provisionne toute la pile : API, contenu, workers, PostgreSQL, Redis, reverse proxy.
• postgres_storage_class est obligatoire ; PostgreSQL 15 satisfait pulpcore et l'outil de sauvegarde.
• En production multi-nœuds, le stockage d'artefacts doit être ReadWriteMany ou S3, jamais ReadWriteOnce local.

Prochaines étapes

Sauvegarder et restaurer Pulp PulpBackup/PulpRestore en Kubernetes, et la méthode en conteneur.

Air-gapped et TLS auto-signé Exposer l'instance en HTTPS avec une autorité approuvée.

Sécuriser Pulp RBAC, content-guards et signature.

Installer Pulp (conteneur) L'alternative en un conteneur avec podman.

×

📖 Voir la documentation →