---
title: "Limitations connues"
description: "Ce qui ne fonctionne pas comme sur un cluster Kubernetes classique : la liste honnête, avec le contournement pour chaque limite."
source_url:
  html: https://docs.blackswift.cloud/reference/limitations-connues/
  md: https://docs.blackswift.cloud/reference/limitations-connues.md
---

# Limitations connues

> Ce qui ne fonctionne pas comme sur un cluster Kubernetes classique : la liste honnête, avec le contournement pour chaque limite.

Kontainers est un service de namespaces managés sur un cluster mutualisé — pas un
cluster dédié. Certaines capacités d'un cluster « vanilla » sont donc absentes ou
encadrées, volontairement. Cette page les liste **toutes**, avec le contournement
quand il existe.

| Limitation | Pourquoi | Contournement |
| --- | --- | --- |
| Pas de DaemonSets | Objet cluster-wide par nature (un pod par nœud) | Deployment avec plusieurs replicas + [PDB](https://docs.blackswift.cloud/reference/permissions-et-rbac.md) |
| Pas de ReplicationControllers (quota 0) | Objet déprécié | Deployments |
| NetworkPolicies en lecture seule | L'isolation inter-tenants est gérée par la plateforme | Lisez les règles avec `kubectl get netpol` ; besoin spécifique → [support](https://docs.blackswift.cloud/depanner/contacter-le-support.md) |
| LoadBalancer limité à 1 par namespace | Option payante (0,02 €/h), IP publique dédiée | Quota supplémentaire via ticket ; pour du HTTP(S), l'[Ingress mutualisé](https://docs.blackswift.cloud/deployer/exposer-en-https.md) est inclus |
| Pas d'accès aux nœuds, PV, CRDs, objets cluster | Isolation multi-tenant | — |
| `kubectl get namespaces` refusé | Pas de visibilité inter-tenants | Vos namespaces sont dans votre kubeconfig |
| Pods privilégiés, hostPath, hostNetwork rejetés | Pod Security `baseline` | Repenser le besoin ; cas légitime → support |
| Tolerations control-plane rejetées | Protection du control plane | Retirer la toleration |
| Limite mémoire = request (pas d'overcommit) | Stabilité du nœud, prévisibilité de la facturation | Dimensionner la request sur le pic réel — voir [Mutations](https://docs.blackswift.cloud/reference/mutations-et-politiques.md) |
| Maximum 8 Gi de RAM par conteneur | Plafond LimitRange | Augmentable via ticket avec justification |
| Stockage éphémère limité à 2 Gi par conteneur | Protection des nœuds | Monter un [volume persistant](https://docs.blackswift.cloud/deployer/stockage-persistant.md) pour les données volumineuses |
| Pas de restauration de sauvegarde en self-service | La restauration est une opération encadrée | [Ticket support](https://docs.blackswift.cloud/depanner/contacter-le-support.md), généralement traité en heures ouvrées |
| Rétention des sauvegardes fixe (10 jours) | Politique plateforme | Dumps applicatifs complémentaires (pg_dump en CronJob) pour un RPO/rétention sur mesure |
| Pas de création de namespace en self-service | Validation manuelle (quotas, nommage) | [Ticket support](https://docs.blackswift.cloud/depanner/contacter-le-support.md), gratuit |
| `pods/proxy`, `pods/attach` indisponibles (compte utilisateur) | Surface d'attaque réduite | `kubectl port-forward` et `kubectl exec` couvrent l'essentiel ; le SA CI dispose d'`attach`/`debug` |

## En résumé

Si votre application :

- tourne dans des conteneurs **non privilégiés**,
- s'expose en **HTTP(S) via Ingress** (ou TCP via NodePort/LoadBalancer),
- stocke ses données dans des **PVC** ou une base **PostgreSQL managée**,

…alors aucune de ces limitations ne vous concernera au quotidien. Dans le doute,
[contactez le support](https://docs.blackswift.cloud/depanner/contacter-le-support.md) avant de migrer : mieux
vaut une réponse en amont qu'une surprise en production.