ECI prend en charge les instances spot. Utilisez ces instances pour des jobs de courte durée et certaines applications sans état hautement évolutives et tolérantes aux pannes afin de réduire les coûts. Cette rubrique explique comment créer un pod ECI spot dans un cluster Kubernetes.
Informations générales
Une instance preemptible est une ressource de calcul peu coûteuse, basée sur un système d'enchères. Enchérissez sur les ressources inactives disponibles sur Alibaba Cloud pour exécuter vos conteneurs. Le système récupère ces ressources si votre enchère devient inférieure au prix actuel du marché ou si l'inventaire des ressources est insuffisant.
Les instances preemptibles conviennent aux jobs de courte durée et aux applications sans état hautement évolutives et tolérantes aux pannes, telles que les services web à mise à l'échelle élastique, le rendu d'images, l'analyse de big data et le calcul parallèle à grande échelle. Plus votre application est distribuée, évolutive et tolérante aux pannes, plus vous réalisez d'économies et augmentez le débit en utilisant des instances preemptibles. Pour plus d'informations, consultez la page Qu'est-ce qu'une instance preemptible ?.
Concepts clés
Avant de créer une instance preemptible, familiarisez-vous avec les concepts suivants :
-
Méthode de facturation
Le prix du marché d'une instance preemptible fluctue selon l'offre et la demande. Lors de la création, spécifiez une politique d'enchère. Si votre enchère est supérieure au prix du marché en temps réel pour le type d'instance spécifié et que l'inventaire est suffisant, la création aboutit. Après sa création, l'instance est facturée au prix du marché en vigueur au moment de l'achat pendant sa période de protection (1 heure par défaut). À l'issue de cette période, l'instance est facturée au prix du marché en temps réel.
RemarqueLes instances preemptibles sont proposées à tarif réduit par rapport aux instances à la demande. Le prix réel fluctue selon l'offre et la demande, et la facturation s'applique à la durée d'utilisation effective. Pour plus d'informations, consultez la page Facturation des instances preemptibles.
-
Mécanisme de récupération
Après la fin de la période de protection, le système vérifie automatiquement toutes les 5 minutes le prix du marché et l'inventaire du type d'instance. Si le prix du marché dépasse à tout moment votre enchère ou si l'inventaire du type d'instance est insuffisant, le système libère l'instance preemptible.
RemarqueEnviron 3 minutes avant la récupération des ressources, le système génère un événement indiquant que l'instance est sur le point d'être libérée.
Une fois les ressources récupérées, la facturation de l'instance s'arrête. Les informations relatives à l'instance sont conservées et son statut passe à Expired.
Remarques d'utilisation
Lorsque vous utilisez des instances preemptibles, tenez compte des points suivants :
-
Choisissez un type d'instance approprié et placez une enchère raisonnable.
Appelez les opérations OpenAPI d'ECS pour consulter les informations sur les instances preemptibles des 30 derniers jours, ce qui vous aidera à sélectionner un type d'instance et à placer une enchère. Les opérations pertinentes sont les suivantes :
DescribeSpotPriceHistory : interroge l'historique des prix des instances.
DescribeSpotAdvice : interroge des informations telles que le taux moyen de libération et le taux de réduction moyen des instances.
ImportantDéfinissez une enchère suffisamment élevée pour tenir compte des fluctuations du prix du marché et correspondant à vos attentes en matière de coûts métier. Cela augmente les chances de créer avec succès une instance preemptible et empêche sa libération due aux variations de prix, vous permettant ainsi de répondre aux besoins métier tout en réalisant des économies.
Stockez vos données importantes sur des supports de stockage non affectés par la libération des instances preemptibles, tels que des disques cloud (avec l'option de libération avec l'instance désactivée) ou NAS.
Méthodes de création
Créez une instance de conteneur élastique preemptible en spécifiant un type d'instance ECS ou en spécifiant les vCPU et la mémoire :
-
Spécifier un type d'instance ECS
La facturation est basée sur le prix du marché à la demande du type d'instance spécifié et sur la réduction en temps réel.
-
Spécifier les vCPU et la mémoire
Cette méthode produit le même effet que la spécification d'un type d'instance ECS. Le système fait correspondre automatiquement un type d'instance ECS répondant aux exigences en matière de ressources et de prix. La facturation est basée sur le prix du marché de ce type d'instance correspondant. Autrement dit, la réduction s'applique au prix du marché du type d'instance ECS correspondant, et non au prix à la demande des vCPU et de la mémoire correspondants.
Cette méthode prend uniquement en charge les spécifications de 2 vCPU ou plus. Le tableau ci-dessous répertorie les spécifications de vCPU et de mémoire prises en charge. Si vous spécifiez une configuration non prise en charge, le système l'arrondit automatiquement à la spécification prise en charge supérieure suivante.
vCPU
Mémoire (Go)
2
2, 4, 8, 16
4
4, 8, 16, 32
8
8, 16, 32, 64
12
12, 24, 48, 96
16
16, 32, 64, 128
24
24, 48, 96, 192
32
32, 64, 128, 256
52
96, 192, 384
64
128, 256, 512
Configuration
Créez une instance spot en ajoutant des annotations aux métadonnées du pod. Le tableau suivant décrit les annotations pertinentes.
|
Annotation |
Valeur d'exemple |
Obligatoire |
Description |
|
k8s.aliyun.com/eci-spot-strategy |
SpotAsPriceGo |
Oui |
La stratégie d'enchère pour l'instance spot. Valeurs possibles :
|
|
k8s.aliyun.com/eci-spot-price-limit |
"0.5" |
Non |
Le prix horaire maximal pour l'instance spot. Vous pouvez spécifier une valeur avec jusqu'à trois décimales. Cette annotation n'est valide que lorsque |
|
k8s.aliyun.com/eci-spot-duration |
"0" |
Non |
La période de protection pour l'instance spot, en heures. La valeur par défaut est 1. Une valeur de 0 signifie qu'il n'y a pas de période de protection. |
|
k8s.aliyun.com/eci-spot-fallback |
"true" |
Non |
Indique s'il faut créer une instance à la demande si une instance spot ne peut pas être créée en raison d'un inventaire insuffisant. La valeur par défaut est false. |
Ajoutez les annotations sous les métadonnées du pod. Par exemple, lors de la création d'un Job, ajoutez l'annotation sous
spec>template>metadata.Les annotations liées à Elastic Container Instance ne sont appliquées que lors de la création d'un pod. L'ajout ou la modification de ces annotations sur un pod existant n'aura aucun effet.
Exemple 1 : Spécifier un type d'instance ECS et utiliser SpotWithPriceLimit
Exemple 2 : Spécifier les vCPU et la mémoire et utiliser SpotAsPriceGo
Exemple 3 : Définir aucune période de protection
Exemple 4 : Basculer vers une instance à la demande
Détails de la récupération
Après la création d'une instance spot, elle fonctionne normalement pendant sa période de protection. À l'expiration de la période de protection, l'instance spot est récupérée si le prix du marché dépasse votre enchère ou si l'inventaire des ressources est insuffisant. Cette section décrit les événements et les statuts de pod liés à la récupération des instances spot.
-
Événement de pré-libération
Environ trois minutes avant la récupération d'une instance spot, un événement
SpotToBeReleasedest généré.ImportantECI vous informe via les événements Kubernetes que l'instance spot sera libérée. Pendant ce temps, prenez des mesures pour éviter les interruptions d'activité dues à la récupération de l'instance. Pour plus d'informations, consultez la section Arrêt gracieux.
-
Exécutez la commande
kubectl describepour afficher les informations détaillées sur le pod. Vous pouvez voir l'événement de pré-libération dans la sectionEventsde la sortie. Voici un exemple :Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning SpotToBeReleased 3m32s kubelet, eci Spot ECI will be released in 3 minutes -
Exécutez la commande
kubectl get eventspour afficher les informations sur les événements. Vous pouvez voir l'événement de pré-libération dans la sortie. Voici un exemple :LAST SEEN TYPE REASON OBJECT MESSAGE 3m39s Warning SpotToBeReleased pod/pi-frmr8 Spot ECI will be released in 3 minutes
-
-
Statut du pod après récupération
Après la récupération d'une instance spot, ses informations sont conservées, mais son statut passe à
Failedet la raison estBidFailed.-
Exécutez la commande
kubectl get podpour afficher les informations sur le pod. Vous pouvez constater que le statut du pod a changé dans la sortie. Voici un exemple :NAME READY STATUS RESTARTS AGE pi-frmr8 1/1 BidFailed 0 3h5m -
Exécutez la commande
kubectl describepour afficher les informations détaillées sur le pod. Vous pouvez voir les informations sur le statut du pod dans la sortie. Voici un exemple :Status: Failed Reason: BidFailed Message: The pod is spot instance, and have been released at 2020-04-08T12:36Z
-
Arrêt gracieux
Environ trois minutes avant la récupération d'une instance spot, un événement SpotToBeReleased est généré et le champ ContainerInstanceExpired dans les conditions du pod est défini sur true. Utilisez ces mécanismes de notification pour mettre en œuvre un arrêt gracieux et une rotation des pods, ce qui minimise les interruptions d'activité dues à la récupération des instances spot.
Virtual Node prend en charge l'arrêt gracieux des instances spot ECI. Ajoutez l'annotation k8s.aliyun.com/eci-spot-release-strategy: api-evict à votre pod ECI. Lorsque le nœud virtuel reçoit un événement SpotToBeReleased, il appelle l'API d'éviction pour évincer l'instance spot.
Pour prendre en charge les notifications d'interruption via les conditions de pod et l'éviction via l'API d'éviction, mettez à niveau ACK Virtual Node vers la version v2.11.0 ou ultérieure. Pour plus d'informations, consultez la page ACK Virtual Node.
Une éviction initiée par l'API respecte vos configurations PodDisruptionBudget (PDB) et terminationGracePeriodSeconds. La création d'un objet Eviction à l'aide de l'API est similaire à l'exécution d'une opération DELETE contrôlée par une politique sur un pod. Le processus est le suivant :
-
Requête API
Le nœud virtuel reçoit un événement
SpotToBeReleasedet appelle l'API d'éviction. -
Vérification PDB
Le serveur API valide le PodDisruptionBudget associé au pod cible.
-
Exécution de l'éviction
Si le serveur API autorise l'éviction, le pod est supprimé comme suit :
La ressource pod dans le serveur API est mise à jour avec un horodatage de suppression, après quoi le serveur API considère que le pod est en cours de terminaison. La ressource pod est également marquée avec la période de grâce configurée.
Le kubelet sur le nœud où le pod est en cours d'exécution remarque que la ressource pod est marquée pour la terminaison et commence à arrêter gracieusement le pod local.
Pendant que le kubelet arrête le pod, le plan de contrôle supprime le pod des objets Endpoint et EndpointSlice. Par conséquent, les contrôleurs ne considèrent plus le pod comme un objet valide.
À l'expiration de la période de grâce du pod, le kubelet termine de force le pod local.
Le kubelet informe le serveur API de supprimer la ressource pod.
Le serveur API supprime la ressource pod.
-
Réconciliation de la charge de travail
Si le pod cible est géré par un contrôleur (tel qu'un ReplicaSet, un StatefulSet ou un Job tolérant aux pannes, une sparkApplication ou un Workflow), le contrôleur crée généralement un nouveau pod pour remplacer celui qui a été évincé.
Si le PodDisruptionBudget est mal configuré, ou s'il y a beaucoup de pods qui ne sont pas dans l'état Ready lorsque l'API d'éviction est appelée, le processus d'éviction peut être bloqué. Si l'éviction n'est pas terminée avant l'expiration de l'instance spot, l'instance est récupérée immédiatement.