Évolutivité verticale de SQL Server en ligne dans Kubernetes

Cet article a été publié pour la première fois sur le blog d’Andrew Pruski. Elle a été republiée avec le crédit et le consentement de l’auteur.

L’une des nouvelles fonctionnalités de Kubernetes v1.33 est la possibilité de redimensionner les ressources CPU et mémoire pour les conteneurs en ligne, sans avoir à recréer le pod dans lequel le conteneur s’exécute. Auparavant, lors de l’ajustement des ressources d’un pod, Kubernetes supprimait le pod existant et en créait un nouveau via un contrôleur.

Bien que ce ne soit pas un problème pour les applications qui peuvent avoir plusieurs répliques en cours d’exécution, pour SQL Server, cela provoquerait une interruption car nous n’avons (généralement) qu’un seul pod exécutant SQL Server dans un statefulset. Voyons cela en action.

Tout d’abord, nous allons déployer ce simple jeu d’état sur Kubernetes : 

L’important ici réside dans les paramètres du processeur et de la mémoire : 

Remarque : Vous avez peut-être remarqué que les limites et les demandes ici sont de la même valeur. Il s’agit de définir une qualité de service « garantie » pour le pod… c’est une bonne pratique recommandée pour SQL Server dans Kubernetes. Vous trouverez plus d’informations dans cet article.

Appliquons ce manifeste : 

Par le passé, nous devions modifier notre état pour augmenter ces valeurs : 

Cela recréerait le pod avec les nouvelles limites/demandes : 

Mais à partir de Kubernetes v1.33, nous pouvons faire évoluer les pods sans redémarrage !