Nous avons un cluster Kubernetes simple à 3 nœuds sur Azure Kubernetes Service (AKS). La plupart du temps, cette infrastructure est plus que suffisante, mais il arrive que nous devions être en mesure de passer à 50 instances d'un service pendant quelques heures, puis de revenir en arrière.
Combiner AKS avec Azure Container Instances (ACI) via le Virtual Kubelet semble être une solution idéale pour ce scénario.
Du point de vue de la gestion des coûts, nous préférerions que les choses fonctionnent sur notre VMs s'il y a de la capacité disponible. Nous les payons déjà, il est donc inutile de payer aussi des instances ACI.
Question 1
Si nous effectuons une mise à l'échelle via le Kubelet virtuel en utilisant ACI, comment Kubernetes choisit-il les pods à mettre à l'échelle ? arrière plus tard ? Son approche est-elle cohérente avec notre exigence de gestion des coûts - c'est-à-dire que les nœuds "authentiques" sont préférés - ou pourrait-on la rendre cohérente ?
Question 2
Scénario : nous exécutons deux applications - "App1" et "App2" - dans Kubernetes. App1 est celle qui entraîne le besoin de passer à 50 instances via ACI ; App2 s'exécute sur les noeuds "authentiques".
Disons que nous utilisons ensuite Helm pour mettre à jour App2 . Quand il redémarre, je suppose que Kubernetes podría le placer sur une instance ACI puisque nous sommes à l'échelle à ce stade.
Par la suite, le besoin des 50 instances de App1 s'en va et on réduit à nouveau.
App2 s'exécuteraient encore sur des instances ACI alors que nous préférerions qu'elles soient à nouveau sur des nœuds authentiques à ce stade.
Kubernetes pourrait-il gérer cela conformément à nos exigences en matière de gestion des coûts, ou un encadrement supplémentaire est-il nécessaire ?
