Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Karpenter

Karpenter est un projet open source qui fournit une gestion du cycle de vie des nœuds pour les clusters Kubernetes. Il automatise le provisionnement et le déprovisionnement des nœuds en fonction des besoins de planification des pods, ce qui permet une mise à l'échelle et une optimisation des coûts efficaces. Ses principales fonctions sont les suivantes :

Avec Karpenter, vous pouvez définir NodePools des contraintes relatives au provisionnement des nœuds, telles que les taches, les étiquettes, les exigences (types d'instances, zones, etc.) et les limites du total des ressources provisionnées. Lorsque vous déployez des charges de travail, vous pouvez spécifier des contraintes de planification dans les spécifications du module, telles que les requests/limits, node selectors, node/pod affinités de ressources, les tolérances et les contraintes de répartition topologique. Karpenter fournira ensuite des nœuds de la bonne taille pour ces pods.

Pourquoi utiliser Karpenter

Avant le lancement de Karpenter, les utilisateurs de Kubernetes s'appuyaient principalement sur les groupes Amazon EC2 Auto Scaling et le Kubernetes Cluster Autoscaler (CAS) pour ajuster dynamiquement la capacité de calcul de leurs clusters. Avec Karpenter, vous n'avez pas besoin de créer des dizaines de groupes de nœuds pour bénéficier de la flexibilité et de la diversité que vous offre Karpenter. De plus, Karpenter n'est pas aussi étroitement lié aux versions de Kubernetes (tel CAS quel) et ne vous oblige pas à passer de l'une à l'autre. AWS APIs

Karpenter consolide les responsabilités d'orchestration des instances au sein d'un système unique, plus simple, plus stable et adapté aux clusters. Karpenter a été conçu pour surmonter certains des défis présentés par Cluster Autoscaler en proposant des méthodes simplifiées pour :

Pour obtenir des informations et de la documentation sur l'utilisation de Karpenter, rendez-vous sur le site karpenter.sh.

Recommandations

Les meilleures pratiques sont divisées en sections sur Karpenter lui-même et sur la planification des modules. NodePools

Les meilleures pratiques de Karpenter

Les meilleures pratiques suivantes couvrent des sujets liés à Karpenter lui-même.

Utilisez Karpenter pour les charges de travail dont les besoins en capacité évoluent

Karpenter rapproche la gestion de la mise à l'échelle de la version native de Kubernetes APIs plutôt que les groupes Autoscaling (ASGs) et les groupes de nœuds gérés (). MNGs ASGset MNGs sont des abstractions AWS -natives où le dimensionnement est déclenché en fonction de métriques de AWS niveau, telles que EC2 CPU la charge. Cluster Autoscaler fait le lien entre les abstractions Kubernetes et les AWS abstractions, mais perd une certaine flexibilité à cause de cela, comme la planification pour une zone de disponibilité spécifique.

Karpenter supprime une couche d'AWSabstraction pour apporter une partie de la flexibilité directement dans Kubernetes. Karpenter est idéal pour les clusters dont les charges de travail sont soumises à des périodes de forte demande ou à des exigences informatiques diverses. MNGset ASGs conviennent aux clusters exécutant des charges de travail qui ont tendance à être plus statiques et cohérentes. Vous pouvez utiliser une combinaison de nœuds gérés dynamiquement et statiquement, en fonction de vos besoins.

Envisagez d'autres projets de mise à l'échelle automatique lorsque...

Vous avez besoin de fonctionnalités qui sont toujours en cours de développement dans Karpenter. Karpenter étant un projet relativement récent, envisagez d'autres projets de mise à l'échelle automatique pour le moment si vous avez besoin de fonctionnalités qui ne font pas encore partie de Karpenter.

Exécutez le contrôleur Karpenter sur EKS Fargate ou sur un nœud de travail appartenant à un groupe de nœuds

Karpenter est installé à l'aide d'un graphique Helm. Le graphique Helm installe le contrôleur Karpenter et un module Webhook en tant que déploiement qui doit être exécuté avant que le contrôleur ne puisse être utilisé pour dimensionner votre cluster. Nous recommandons un minimum d'un petit groupe de nœuds avec au moins un nœud de travail. Vous pouvez également exécuter ces modules sur EKS Fargate en créant un profil Fargate pour l'espace de noms. karpenter Cela entraînera l'exécution de tous les pods déployés dans cet espace de noms sur EKS Fargate. N'exécutez pas Karpenter sur un nœud géré par Karpenter.

Aucun modèle de lancement personnalisé n'est pris en charge avec Karpenter

Aucun modèle de lancement personnalisé n'est pris en charge avec la version v1beta1 APIs (v0.32+). Vous pouvez utiliser des données utilisateur personnalisées et/ou spécifier directement la personnalisation AMIs dans leEC2NodeClass. De plus amples informations sur la manière de procéder sont disponibles sur NodeClasses.

Exclure les types d'instances qui ne correspondent pas à votre charge de travail

Envisagez d'exclure des types d'instances spécifiques à l'aide de la node.kubernetes.io/instance-type clé s'ils ne sont pas requis par les charges de travail exécutées dans votre cluster.

L'exemple suivant montre comment éviter de provisionner de grandes instances Graviton.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

Activer la gestion des interruptions lors de l'utilisation de Spot

Karpenter prend en charge la gestion native des interruptions et peut gérer les événements d'interruption involontaires tels que les interruptions liées aux instances Spot, les événements de maintenance planifiée, les événements de termination/d'arrêt d'instance susceptibles de perturber vos charges de travail. Lorsque Karpenter détecte de tels événements pour les nœuds, il entache, vide et arrête automatiquement les nœuds concernés à l'avance afin de commencer à nettoyer en douceur les charges de travail avant toute interruption. En cas d'interruption ponctuelle avec un préavis de 2 minutes, Karpenter démarre rapidement un nouveau nœud afin que les pods puissent être déplacés avant que l'instance ne soit récupérée. Pour activer la gestion des interruptions, vous configurez l'--interruption-queueCLIargument avec le nom de la SQS file d'attente configurée à cet effet. Il n'est pas conseillé d'utiliser la gestion des interruptions Karpenter avec Node Termination Handler, comme expliqué ici.

Les pods qui nécessitent des points de contrôle ou d'autres formes de vidange gracieuse, nécessitant 2 minutes avant l'arrêt, devraient permettre à Karpenter de gérer les interruptions dans leurs clusters.

Cluster EKS privé Amazon sans accès Internet sortant

Lorsque vous approvisionnez un EKS cluster dans un VPC environnement sans accès à Internet, vous devez vous assurer que vous avez configuré votre environnement conformément aux exigences du cluster privé décrites dans la EKS documentation. En outre, vous devez vous assurer que vous avez créé un point de terminaison STS VPC régional dans votreVPC. Si ce n'est pas le cas, vous verrez des erreurs similaires à celles qui apparaissent ci-dessous.

{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Ces modifications sont nécessaires dans un cluster privé car le Karpenter Controller utilise des IAM rôles pour les comptes de service (IRSA). Les pods configurés pour IRSA acquérir des informations d'identification en appelant le AWS Security Token Service (AWSSTS)API. S'il n'y a pas d'accès Internet sortant, vous devez créer et utiliser un AWSSTSVPCpoint de terminaison dans votre VPC.

Les clusters privés nécessitent également que vous créiez un VPCpoint de terminaison pour SSM. Lorsque Karpenter essaie de provisionner un nouveau nœud, il interroge les configurations du modèle de lancement et un SSM paramètre. Si vous n'avez pas de SSM VPC point de terminaison dans votre ordinateurVPC, cela provoquera l'erreur suivante :

{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm.<region>.amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}

Il n'existe aucun VPCpoint de terminaison pour la requête de liste de prix API. Par conséquent, les données sur les prix deviendront obsolètes au fil du temps. Karpenter contourne ce problème en incluant des données de tarification à la demande dans son binaire, mais ne met à jour ces données que lorsque Karpenter est mis à niveau. L'échec des demandes de données tarifaires entraînera les messages d'erreur suivants :

{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

Reportez-vous à cette documentation pour utiliser Karpenter dans un EKS cluster entièrement privé et pour savoir quels VPC points de terminaison créer.

Création NodePools

Les meilleures pratiques suivantes portent sur des sujets liés à la création NodePools.

Créez plusieurs NodePools lorsque...

Lorsque différentes équipes partagent un cluster et doivent exécuter leurs charges de travail sur différents nœuds de travail, ou ont des exigences différentes en matière de système d'exploitation ou de type d'instance, créez-en plusieurs NodePools. Par exemple, une équipe peut vouloir utiliser Bottlerocket, tandis qu'une autre peut vouloir utiliser Amazon Linux. De même, une équipe peut avoir accès à GPU du matériel coûteux dont une autre n'aurait pas besoin. L'utilisation de plusieurs NodePools permet de s'assurer que les ressources les plus appropriées sont disponibles pour chaque équipe.

Créez des NodePools créations qui s'excluent mutuellement ou qui sont pondérées

Il est recommandé de créer des modèles NodePools qui s'excluent mutuellement ou qui sont pondérés afin de garantir un comportement de planification cohérent. Si ce n'est pas le cas et que plusieurs NodePools correspondent, Karpenter choisira au hasard laquelle utiliser, ce qui provoquera des résultats inattendus. Voici des exemples utiles pour créer plusieurs NodePools  :

Créer un NodePool avec GPU et autoriser uniquement l'exécution de charges de travail spéciales sur ces nœuds (coûteux) :

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m0s
    consolidationPolicy: WhenEmpty
    expireAfter: Never
  template:
    metadata: {}
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - p3.8xlarge
        - p3.16xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      taints:
      - effect: NoSchedule
        key: nvidia.com/gpu
        value: "true"

Déploiement avec tolérance aux salissures :

# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-gpu
spec:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"

Pour un déploiement général pour une autre équipe, les NodePool spécifications peuvent inclurenodeAffinity. Un déploiement pourrait alors être utilisé nodeSelectorTerms pour correspondrebilling-team.

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: generalcompute
spec:
  disruption:
    expireAfter: Never
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5.2xlarge
        - c5.large
        - c5.xlarge
        - c5a.large
        - c5a.xlarge
        - r5.large
        - r5.xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand

Déploiement avec nodeAffinity :

# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
  name: workload-my-team
spec:
  replicas: 200
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "billing-team"
                  operator: "In"
                  values: ["my-team"]

Utilisez timers (TTL) pour supprimer automatiquement les nœuds du cluster

Vous pouvez utiliser des minuteries sur les nœuds provisionnés pour définir à quel moment supprimer les nœuds dépourvus de modules de charge de travail ou ayant atteint une date d'expiration. L'expiration des nœuds peut être utilisée comme moyen de mise à niveau, afin que les nœuds soient retirés et remplacés par des versions mises à jour. Voir Expiration dans la documentation de Karpenter pour plus d'informations sur l'utilisation spec.disruption.expireAfter pour configurer l'expiration des nœuds.

Évitez de trop restreindre les types d'instances que Karpenter peut fournir, en particulier lors de l'utilisation de Spot

Lors de l'utilisation de Spot, Karpenter utilise la stratégie d'allocation Price Capacity Optimized pour provisionner EC2 les instances. Cette stratégie indique de EC2 provisionner les instances issues des pools les plus profonds en fonction du nombre d'instances que vous lancez et de réduire au maximum le risque d'interruption. EC2Fleet demande ensuite des instances Spot auprès du pool le moins cher. Plus vous autorisez Karpenter à utiliser de types d'instances, mieux vous EC2 pourrez optimiser le temps d'exécution de votre instance ponctuelle. Par défaut, Karpenter utilisera toutes les EC2 offres de types d'instances de la région et des zones de disponibilité dans lesquelles votre cluster est déployé. Karpenter choisit intelligemment parmi tous les types d'instances en fonction des pods en attente pour s'assurer que vos pods sont planifiés sur des instances de taille et d'équipement appropriés. Par exemple, si votre pod ne nécessite pas unGPU, Karpenter ne planifiera pas votre pod pour un type d'EC2instance prenant en charge unGPU. Si vous n'êtes pas sûr des types d'instances à utiliser, vous pouvez exécuter le sélecteur d'instance Amazon ec2-instance-selector pour générer une liste des types d'instances correspondant à vos besoins de calcul. Par exemple, le CLI prend la mémoire vCPU, l'architecture et la région comme paramètres d'entrée et vous fournit une liste d'EC2instances qui répondent à ces contraintes.

$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

Vous ne devez pas imposer trop de contraintes à Karpenter lorsque vous utilisez des instances Spot, car cela peut affecter la disponibilité de vos applications. Supposons, par exemple, que toutes les instances d'un type particulier soient récupérées et qu'il n'existe aucune alternative appropriée pour les remplacer. Vos pods resteront en attente jusqu'à ce que la capacité ponctuelle pour les types d'instances configurés soit réapprovisionnée. Vous pouvez réduire le risque d'erreurs liées à une capacité insuffisante en répartissant vos instances entre différentes zones de disponibilité, car les pools d'instances sont différents d'un endroit à l'autreAZs. Cela dit, la meilleure pratique générale consiste à autoriser Karpenter à utiliser un ensemble diversifié de types d'instances lors de l'utilisation de Spot.

Pods de planification

Les meilleures pratiques suivantes concernent le déploiement de pods dans un cluster à l'aide de Karpenter pour le provisionnement des nœuds.

Suivez les EKS meilleures pratiques en matière de haute disponibilité

Si vous devez exécuter des applications à haute disponibilité, suivez les recommandations générales relatives aux EKS meilleures pratiques. Consultez la documentation Topology Spread in Karpenter pour plus de détails sur la façon de répartir les pods sur les nœuds et les zones. Utilisez les budgets d'interruption pour définir le nombre minimum de pods disponibles qui doivent être entretenus, en cas de tentative d'expulsion ou de suppression de pods.

Utilisez des contraintes en couches pour limiter les fonctionnalités de calcul disponibles auprès de votre fournisseur de cloud

Le modèle de contraintes en couches de Karpenter vous permet de créer un ensemble complexe de contraintes de déploiement NodePool des modules afin d'obtenir les meilleures correspondances possibles pour la planification des modules. Voici des exemples de contraintes qu'une spécification de pod peut demander :

Créez des alarmes de facturation pour surveiller vos dépenses informatiques

Lorsque vous configurez votre cluster pour qu'il évolue automatiquement, vous devez créer des alarmes de facturation pour vous avertir lorsque vos dépenses dépassent un seuil et ajouter des limites de ressources à votre configuration Karpenter. La définition des limites de ressources avec Karpenter est similaire à la définition de la capacité maximale d'un groupe de mise à l'AWSéchelle automatique dans la mesure où elle représente la quantité maximale de ressources de calcul pouvant être instanciées par un Karpenter. NodePool

L'extrait ci-dessous indique à Karpenter de ne fournir qu'un maximum de 1 000 CPU cœurs et 1 000 Go de mémoire. Karpenter arrêtera d'ajouter de la capacité uniquement lorsque la limite sera atteinte ou dépassée. Lorsqu'une limite est dépassée, le contrôleur Karpenter écrit un message memory resource usage of 1001 exceeds limit of 1000 ou un message similaire dans les journaux du contrôleur. Si vous acheminez les journaux de vos conteneurs vers CloudWatch des journaux, vous pouvez créer un filtre de métriques pour rechercher des modèles ou des termes spécifiques dans vos journaux, puis créer une CloudWatchalarme pour vous avertir lorsque le seuil de métriques que vous avez configuré est dépassé.

Pour plus d'informations sur l'utilisation des limites avec Karpenter, consultez la section Définition des limites de ressources dans la documentation de Karpenter.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

Si vous n'utilisez pas de limites ou ne limitez pas les types d'instances que Karpenter peut provisionner, Karpenter continuera d'ajouter de la capacité de calcul à votre cluster selon les besoins. Si cette configuration de Karpenter permet à votre cluster de s'adapter librement, cela peut également avoir des implications financières importantes. C'est pour cette raison que nous recommandons de configurer les alarmes de facturation. Les alarmes de facturation vous permettent d'être alerté et averti de manière proactive lorsque les frais estimés calculés sur votre ou vos comptes dépassent un seuil défini. Consultez Configuration d'une alarme CloudWatch de facturation Amazon pour surveiller de manière proactive les frais estimés pour plus d'informations.

Vous pouvez également activer la détection des anomalies de coûts, une fonctionnalité de gestion des AWS coûts qui utilise l'apprentissage automatique pour surveiller en permanence vos coûts et votre utilisation afin de détecter les dépenses inhabituelles. Vous trouverez de plus amples informations dans le guide de démarrage de la détection des anomalies de AWS coût. Si vous êtes allé jusqu'à créer un budget dans AWS Budgets, vous pouvez également configurer une action pour vous avertir lorsqu'un seuil spécifique a été dépassé. Avec les actions budgétaires, vous pouvez envoyer un e-mail, publier un message sur un SNS sujet ou envoyer un message à un chatbot tel que Slack. Pour plus d'informations, voir Configuration des actions de AWS budget.

Utilisez l'do-not-disrupt annotation karpenter.sh/ pour empêcher Karpenter de déprovisionner un nœud

Si vous exécutez une application critique sur un nœud approvisionné par Karpenter, tel qu'un traitement par lots de longue durée ou une application dynamique, et que le nœud TTL a expiré, l'application sera interrompue lors de la fermeture de l'instance. En ajoutant une karpenter.sh/do-not-disrupt annotation au pod, vous demandez à Karpenter de conserver le nœud jusqu'à ce que le pod soit fermé ou que l'karpenter.sh/do-not-disruptannotation soit supprimée. Consultez la documentation de Distruption pour plus d'informations.

Si les seuls pods qui restent sur un nœud ne relevant pas du daemonset sont ceux associés aux tâches, Karpenter est en mesure de cibler et de supprimer ces nœuds à condition que le statut de la tâche soit « réussi » ou « échec ».

Configurer requests=limits pour toutes les ressources autres que les ressources lors de l'utilisation de la consolidation CPU

La consolidation et la planification fonctionnent en général en comparant les demandes de ressources du pod à la quantité de ressources allouables sur un nœud. Les limites de ressources ne sont pas prises en compte. Par exemple, les pods dont la limite de mémoire est supérieure à la demande de mémoire peuvent dépasser la demande. Si plusieurs pods sur le même nœud éclatent en même temps, cela peut entraîner la fermeture de certains pods en raison d'un manque de mémoire (OOM). La consolidation peut augmenter les chances que cela se produise, car il est possible de regrouper les pods sur les nœuds uniquement en tenant compte de leurs demandes.

LimitRanges À utiliser pour configurer les valeurs par défaut pour les demandes de ressources et les limites

Kubernetes ne définissant pas de requêtes ou de limites par défaut, la consommation de ressources par un conteneur en provenance de l'hôte sous-jacent et en mémoire n'est pas liée. CPU Le planificateur Kubernetes examine le nombre total de demandes d'un pod (le plus élevé entre le nombre total de demandes provenant des conteneurs du pod ou le total des ressources provenant des conteneurs d'initialisation du pod) afin de déterminer sur quel nœud de travail planifier le pod. De même, Karpenter prend en compte les demandes d'un module pour déterminer le type d'instance qu'il fournit. Vous pouvez utiliser une plage de limites pour appliquer une valeur par défaut raisonnable à un espace de noms, au cas où les demandes de ressources ne seraient pas spécifiées par certains pods.

Voir Configurer les demandes de mémoire par défaut et les limites pour un espace de noms

Appliquez des demandes de ressources précises à toutes les charges de travail

Karpenter est en mesure de lancer les nœuds les mieux adaptés à vos charges de travail lorsque ses informations concernant vos exigences en matière de charges de travail sont exactes. Cela est particulièrement important si vous utilisez la fonction de consolidation de Karpenter.

Voir Configurer et dimensionner les demandes/limites de ressources pour toutes les charges de travail

DNSRecommandations fondamentales

Mettre à jour la configuration de Core DNS pour maintenir la fiabilité

Lorsque vous déployez DNS des pods Core sur des nœuds gérés par Karpenter, étant donné la nature dynamique de Karpenter en matière de termination/création rapides de nouveaux nœuds pour répondre à la demande, il est conseillé de respecter les meilleures pratiques suivantes :

Durée du DNS manège principal

Sonde de DNS préparation du noyau

Cela permettra de s'assurer que les DNS requêtes ne sont pas dirigées vers un Core DNS Pod qui n'est pas encore prêt ou qui a été arrêté.

Plans de charpentier

Karpenter adopte une approche axée sur les applications pour fournir de la capacité de calcul au plan de données Kubernetes. Dans certains scénarios de charge de travail courants, vous vous demandez peut-être comment les configurer correctement. Karpenter Blueprints est un référentiel qui inclut une liste de scénarios de charge de travail courants conformes aux meilleures pratiques décrites ici. Vous disposerez de toutes les ressources nécessaires pour créer un EKS cluster avec Karpenter configuré et tester chacun des plans inclus dans le référentiel. Vous pouvez combiner différents plans pour créer enfin celui dont vous avez besoin pour votre ou vos charges de travail.

Ressources supplémentaires

📝 Modifiez cette page sur GitHub