doc-locale/fr-fr/administration/reference_architectures/cloud_native_first.md
{{< details >}}
{{< /details >}}
Les architectures de référence Cloud Native First sont conçues pour les modèles de déploiement cloud-native modernes avec quatre tailles standardisées (S/M/L/XL) basées sur les caractéristiques de charge de travail. Ces architectures déploient tous les composants GitLab dans Kubernetes, tandis que PostgreSQL, Redis et le stockage d'objets utilisent des solutions tierces externes, notamment des services gérés ou des options sur site.
[!note] Ces architectures sont en bêta. Nous encourageons les retours d'expérience et continuerons à affiner les spécifications sur la base des données d'utilisation en production.
Les architectures Cloud Native First déploient les composants GitLab dans Kubernetes et des services externes :
@startuml kubernetes
skinparam linetype ortho
card "Kubernetes via Helm Charts" as kubernetes {
collections "**Webservice Pods**\n//Auto-scaling//" as web #32CD32
collections "**Sidekiq Pods**\n//Auto-scaling//" as sidekiq #ff8dd1
collections "**Gitaly Pods**\n//StatefulSets//" as gitaly #FF8C00
collections "**Supporting Pods**\n//Gateway API / Ingress, Toolbox//" as support #e76a9b
}
card "External Services" as external {
collections "**PostgreSQL**" as database #4EA7FF
collections "**Redis Cache**" as redis_cache #FF6347
collections "**Redis Persistent**" as redis_persistent #FF6347
cloud "**Object Storage**" as object_storage #white
}
kubernetes -[hidden]---> external
web -[#32CD32,norank]--> object_storage
web -[#32CD32,norank]--> redis_cache
web -[#32CD32,norank]--> redis_persistent
web -[#32CD32,norank]--> database
sidekiq -[#ff8dd1,norank]--> object_storage
sidekiq -[#ff8dd1,norank]--> redis_cache
sidekiq -[#ff8dd1,norank]--> redis_persistent
sidekiq -[#ff8dd1,norank]--> database
@enduml
Kubernetes components :
[!note] Lors du déploiement de Gitaly sur Kubernetes, Gitaly ne prend en charge que les configurations fragmentées (non-cluster). Vous pouvez mettre à niveau Gitaly sans interruption de service grâce aux nouvelles tentatives client. Chaque pod Gitaly est un point de défaillance unique pour les dépôts qu'il sert. Gitaly Cluster (Praefect) n'est pas pris en charge sur Kubernetes.
Si vous avez besoin d'une haute disponibilité Gitaly avec basculement automatique, envisagez les architectures Cloud Native Hybrid, qui déploient Gitaly Cluster sur des machines virtuelles tout en exécutant des composants sans état dans Kubernetes. Pour les exigences et limitations de Gitaly sur Kubernetes, consultez Gitaly sur Kubernetes.
External services :
Pour les fournisseurs de services gérés recommandés (GCP Cloud SQL, AWS RDS, Azure Database, etc.), consultez les fournisseurs et services cloud recommandés.
Ces architectures sont conçues autour de plages RPS cibles représentant les modèles de charge de travail de production typiques. Les cibles RPS servent de points de départ ; vos besoins en capacité spécifiques dépendent de la composition de la charge de travail et des modèles d'utilisation. Pour des conseils sur la composition RPS et les cas où des ajustements sont nécessaires, consultez Comprendre la composition RPS.
| Taille | RPS cible | Charge de travail prévue |
|---|---|---|
| S | ≤100 | Équipes avec une activité de développement légère et une automatisation minimale |
| M | ≤200 | Organisations avec une vélocité de développement modérée et une utilisation standard du CI/CD |
| L | ≤500 | Grandes équipes avec une activité de développement intense et une automatisation significative |
| XL | ≤1000 | Déploiements d'entreprise avec des charges de travail intensives et des intégrations étendues |
Pour des conseils détaillés sur la détermination de votre charge attendue et la sélection de la taille appropriée, consultez le guide de dimensionnement des architectures de référence.
Les architectures Cloud Native First offrent :
Avant de déployer une architecture Cloud Native First, assurez-vous de disposer de :
Pour les exigences complètes, notamment la mise en réseau, les types de machines et les services des fournisseurs cloud, consultez les exigences des architectures de référence.
Pour les exigences spécifiques et les limitations de Gitaly sur Kubernetes, consultez les exigences de Gitaly sur Kubernetes.
Target load : ≤ 100 RPS | Charge globale légère
Workload characteristics :
| Composant | Ressources par pod | Pods/Workers minimum | Pods/Workers maximum | Exemple de configuration de nœud |
|---|---|---|---|---|
| Webservice | 2 vCPU, 3 Go (requête), 4 Go (limite) | 12 pods (24 workers) | 18 pods (36 workers) | GCP : 6 × n2-standard-8 |
| AWS : 6 × c6i.2xlarge | ||||
| Sidekiq | 900m vCPU, 2 Go (requête), 4 Go (limite) | 8 workers | 12 workers | GCP : 3 × n2-standard-4 |
| AWS : 3 × m6i.xlarge | ||||
| Gitaly | 7 vCPU, 30 Go (requête et limite) | 3 pods | 3 pods | GCP : 3 × n2-standard-8 |
| AWS : 3 × m6i.2xlarge | ||||
| Support | Variable selon le service | 12 vCPU, 48 Go | 12 vCPU, 48 Go | GCP : 3 × n2-standard-4 |
| AWS : 3 × c6i.xlarge |
| Composant | Pods min → max | Workers min → max | Ressources par pod | Workers par pod |
|---|---|---|---|---|
| Webservice | 12 → 18 | 24 → 36 | 2 vCPU, 3 Go (requête), 4 Go (limite) | 2 |
| Sidekiq | 8 → 12 | 8 → 12 | 900m vCPU, 2 Go (requête), 4 Go (limite) | 1 |
| Gitaly | 3 (sans mise à l'échelle automatique) | sans objet | 7 vCPU, 30 Go (requête et limite) | sans objet |
Gitaly notes : cgroups Git : 27 Go, tampon : 3 Go. cgroups de dépôt définis à 1. Consultez la configuration des cgroups Gitaly pour des conseils d'optimisation.
| Service | Configuration | Équivalent GCP | Équivalent AWS |
|---|---|---|---|
| PostgreSQL | 8 vCPU, 32 Go | n2-standard-8 | m6i.2xlarge |
| Redis - Cache | 2 vCPU, 8 Go | n2-standard-2 | m6i.large |
| Redis - Persistant | 2 vCPU, 8 Go | n2-standard-2 | m6i.large |
| Stockage d'objets | Service du fournisseur cloud | Google Cloud Storage | Amazon S3 |
Target load : ≤ 200 RPS | Charge globale modérée
Workload characteristics :
| Composant | Ressources par pod | Pods/Workers minimum | Pods/Workers maximum | Exemple de configuration de nœud |
|---|---|---|---|---|
| Webservice | 2 vCPU, 3 Go (requête), 4 Go (limite) | 28 pods (56 workers) | 42 pods (84 workers) | GCP : 6 × n2-standard-16 |
| AWS : 6 × c6i.4xlarge | ||||
| Sidekiq | 900m vCPU, 2 Go (requête), 4 Go (limite) | 16 workers | 24 workers | GCP : 3 × n2-standard-8 |
| AWS : 3 × m6i.2xlarge | ||||
| Gitaly | 15 vCPU, 62 Go (requête et limite) | 3 pods | 3 pods | GCP : 3 × n2-standard-16 |
| AWS : 3 × m6i.4xlarge | ||||
| Support | Variable selon le service | 12 vCPU, 48 Go | 12 vCPU, 48 Go | GCP : 3 × n2-standard-4 |
| AWS : 3 × c6i.xlarge |
| Composant | Pods min → max | Workers min → max | Ressources par pod | Workers par pod |
|---|---|---|---|---|
| Webservice | 28 → 42 | 56 → 84 | 2 vCPU, 3 Go (requête), 4 Go (limite) | 2 |
| Sidekiq | 16 → 24 | 16 → 24 | 900m vCPU, 2 Go (requête), 4 Go (limite) | 1 |
| Gitaly | 3 (sans mise à l'échelle automatique) | sans objet | 15 vCPU, 62 Go (requête et limite) | sans objet |
Gitaly notes : cgroups Git : 56 Go, tampon : 6 Go. cgroups de dépôt définis à 1. Consultez la configuration des cgroups Gitaly pour des conseils d'optimisation.
| Service | Configuration | Équivalent GCP | Équivalent AWS |
|---|---|---|---|
| PostgreSQL | 16 vCPU, 64 Go | n2-standard-16 | m6i.4xlarge |
| Redis - Cache | 2 vCPU, 8 Go | n2-standard-2 | m6i.large |
| Redis - Persistant | 2 vCPU, 8 Go | n2-standard-2 | m6i.large |
| Stockage d'objets | Service du fournisseur cloud | Google Cloud Storage | Amazon S3 |
Target load : ≤ 500 RPS | Charge globale élevée
Workload characteristics :
| Composant | Ressources par pod | Pods/Workers minimum | Pods/Workers maximum | Exemple de configuration de nœud |
|---|---|---|---|---|
| Webservice | 2 vCPU, 3 Go (requête), 4 Go (limite) | 56 pods (112 workers) | 84 pods (168 workers) | GCP : 6 × n2-standard-32 |
| AWS : 6 × c6i.8xlarge | ||||
| Sidekiq | 900m vCPU, 2 Go (requête), 4 Go (limite) | 32 workers | 48 workers | GCP : 6 × n2-standard-8 |
| AWS : 6 × m6i.2xlarge | ||||
| Gitaly | 31 vCPU, 126 Go (requête et limite) | 3 pods | 3 pods | GCP : 3 × n2-standard-32 |
| AWS : 3 × m6i.8xlarge | ||||
| Support | Variable selon le service | 12 vCPU, 48 Go | 12 vCPU, 48 Go | GCP : 3 × n2-standard-4 |
| AWS : 3 × c6i.xlarge |
| Composant | Pods min → max | Workers min → max | Ressources par pod | Workers par pod |
|---|---|---|---|---|
| Webservice | 56 → 84 | 112 → 168 | 2 vCPU, 3 Go (requête), 4 Go (limite) | 2 |
| Sidekiq | 32 → 48 | 32 → 48 | 900m vCPU, 2 Go (requête), 4 Go (limite) | 1 |
| Gitaly | 3 (sans mise à l'échelle automatique) | sans objet | 31 vCPU, 126 Go (requête et limite) | sans objet |
Gitaly notes : cgroups Git : 120 Go, tampon : 6 Go. cgroups de dépôt définis à 1. Consultez la configuration des cgroups Gitaly pour des conseils d'optimisation.
| Service | Configuration | Équivalent GCP | Équivalent AWS |
|---|---|---|---|
| PostgreSQL | 32 vCPU, 128 Go | n2-standard-32 | m6i.8xlarge |
| Redis - Cache | 2 vCPU, 16 Go | n2-highmem-2 | r6i.large |
| Redis - Persistant | 2 vCPU, 16 Go | n2-highmem-2 | r6i.large |
| Stockage d'objets | Service du fournisseur cloud | Google Cloud Storage | Amazon S3 |
Target load : ≤ 1 000 RPS | Charge globale intensive
Workload characteristics :
| Composant | Ressources par pod | Pods/Workers minimum | Pods/Workers maximum | Exemple de configuration de nœud |
|---|---|---|---|---|
| Webservice | 2 vCPU, 3 Go (requête), 4 Go (limite) | 110 pods (220 workers) | 165 pods (330 workers) | GCP : 6 × n2-standard-64 |
| AWS : 6 × c6i.16xlarge | ||||
| Sidekiq | 900m vCPU, 2 Go (requête), 4 Go (limite) | 64 workers | 96 workers | GCP : 6 × n2-standard-16 |
| AWS : 6 × m6i.4xlarge | ||||
| Gitaly | 63 vCPU, 254 Go (requête et limite) | 3 pods | 3 pods | GCP : 3 × n2-standard-64 |
| AWS : 3 × m6i.16xlarge | ||||
| Support | Variable selon le service | 24 vCPU, 96 Go | 24 vCPU, 96 Go | GCP : 3 × n2-standard-8 |
| AWS : 3 × c6i.2xlarge |
| Composant | Pods min → max | Workers min → max | Ressources par pod | Workers par pod |
|---|---|---|---|---|
| Webservice | 110 → 165 | 220 → 330 | 2 vCPU, 3 Go (requête), 4 Go (limite) | 2 |
| Sidekiq | 64 → 96 | 64 → 96 | 900m vCPU, 2 Go (requête), 4 Go (limite) | 1 |
| Gitaly | 3 (sans mise à l'échelle automatique) | sans objet | 63 vCPU, 254 Go (requête et limite) | sans objet |
Gitaly notes : cgroups Git : 248 Go, tampon : 6 Go. cgroups de dépôt définis à 1. Consultez la configuration des cgroups Gitaly pour des conseils d'optimisation.
| Service | Configuration | Équivalent GCP | Équivalent AWS |
|---|---|---|---|
| PostgreSQL | 64 vCPU, 256 Go | n2-standard-64 | m6i.16xlarge |
| Redis - Cache | 2 vCPU, 16 Go | n2-highmem-2 | r6i.large |
| Redis - Persistant | 2 vCPU, 16 Go | n2-highmem-2 | r6i.large |
| Stockage d'objets | Service du fournisseur cloud | Google Cloud Storage | Amazon S3 |
Cette section fournit des conseils supplémentaires pour le déploiement et l'exploitation des architectures Cloud Native First, notamment la sélection du type de machine, les considérations spécifiques aux composants et les stratégies de mise à l'échelle.
Les types de machines indiqués sont des exemples utilisés lors de la validation et des tests. Vous pouvez utiliser :
N'utilisez pas de types d'instances burstables en raison de performances inconsistantes.
Pour plus d'informations, consultez les types de machines pris en charge.
Gitaly dans Kubernetes avec les architectures Cloud Native First utilise des StatefulSets avec les spécifications suivantes :
Gitaly deployment mode :
De par sa conception, Gitaly (non-Cluster) sur Kubernetes est un service à point de défaillance unique pour les dépôts stockés sur chaque pod. Les données sont sourcées et servies depuis une seule instance par pod. Chaque pod Gitaly gère son propre ensemble de dépôts, assurant une mise à l'échelle horizontale du stockage Git via la distribution des dépôts.
Gitaly Cluster (Praefect) n'est pas pris en charge dans les architectures Cloud Native First. Pour le contexte sur les limitations du déploiement Gitaly dans Kubernetes, consultez Gitaly sur Kubernetes.
Repository distribution :
Avec plusieurs stockages Gitaly configurés (par exemple default, storage1, storage2), GitLab crée par défaut tous les nouveaux dépôts sur le stockage default. Pour distribuer les dépôts sur tous les pods Gitaly, configurez les poids de stockage pour équilibrer la charge.
Pour des conseils sur la configuration des poids de stockage des dépôts, consultez configurer où les nouveaux dépôts sont stockés.
Gitaly utilise les cgroups pour se protéger contre l'épuisement des ressources dû aux opérations Git individuelles. La configuration par défaut définit le nombre de cgroups de dépôt à 1, ce qui constitue un point de départ permettant à n'importe quel dépôt individuel d'utiliser toutes les ressources du pod via la sursouscription.
Cependant, cette configuration peut ne pas être optimale pour toutes les charges de travail. Pour les environnements avec de nombreux dépôts actifs ou des exigences spécifiques d'isolation des ressources, vous devez ajuster la configuration des cgroups en fonction des modèles d'utilisation observés. Cela inclut l'ajustement du nombre de cgroups de dépôt et des allocations de mémoire.
Pour des conseils détaillés sur la mesure, l'optimisation et la configuration des cgroups Gitaly, consultez cgroups Gitaly.
Pour les grands monodépôts (de plus de 2 Go) ou les charges de travail Git intensives, des ajustements supplémentaires de Gitaly peuvent être nécessaires. Consultez le guide de dimensionnement des architectures de référence pour des conseils détaillés.
Toutes les architectures utilisent Kubernetes Horizontal Pod Autoscaler (HPA) et Cluster Autoscaler pour gérer la capacité :
Les nombres minimum de pods sont fixés à environ 2/3 du maximum pour équilibrer l'efficacité des coûts et la fiabilité des performances, sur la base de tests internes visant à atteindre les objectifs suivants :
Si vous avez des modèles de charge bien compris, vous pouvez ajuster les minimums en fonction de vos besoins :
Les architectures Cloud Native First sont conçues pour évoluer au-delà de leurs spécifications de base. Vous pourriez avoir besoin d'ajuster la capacité si votre environnement présente :
Les stratégies de mise à l'échelle diffèrent selon le type de composant.
Pour augmenter la capacité, effectuez une mise à l'échelle horizontale en ajustant le nombre maximum de réplicas et la capacité du pool de nœuds :
maxReplicas dans les valeurs Helm et ajoutez les nœuds correspondants au pool de nœuds WebservicemaxReplicas pour gérer un débit de jobs plus élevé et ajoutez des nœuds au pool de nœuds SidekiqLa mise à l'échelle horizontale est l'approche recommandée pour ces composants sans état.
Pour les composants avec état, augmentez les spécifications des instances ou des pods :
Par défaut, Sidekiq traite tous les types de jobs dans une seule file d'attente. Pour les environnements avec des modèles de charge de travail variés, vous pouvez configurer des files d'attente distinctes en fonction des caractéristiques des jobs :
La séparation des files d'attente peut améliorer la fiabilité du traitement des jobs et empêcher les jobs à faible priorité de bloquer les opérations urgentes, en particulier dans les environnements plus grands (L, XL) avec des charges de travail d'automatisation importantes.
Pour plus d'informations sur la configuration des files d'attente Sidekiq, consultez le traitement de classes de jobs spécifiques.
GitLab Duo Agent Platform introduit des exigences d'infrastructure supplémentaires au-delà des charges de travail GitLab standard. Pour des conseils détaillés sur la surveillance et la mise à l'échelle pour l'adoption d'Agent Platform, consultez Mise à l'échelle pour GitLab Duo Agent Platform.
Lors de la mise à l'échelle significative d'un composant :
Pour des conseils complets sur la mise à l'échelle, consultez la mise à l'échelle d'un environnement.
Les architectures Cloud Native First peuvent être déployées à l'aide de charts Helm et de fournisseurs de services externes directement ou via le GitLab Environment Toolkit.
Le GitLab Environment Toolkit fournit un déploiement automatisé avec :
Pour les instructions de déploiement, consultez la documentation du GitLab Environment Toolkit.
Prérequis pour le déploiement manuel :
Pour les prérequis détaillés et la configuration des secrets, consultez les prérequis du chart GitLab et configurer les secrets.
Pour le déploiement manuel à l'aide de charts Helm :
helm installPour les étapes détaillées du déploiement manuel, consultez l'installation de GitLab sur Kubernetes.
Pour des exemples complets de configuration du chart Helm et des conseils détaillés sur le déploiement, consultez le dépôt GitLab Charts.
Principaux domaines de configuration pour les architectures Cloud Native First :
webservice, sidekiq, gitaly, support)Pour les nombres de réplicas et les valeurs de ressources spécifiques à chaque architecture, référez-vous aux spécifications dans chaque section de taille ci-dessus.
[!note] Les architectures Cloud Native First sont en version bêta. Des exemples spécifiques de configuration du chart Helm seront ajoutés au dépôt Charts au fur et à mesure que la fonctionnalité progresse vers la disponibilité générale. Utilisez les spécifications de chaque section de taille d'architecture ci-dessus pour construire votre configuration de valeurs Helm.
Après le déploiement, les environnements nécessitent généralement une surveillance et un réglage pour correspondre aux modèles de charge de travail réels.
Les architectures de référence sont des points de départ. De nombreux environnements bénéficient d'ajustements basés sur :
Consultez Mise à l'échelle avancée pour des conseils d'ajustement spécifiques aux composants.
Vous pouvez configurer des fonctionnalités optionnelles supplémentaires de GitLab selon vos besoins. Consultez les étapes après l'installation de GitLab pour plus d'informations.
[!note] Une capacité supplémentaire peut être requise pour les fonctionnalités optionnelles. Consultez la documentation spécifique à la fonctionnalité pour connaître les exigences.