Use ECS instances during off-peak hours and use elastic container instances to handle traffic spikes in Knative - Container Service for Kubernetes

Exécutez les charges de travail Knative de base sur vos instances Elastic Compute Service (ECS) existantes et délestez automatiquement les pics de trafic vers des Elastic Container Instances (ECI), sans provisionner au préalable des machines virtuelles supplémentaires. Une ResourcePolicy contrôle la priorité de planification entre ces deux types de ressources : les instances ECS sont privilégiées en régime stable, tandis que les ECI absorbent le surplus. Lors de la mise à l'échelle descendante, les ECI sont libérées en premier.

Prérequis

Avant de commencer, assurez-vous d'avoir :

Déployé Knative dans votre cluster. Consultez les rubriques Déployer Knative dans un cluster ACK ou Déployer Knative dans un cluster ACK Serverless.

Une version de kube-scheduler compatible avec votre version Kubernetes :

Version Kubernetes	Version kube-scheduler
1.20	1.20.4-ack-7.0 ou ultérieure
1.22	1.22.15-ack-2.0 ou ultérieure
1.24	1.24.3-ack-2.0 ou ultérieure
1,26	1.26.3-ack-4.0 ou ultérieure
1,26 ou ultérieure	Toutes les versions

Déployé le composant ack-virtual-node. Ce composant est requis pour les Elastic Container Instances. Consultez la rubrique Déployer ack-virtual-node dans le cluster.
Obtenu un fichier kubeconfig et connecté kubectl au cluster. Consultez la rubrique Se connecter à votre cluster à l'aide de kubectl.

Limitations

Contrainte	Détails
Exclusion mutuelle avec le coût de suppression des pods	Vous ne pouvez pas utiliser la planification basée sur les priorités conjointement avec la fonctionnalité coût de suppression des pods.
Exclusion mutuelle avec la planification basée sur les ECI	Vous ne pouvez pas utiliser la planification basée sur les priorités conjointement avec la planification basée sur les Elastic Container Instances.
La mise à l'échelle descendante s'effectue au mieux	La ResourcePolicy utilise la stratégie `prefer` (BestEffort). La mise à l'échelle descendante ne garantit pas la suppression des pods dans un ordre de priorité strict.
Le paramètre `max` nécessite Kubernetes 1.22+ et le planificateur 5,0+	Le paramètre `max` n'est disponible que si votre cluster exécute Kubernetes 1.22 ou une version ultérieure, et que votre version du planificateur est 5,0 ou ultérieure.
Les pools de nœuds élastiques doivent être définis en unités sans `max`	Lorsque vous utilisez des pools de nœuds élastiques, incluez-les dans les unités, mais ne spécifiez pas le paramètre `max` pour ces unités.
Pods préexistants (planificateur < 5,0 ou Kubernetes 1.20 ou antérieur)	Les pods qui existaient avant la création de la ResourcePolicy sont prioritaires lors de la mise à l'échelle descendante.
Modification de la ResourcePolicy (planificateur < 6,1 ou Kubernetes 1.20 ou antérieur)	Ne modifiez pas la ResourcePolicy tant que tous les pods qu'elle sélectionne n'ont pas été supprimés.

Créer une ResourcePolicy pour une planification hybride ECS et ECI

Une ResourcePolicy cible un service Knative par étiquette et définit une liste ordonnée d'units. Chaque unité correspond à un type de ressource (ECS ou ECI) et peut éventuellement limiter le nombre de pods via le paramètre max. Le planificateur traite les unités dans l'ordre : lorsqu'une unité ECS est pleine ou qu'aucune capacité ECS n'est disponible, les pods sont délestés vers l'unité suivante.

Créez un service Knative.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    spec:
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

Créez une ResourcePolicy ciblant le service Knative helloworld-go. Les instances ECS ont la priorité la plus élevée. Les ECI servent de solution de secours : les pods y sont planifiés uniquement lorsque la capacité ECS est épuisée ou lorsque le nombre de pods sur une unité ECS atteint la limite max.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: xxx
  namespace: xxx
spec:
  selector:
    serving.knative.dev/service: helloworld-go  # Target Knative Service name
  strategy: prefer
  units:
  - resource: ecs
    max: 10           # Cap at 10 pods on this ECS node group
    nodeSelector:
      key2: value2
  - resource: ecs     # Secondary ECS node group (no cap)
    nodeSelector:
      key3: value3
  - resource: eci     # ECI absorbs overflow; released first during scale-in

La mise à l'échelle descendante suit l'ordre inverse des unités, dans la mesure du possible. Les ECI sont de préférence libérées en premier, mais un ordre strict n'est pas garanti.

Étapes suivantes

Pour plus d'informations sur les paramètres de planification des ressources basée sur les priorités, consultez la rubrique Configurer la planification des ressources basée sur les priorités.