Tailles et ressources
Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.
Un service ne règle ni CPU ni mémoire : il choisit une taille, de xxxs à xxxl. La taille
fixe ce qui lui est réservé ; il peut consommer jusqu'au double en pointe. Le total des
services de votre tenant est borné par le quota de votre offre.
Prérequis
- Connaître votre offre : Tiers.
Étapes
1. Choisir une taille par service
apiVersion: deploy.stackngo.io/v1alpha1
kind: App
metadata:
name: shop
spec:
services:
api:
image: registry.gitlab.com/acme/shop-api:1.4.2
ports: ["8080"]
size: xs # 500m / 1Gi réservés
replicas: 2
worker:
image: registry.gitlab.com/acme/shop-worker:1.4.2
size: xxxs # 100m / 200Mi : parfait pour une tâche légère
db:
image: postgres:17
user: "999"
ports: ["5432"]
size: s # 1 CPU / 2Gi
volumes:
- { path: /var/lib/postgresql/data, size: 10Gi }
Sans size, un service est en xxs. En ligne de commande : sng app create … --size s,
sng app patch shop --service api --size m.
2. Appliquer et lire l'état
sng apply shop.yml
sng app describe shop
Si l'offre ne suffit pas :
App : shop
Statut : QuotaExceeded
Message : db : … exceeded quota … requested: limits.memory=4Gi, used: …, limited: …
SERVICE KIND IMAGE PHASE URL DETAIL
api deployment registry.gitlab.com/acme/shop-api:1.4.2 Ready - Reconciled 2/2 prêts
db deployment postgres:17 Failed - QuotaExceeded … exceeded quota …
worker deployment registry.gitlab.com/acme/shop-worker:1.4.2 Ready - Reconciled 1/1 prêts
Réduisez la taille ou le nombre de réplicas, ou changez d'offre, puis sng apply.
Vérification
sng app describe shop : Statut : prête. Chaque service dispose de la réservation de sa
taille et peut monter jusqu'au double.
Les tailles
size | Réservé CPU / mémoire | Limite CPU / mémoire |
|---|---|---|
xxxs | 100m / 200Mi | 200m / 400Mi |
xxs (défaut) | 200m / 500Mi | 400m / 1000Mi |
xs | 500m / 1Gi | 1 / 2Gi |
s | 1 / 2Gi | 2 / 4Gi |
m | 1 / 5Gi | 2 / 10Gi |
l | 2 / 10Gi | 4 / 20Gi |
xl | 4 / 24Gi | 8 / 48Gi |
xxl | 10 / 48Gi | 20 / 96Gi |
xxxl | 20 / 64Gi | 40 / 128Gi |
1000m = 1 CPU. La réservation est garantie au conteneur ; la limite est le plafond
au-delà duquel il est bridé (CPU) ou arrêté puis redémarré (mémoire). La limite vaut toujours
2 × la réservation, pour le CPU comme pour la mémoire.
Les mêmes valeurs s'appliquent au conteneur d'initialisation (init) du service.
Le quota de votre offre
Votre tenant dispose d'un quota global, fixé par son tier : CPU et mémoire garantis (la somme des réservations), CPU et mémoire max (la somme des limites, soit le double des réservations), stockage et exemplaires. Les deux plafonds comptent. Deux choses à retenir :
- additionnez les réservations de vos exemplaires et comparez-les au garanti du tier, puis
leur double au max : en
3XS(0,5 CPU / 1 Gi garantis, 1 CPU / 2 Gi max), deux servicesxxstiennent (400m / 1000Mi réservés, 800m / 2000Mi de limites), mais pas unxxxsde plus (1200Mi réservés) ; - le quota compte chaque exemplaire :
replicas: 3enxspèse 3 × (500m / 1Gi) ; pendant une mise à jour progressive, les exemplaires en plus (maxSurge) comptent aussi ;autoscale.maxfixe le pire cas.
Quand un service dépasse le quota :
| Moment | Phase et raison | Ce que vous voyez |
|---|---|---|
| à la création du service | Failed, QuotaExceeded | le message cite exceeded quota et la ressource en cause |
| pendant une mise à jour ou une montée en charge | Progressing, QuotaExceeded | les nouveaux exemplaires ne démarrent pas ; les anciens continuent de servir |
Passer d'une consommation compose à une taille
Si votre docker-compose.yml déclare deploy.resources.reservations (ou limits à défaut),
prenez la plus petite taille dont la réservation couvre à la fois le CPU et la mémoire :
cpus: "0.25", memory: 256M → xs (le xxs offre 200m, insuffisant pour 250m) ;
cpus: "1", memory: 1G → s. Au-delà de xxxl, prenez xxxl et découpez le service.
Pour aller plus loin
- Les tailles ne sont pas modifiables ni extensibles par le tenant ; aucun champ ne permet de donner des valeurs libres.
- Le message
QuotaExceededcite la ressource qui bloque (requests.cpu,limits.memory…) ; comme les deux ratios valent 2, c'est toujours la même taille qui déborde, quel que soit le compteur cité. - Un conteneur qui dépasse sa limite mémoire est redémarré ; si cela se répète, montez d'une taille plutôt que de multiplier les réplicas.
Voir aussi
- Tiers
- Healthchecks et scaling
- Référence des manifestes (page
App)