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 préemptible est une ressource de calcul peu coûteuse, basée sur un système d'enchères. Enchérissez sur les ressources inutilisées d'Alibaba Cloud pour exécuter vos conteneurs. Le système récupère ces ressources lorsque votre enchère devient inférieure au prix du marché actuel ou lorsque l'inventaire des ressources est insuffisant.
Les instances préemptibles 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 préemptibles. Pour plus d'informations, consultez la rubrique Qu'est-ce qu'une instance préemptible ?.
Concepts clés
Avant de créer une instance préemptible, familiarisez-vous avec les concepts suivants :
-
Méthode de facturation
Le prix du marché d'une instance préemptible 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). Une fois la période de protection terminée, l'instance est facturée au prix du marché en temps réel.
RemarqueLes instances préemptibles sont proposées à un tarif réduit par rapport aux instances à la demande. Le prix réel fluctue selon l'offre et la demande, et vous êtes facturé pour la durée d'utilisation effective. Pour plus d'informations, consultez la rubrique Facturation des instances préemptibles.
-
Mécanisme de récupération
Une fois la période de protection terminée, 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 préemptible.
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 préemptibles, 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 interroger les informations sur les instances préemptibles des 30 derniers jours afin de sélectionner un type d'instance et de 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 remise moyen des instances.
ImportantDéfinissez une enchère suffisamment élevée pour tenir compte des fluctuations du prix du marché et correspondant à vos attentes budgétaires. Cela augmente les chances de créer avec succès une instance préemptible 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 préemptibles, tels que les 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 préemptible 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 remise 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 associe 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 associé. En d'autres termes, la remise s'applique au prix du marché du type d'instance ECS associé, 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 suivant répertorie les spécifications de vCPU et de mémoire prises en charge. Si vous spécifiez une spécification non prise en charge, le système l'arrondit automatiquement à la spécification prise en charge suivante.
vCPU
Mémoire (GiB)
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 des 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 : Ne définir aucune période de protection
Exemple 4 : Revenir à une instance à la demande
Détails de la récupération
Une fois une instance spot créée, 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 toute interruption de service due à 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
Une fois une instance spot récupérée, 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 de service 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 rubrique 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 de 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 de pod est également marquée avec la période de grâce configurée.
Le kubelet sur le nœud où le pod s'exécute remarque que la ressource de 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 de pod.
Le serveur API supprime la ressource de pod.
-
Réconciliation de la charge de travail
Si le pod cible est géré par un contrôleur (tel qu'un ReplicaSet, StatefulSet ou un Job tolérant aux pannes, sparkApplication ou 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.