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.
Calcul et mise à l'échelle automatique
En tant que développeur, vous évaluerez les besoins en ressources de votre application, par exemple en termes de processeur et de mémoire, mais si vous ne les ajustez pas continuellement, elles risquent de devenir obsolètes, ce qui peut augmenter vos coûts et détériorer les performances et la fiabilité. Il est plus important d'ajuster en permanence les besoins en ressources d'une application que de les satisfaire correctement du premier coup.
Les meilleures pratiques mentionnées ci-dessous vous aideront à créer et à exploiter des charges de travail sensibles aux coûts qui permettent d'obtenir des résultats commerciaux tout en minimisant les coûts et en permettant à votre organisation de maximiser son retour sur investissement. Voici un ordre d'importance élevé pour optimiser les coûts de calcul de votre cluster :
-
Dimensionnez correctement les charges de travail
-
Réduction de la capacité inutilisée
-
Optimisez les types de capacité de calcul (par exemple Spot) et les accélérateurs (par exemple GPUs)
Dimensionnez correctement vos charges de travail
Dans la plupart des clusters EKS, l'essentiel des coûts provient des EC2 instances utilisées pour exécuter vos charges de travail conteneurisées. Vous ne serez pas en mesure de dimensionner correctement vos ressources informatiques si vous ne comprenez pas vos exigences en matière de charges de travail. C'est pourquoi il est essentiel que vous utilisiez les demandes et les limites appropriées et que vous modifiiez ces paramètres si nécessaire. En outre, les dépendances, telles que la taille de l'instance et la sélection du stockage, peuvent affecter les performances de la charge de travail, ce qui peut avoir diverses conséquences imprévues sur les coûts et la fiabilité.
Les demandes doivent correspondre à l'utilisation réelle. Si les demandes d'un conteneur sont trop élevées, la capacité sera inutilisée, ce qui représente un facteur important dans le coût total du cluster. Chaque conteneur d'un pod, par exemple l'application et les sidecars, doit avoir ses propres demandes et limites définies pour garantir que les limites globales des pods sont aussi précises que possible.
Utilisez des outils tels que Goldilocks
Nous vous recommandons d'utiliser le Horizontal Pod Autoscaler (HPA) pour contrôler le nombre de répliques de votre application à exécuter, le Vertical Pod Autoscaler (VPA) pour ajuster le nombre de demandes et les limites dont votre application a besoin par réplique, et un autoscaler de nœuds tel que Karpenter
Le Vertical Pod Autoscaler peut ajuster les demandes et les limites attribuées aux conteneurs afin que les charges de travail s'exécutent de manière optimale. Vous devez exécuter le VPA en mode audit afin qu'il n'apporte pas automatiquement de modifications et ne redémarre pas vos pods. Il proposera des modifications en fonction des indicateurs observés. Toute modification affectant les charges de travail de production doit d'abord être examinée et testée dans un environnement hors production, car elle peut avoir un impact sur la fiabilité et les performances de votre application.
Réduire la consommation
Le meilleur moyen d'économiser de l'argent est de fournir moins de ressources. L'un des moyens d'y parvenir consiste à ajuster les charges de travail en fonction de leurs exigences actuelles. Vous devez commencer tout effort d'optimisation des coûts en vous assurant que vos charges de travail répondent à leurs exigences et évoluent de manière dynamique. Cela nécessitera d'obtenir des métriques à partir de vos applications et de définir des configurations telles que PodDisruptionBudgets
L'Horizontal Pod Autoscaler est un autoscaler de charge de travail flexible qui peut ajuster le nombre de répliques nécessaires pour répondre aux exigences de performance et de fiabilité de votre application. Il dispose d'un modèle flexible permettant de définir quand augmenter ou diminuer en fonction de diverses mesures telles que le processeur, la mémoire ou de mesures personnalisées, telles que la profondeur de la file d'attente, le nombre de connexions à un pod, etc.
Le serveur de métriques Kubernetes permet une mise à l'échelle en réponse à des indicateurs intégrés tels que l'utilisation du processeur et de la mémoire, mais si vous souhaitez effectuer une mise à l'échelle en fonction d'autres indicateurs, tels que la profondeur des files d'attente Amazon CloudWatch ou SQS, vous devez envisager des projets de mise à l'échelle automatique pilotés par des événements tels que KEDA.
La réduction de la consommation de charge de travail crée une capacité excédentaire dans un cluster et, avec une configuration d'autoscaling appropriée, vous pouvez automatiquement réduire le nombre de nœuds et réduire vos dépenses totales. Nous vous recommandons de ne pas essayer d'optimiser la capacité de calcul manuellement. Le planificateur Kubernetes et les autoscalers de nœuds ont été conçus pour gérer ce processus à votre place.
Réduction de la capacité inutilisée
Une fois que vous avez déterminé la taille appropriée pour les applications, réduisant ainsi le nombre de demandes excédentaires, vous pouvez commencer à réduire la capacité de calcul allouée. Vous devriez être en mesure de le faire de manière dynamique si vous avez pris le temps de dimensionner correctement vos charges de travail dans les sections ci-dessus. Deux autoscalers de nœuds principaux sont utilisés avec Kubernetes dans AWS.
Karpenter et Cluster Autoscaler
Karpenter et Kubernetes Cluster Autoscaler augmenteront le nombre de nœuds de votre cluster en fonction de la création ou de la suppression de pods et de l'évolution des exigences de calcul. L'objectif principal des deux est le même, mais Karpenter adopte une approche différente pour le provisionnement et le déprovisionnement de la gestion des nœuds, ce qui peut contribuer à réduire les coûts et à optimiser l'utilisation à l'échelle du cluster.
À mesure que la taille des clusters augmente et que la variété des charges de travail augmente, il devient de plus en plus difficile de préconfigurer les groupes de nœuds et les instances. Tout comme pour les demandes de charge de travail, il est important de définir une base de référence initiale et de l'ajuster en permanence selon les besoins.
Si vous utilisez Cluster Autoscaler, il respectera les valeurs « minimum » et « maximum » de chaque groupe Auto Scaling (ASG) et ajustera uniquement la valeur « souhaitée ». Il est important de faire attention lorsque vous définissez ces valeurs pour l'ASG sous-jacent, car Cluster Autoscaler ne sera pas en mesure de réduire un ASG au-delà de son nombre « minimum ». Définissez le nombre « souhaité » comme le nombre de nœuds dont vous avez besoin pendant les heures normales de bureau et le nombre « minimum » comme le nombre de nœuds dont vous avez besoin en dehors des heures de bureau. Reportez-vous au document FAQ de Cluster Autoscaler
Expandeur de priorité Cluster Autoscaler
Le Kubernetes Cluster Autoscaler fonctionne en redimensionnant des groupes de nœuds (appelés groupes de nœuds) vers le haut ou vers le bas au fur et à mesure que les applications augmentent ou diminuent. Si vous ne dimensionnez pas les charges de travail de manière dynamique, le Cluster Autoscaler ne vous aidera pas à économiser de l'argent. Le Cluster Autoscaler nécessite qu'un administrateur du cluster crée des groupes de nœuds à l'avance pour que les charges de travail soient consommées. Les groupes de nœuds doivent être configurés pour utiliser des instances ayant le même « profil », c'est-à-dire à peu près la même quantité de processeur et de mémoire.
Vous pouvez avoir plusieurs groupes de nœuds et le Cluster Autoscaler peut être configuré pour définir des niveaux de dimensionnement prioritaires. Chaque groupe de nœuds peut contenir des nœuds de tailles différentes. Les groupes de nœuds peuvent avoir différents types de capacité et l'extenseur de priorité peut d'abord être utilisé pour dimensionner les groupes les moins coûteux.
Vous trouverez ci-dessous un exemple d'extrait de configuration de cluster qui utilise un ConfigMap` pour prioriser la capacité réservée avant d'utiliser des instances à la demande. Vous pouvez utiliser la même technique pour prioriser les instances Graviton ou Spot par rapport aux autres types.
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster managedNodeGroups: - name: managed-ondemand minSize: 1 maxSize: 7 instanceType: m5.xlarge - name: managed-reserved minSize: 2 maxSize: 10 instanceType: c5.2xlarge
apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-priority-expander namespace: kube-system data: priorities: |- 10: - .*ondemand.* 50: - .*reserved.*
L'utilisation de groupes de nœuds peut aider les ressources de calcul sous-jacentes à faire ce que l'on attend par défaut, par exemple en répartissant les nœuds AZs, mais toutes les charges de travail n'ont pas les mêmes exigences ou attentes. Il est donc préférable de laisser les applications déclarer leurs besoins de manière explicite. Pour plus d'informations sur Cluster Autoscaler, consultez la section des meilleures pratiques.
Déplanificateur
Le Cluster Autoscaler peut ajouter et supprimer de la capacité des nœuds d'un cluster en fonction de la nécessité de planifier de nouveaux pods ou de la sous-utilisation de nœuds. Il ne prend pas en compte de manière globale le placement des pods une fois qu'ils ont été planifiés sur un nœud. Si vous utilisez le Cluster Autoscaler, vous devez également consulter le déplanificateur Kubernetes pour éviter de gaspiller de la capacité dans
Si vous avez 10 nœuds dans un cluster et que chaque nœud est utilisé à 60 %, vous n'utilisez pas 40 % de la capacité allouée dans le cluster. Avec le Cluster Autoscaler, vous pouvez définir le seuil d'utilisation par nœud à 60 %, mais cela n'essaiera de réduire qu'un seul nœud lorsque l'utilisation est tombée en dessous de 60 %.
Avec le déplanificateur, il peut examiner la capacité et l'utilisation du cluster une fois que les pods ont été planifiés ou que des nœuds ont été ajoutés au cluster. Il tente de maintenir la capacité totale du cluster au-dessus d'un seuil spécifié. Il peut également supprimer des pods en fonction de l'altération des nœuds ou de nouveaux nœuds qui rejoignent le cluster pour s'assurer que les pods fonctionnent dans leur environnement informatique optimal. Notez que le déplanificateur ne planifie pas le remplacement des pods expulsés mais s'appuie sur le planificateur par défaut pour cela.
Consolidation de Karpenter
Karpenter adopte une approche « sans groupe » pour la gestion des nœuds. Cette approche est plus flexible pour les différents types de charge de travail et nécessite moins de configuration initiale pour les administrateurs de clusters. Au lieu de prédéfinir des groupes et de dimensionner chaque groupe en fonction des besoins des charges de travail, Karpenter utilise des fournisseurs et des modèles de nœuds pour définir de manière générale le type d' EC2 instances pouvant être créées et les paramètres relatifs aux instances au fur et à mesure de leur création.
Le bin packing est une pratique qui consiste à utiliser une plus grande partie des ressources de l'instance en répartissant davantage de charges de travail sur un nombre réduit d'instances de taille optimale. Bien que cela contribue à réduire vos coûts de calcul en provisionnant uniquement les ressources utilisées par vos charges de travail, cela comporte un compromis. Le démarrage de nouvelles charges de travail peut prendre plus de temps car de la capacité doit être ajoutée au cluster, en particulier lors d'événements de grande envergure. Tenez compte de l'équilibre entre l'optimisation des coûts, les performances et la disponibilité lors de la configuration de l'emballage en bacs.
Karpenter peut effectuer une surveillance continue et un binpack afin d'améliorer l'utilisation des ressources des instances et de réduire vos coûts de calcul. Karpenter peut également sélectionner un nœud de travail plus rentable pour votre charge de travail. Cela peut être réalisé en activant l'indicateur « consolidation » sur true dans le fournisseur (exemple d'extrait de code ci-dessous). L'exemple ci-dessous montre un exemple de fournisseur qui permet la consolidation. Au moment de la rédaction de ce guide, Karpenter ne remplacera pas une instance Spot en cours d'exécution par une instance Spot moins chère. Pour plus de détails sur la consolidation de Karpenter, consultez ce blog
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: enable-binpacking spec: consolidation: enabled: true
Pour les charges de travail susceptibles de ne pas être interruptibles, par exemple les tâches par lots de longue durée sans point de contrôle, pensez à annoter les pods avec l'annotation. do-not-evict En refusant l'expulsion des modules, vous dites à Karpenter qu'il ne doit pas supprimer volontairement les nœuds contenant ce module. Toutefois, si un do-not-evict pod est ajouté à un nœud alors que celui-ci se vide, les pods restants seront tout de même expulsés, mais ce pod bloquera la terminaison jusqu'à ce qu'il soit retiré. Dans les deux cas, le nœud sera bouclé pour empêcher que des travaux supplémentaires ne soient planifiés sur le nœud. Vous trouverez ci-dessous un exemple montrant comment définir l'annotation :
apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "karpenter.sh/do-not-evict": "true" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80
Supprimez les nœuds sous-utilisés en ajustant les paramètres du Cluster Autoscaler
L'utilisation des nœuds est définie comme la somme des ressources demandées divisée par la capacité. Par défaut, scale-down-utilization-threshold il est défini sur 50 %. Ce paramètre peut être utilisé conjointement avec etscale-down-unneeded-time, qui détermine la durée pendant laquelle un nœud doit être inutile avant de pouvoir être réduit. La valeur par défaut est de 10 minutes. Les pods toujours en cours d'exécution sur un nœud réduit seront planifiés sur d'autres nœuds par kube-scheduler. L'ajustement de ces paramètres peut aider à supprimer les nœuds sous-utilisés, mais il est important de tester d'abord ces valeurs afin de ne pas forcer le cluster à se réduire prématurément.
Vous pouvez empêcher la réduction de la taille en veillant à ce que les pods dont l'expulsion coûte cher soient protégés par une étiquette reconnue par le Cluster Autoscaler. Pour ce faire, assurez-vous que les pods dont l'expulsion coûte cher comportent l'annotationcluster-autoscaler.kubernetes.io/safe-to-evict=false. Voici un exemple de fichier yaml pour définir l'annotation :
apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80
Étiquetez les nœuds avec Cluster Autoscaler et Karpenter
Les balises de ressources AWS sont utilisées pour organiser vos ressources et pour suivre vos coûts AWS de manière détaillée. Ils ne sont pas directement corrélés aux étiquettes Kubernetes pour le suivi des coûts. Il est recommandé de commencer par l'étiquetage des ressources Kubernetes et d'utiliser des outils tels que Kubecost pour obtenir des rapports sur les coûts d'infrastructure basés sur les étiquettes Kubernetes
Les nœuds de travail doivent disposer de balises pour afficher les informations de facturation dans AWS Cost Explorer. Avec Cluster Autoscaler, balisez vos nœuds de travail au sein d'un groupe de nœuds gérés à l'aide d'un modèle de lancement. Pour les groupes de nœuds autogérés, balisez vos instances à l'aide du groupe de dimensionnement EC2 automatique. Pour les instances mises en service par Karpenter, balisez-les à l'aide de spec.tags dans
Clusters à locataires multiples
Lorsque vous travaillez sur des clusters partagés par différentes équipes, vous risquez de ne pas avoir de visibilité sur les autres charges de travail exécutées sur le même nœud. Bien que les demandes de ressources puissent aider à isoler certains problèmes liés aux « voisins bruyants », tels que le partage du processeur, elles peuvent ne pas isoler toutes les limites des ressources, telles que I/O l'épuisement du disque. Toutes les ressources consommables d'une charge de travail ne peuvent pas être isolées ou limitées. Les charges de travail qui consomment des ressources partagées à des taux plus élevés que les autres charges de travail doivent être isolées en fonction des entorses
L'isolation des charges de travail au niveau d'un nœud peut s'avérer plus coûteuse, mais il est possible de planifier des BestEffort
Les clusters partagés peuvent également être soumis à des contraintes de ressources au niveau du cluster, telles que l'épuisement des adresses IP, les limites de service Kubernetes ou les demandes de dimensionnement des API. Vous devriez consulter le guide des meilleures pratiques d'évolutivité pour vous assurer que vos clusters respectent ces limites.
Vous pouvez isoler les ressources au niveau d'un espace de noms ou d'un approvisionneur Karpenter. Les quotas de ressources
Les fournisseurs Karpenter peuvent définir des limites sur certaines des ressources consommables
Mise à l'échelle automatique planifiée
Il se peut que vous deviez réduire la taille de vos clusters le week-end et en dehors des heures de bureau. Cela est particulièrement pertinent pour les clusters de test et non liés à la production pour lesquels vous souhaitez réduire à zéro lorsqu'ils ne sont pas utilisés. Des solutions telles que cluster-turndown peuvent réduire le
Optimisation des types de capacité de calcul
Après avoir optimisé la capacité de calcul totale de votre cluster et utilisé le bin packing, vous devez examiner le type de calcul que vous avez fourni dans vos clusters et le mode de paiement de ces ressources. AWS propose des plans d'économies de calcul
-
Spot
-
Savings Plans
-
À la demande
-
Fargate
Chaque type de capacité comporte des compromis différents en termes de frais de gestion, de disponibilité et d'engagements à long terme, et vous devrez choisir celui qui convient le mieux à votre environnement. Aucun environnement ne doit reposer sur un seul type de capacité et vous pouvez combiner plusieurs types d'exécution dans un seul cluster afin d'optimiser les exigences et les coûts de charge de travail spécifiques.
Spot
Le type de capacité ponctuelle
Le calcul ponctuel doit utiliser une grande variété de types d'instances afin de réduire le risque de ne pas disposer de capacité ponctuelle disponible. Les interruptions d'instance doivent être gérées pour arrêter les nœuds en toute sécurité. Les nœuds approvisionnés avec Karpenter ou faisant partie d'un groupe de nœuds gérés prennent automatiquement en charge les notifications d'interruption d'instance. Si vous utilisez des nœuds autogérés, vous devrez exécuter le gestionnaire de terminaison de nœuds
Il est possible d'équilibrer les instances ponctuelles et à la demande dans un seul cluster. Avec Karpenter, vous pouvez créer des approvisionneurs pondérés afin de trouver un équilibre entre les
Voici un exemple d'utilisation de Karpenter pour prioriser les instances Spot par rapport aux instances à la demande. Lorsque vous créez un fournisseur, vous pouvez spécifier Spot, On-Demand ou les deux (comme indiqué ci-dessous). Lorsque vous spécifiez les deux, et si le pod ne précise pas explicitement s'il doit utiliser Spot ou On-Demand, Karpenter donne la priorité à Spot lorsqu'il approvisionne un nœud avec une stratégie d'allocation. price-capacity-optimization
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: spot-prioritized
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
Savings Plans, instances réservées et AWS EDP
Vous pouvez réduire vos dépenses informatiques en utilisant un plan d'économies de calcul
Un plan d'économies de calcul peut réduire vos EC2 coûts jusqu'à 66 % sans nécessiter d'engagement quant aux types d'instances, aux familles ou aux régions que vous souhaitez utiliser. Les économies sont automatiquement appliquées aux instances lorsque vous les utilisez.
EC2 Instance Savings Plans permet de réaliser jusqu'à 72 % d'économies sur le calcul avec un engagement d'utilisation dans une région et une EC2 famille spécifiques, par exemple les instances de la famille C. Vous pouvez transférer l'utilisation vers n'importe quelle zone de la région, utiliser n'importe quelle génération de la famille d'instances, par exemple c5 ou c6, et utiliser n'importe quelle taille d'instance au sein de la famille. La réduction sera automatiquement appliquée à toute instance de votre compte correspondant aux critères du plan d'épargne.
Les instances réservées
Les clients ont également la possibilité de souscrire un contrat d'entreprise avec AWS. Les contrats d’entreprise offrent aux clients la possibilité de personnaliser les accords qui répondent le mieux à leurs besoins. Les clients peuvent bénéficier de remises sur les tarifs basés sur le programme AWS EDP (Enterprise Discount Program). Pour plus d'informations sur les contrats d'entreprise, veuillez contacter votre représentant commercial AWS.
À la demande
Les EC2 instances à la demande présentent l'avantage d'une disponibilité sans interruption, par rapport aux instances ponctuelles, et de l'absence d'engagement à long terme, par rapport aux plans d'épargne. Si vous souhaitez réduire les coûts d'un cluster, vous devez réduire votre utilisation des EC2 instances à la demande.
Après avoir optimisé vos exigences en matière de charge de travail, vous devriez être en mesure de calculer une capacité minimale et maximale pour vos clusters. Ce chiffre peut changer au fil du temps, mais il diminue rarement. Envisagez d'utiliser un Savings Plan pour tout ce qui est inférieur au minimum, et optez pour une capacité qui n'affectera pas la disponibilité de votre application. Tout autre élément qui ne peut pas être utilisé en permanence ou qui est requis pour des raisons de disponibilité peut être utilisé à la demande.
Comme indiqué dans cette section, le meilleur moyen de réduire votre consommation est de consommer moins de ressources et d'utiliser au maximum les ressources que vous fournissez. Avec le Cluster Autoscaler, vous pouvez supprimer les nœuds sous-utilisés à l'aide du paramètre. scale-down-utilization-threshold Avec Karpenter, il est recommandé d'activer la consolidation.
Pour identifier manuellement les types d' EC2 instances qui peuvent être utilisés avec vos charges de travail, vous devez utiliser ec2-instance-selector
ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \ -r us-east-1 --service eks c5.large c5a.large c5ad.large c5d.large c6a.large c6i.large t2.medium t3.medium t3a.medium
Pour les environnements non liés à la production, vous pouvez automatiquement réduire la taille des clusters pendant les heures non utilisées, telles que la nuit et le week-end. Le cluster-turndown
Ordinateur Fargate
Le calcul Fargate est une option de calcul entièrement gérée pour les clusters EKS. Il permet d'isoler les pods en planifiant un pod par nœud dans un cluster Kubernetes. Il vous permet de dimensionner vos nœuds de calcul en fonction des besoins en CPU et en RAM de votre charge de travail afin de contrôler étroitement l'utilisation de la charge de travail dans un cluster.
Fargate peut faire évoluer des charges de travail allant de 2,5 vCPU avec 0,5 Go de mémoire à 16 vCPU avec 120 Go de mémoire. Le nombre de variations de taille des pods disponibles est limité et vous devez comprendre comment votre charge de travail s'adapte le mieux à une configuration Fargate. Par exemple, si votre charge de travail nécessite 1 vCPU avec 0,5 Go de mémoire, le plus petit pod Fargate sera un vCPU avec 2 Go de mémoire.
Bien que Fargate présente de nombreux avantages, tels que l' EC2 absence de gestion d'instance ou de système d'exploitation, il peut nécessiter une capacité de calcul supérieure à celle des instances EC2 traditionnelles, car chaque pod déployé est isolé en tant que nœud distinct dans le cluster. Cela nécessite davantage de duplication pour des éléments tels que le Kubelet, les agents de journalisation et tout ce DaemonSets que vous déployez généralement sur un nœud. DaemonSets ne sont pas pris en charge dans Fargate et ils devront être convertis en pods « `sidecars » et exécutés en même temps que l'application.
Fargate ne peut pas tirer parti du bin packing ou du surprovisionnement du processeur, car la limite de la charge de travail est un nœud qui n'est pas extensible ou partageable entre les charges de travail. Fargate EC2 vous permettra de gagner du temps dans la gestion des instances, ce qui a un coût en soi, mais les coûts liés au processeur et à la mémoire peuvent être plus élevés que ceux EC2 des autres types de capacité. Les modules Fargate peuvent tirer parti d'un plan d'économies de calcul pour réduire les coûts à la demande.
Optimisation de l'utilisation du calcul
Une autre façon d'économiser de l'argent sur votre infrastructure informatique consiste à utiliser un calcul plus efficace pour la charge de travail. Cela peut être dû à des solutions informatiques à usage général plus performantes, comme les processeurs Graviton
EKS est capable d'exécuter des clusters à architecture mixte (par exemple amd64 et arm64) et si vos conteneurs sont compilés pour plusieurs architectures, vous pouvez tirer parti des processeurs Graviton avec Karpenter en autorisant les deux architectures dans votre fournisseur. Pour maintenir des performances constantes, il est toutefois recommandé de conserver chaque charge de travail sur une architecture informatique unique et de n'utiliser une architecture différente que si aucune capacité supplémentaire n'est disponible.
Les fournisseurs peuvent être configurés avec plusieurs architectures et les charges de travail peuvent également demander des architectures spécifiques dans leurs spécifications de charge de travail.
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: default spec: requirements: - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"]
Avec Cluster Autoscaler, vous devez créer un groupe de nœuds pour les instances Graviton et définir des tolérances de nœuds sur votre charge de travail
GPUs et FPGAs peut augmenter considérablement les performances de votre charge de travail, mais celle-ci devra être optimisée pour utiliser l'accélérateur. De nombreux types de charges de travail pour l'apprentissage automatique et l'intelligence artificielle peuvent être utilisés GPUs pour le calcul, et les instances peuvent être ajoutées à un cluster et montées dans une charge de travail à l'aide de demandes de ressources.
spec: template: spec: - containers: ... resources: limits: nvidia.com/gpu: "1"
Certains matériels GPU peuvent être partagés entre plusieurs charges de travail afin qu'un seul GPU puisse être provisionné et utilisé. Pour savoir comment configurer le partage de charge de travail par GPU, consultez le plug-in du périphérique GPU virtuel
