Mise en oeuvre d’un cluster Kubernetes 1.14 avec des noeuds Windows via AKS-Engine …
AKS Engine fournit un outil pratique pour démarrer rapidement des clusters Kubernetes sur Azure. En s’appuyant sur ARM (Azure Resource Manager), AKS Engine permet de créer, détruire et maintenir des clusters dotés de ressources de base dans Azure. AKS Engine est également la bibliothèque utilisée par AKS pour effectuer ces opérations afin de fournir des implémentations de services gérés :
Je récupère donc le binaire AKS-Engine pour Linux depuis le dépôt dédié sur Github :
Et je pars du template JSON suivant qui va me générer un cluster Kubernetes 1.14 avec des noeuds Windows Server Core :
avec d’autres exemples ici pour Windows Server :
Je lance donc le déploiement du cluster mixte (avec un noeud Maître Linux avec Ubuntu Server et des noeuds Windows Server Core) via le binaire AKS-Engine :
$ aks-engine deploy --subscription-id <your subscription ID> --client-id '<service principal client ID>' --client-secret '<service principal client secret>' --dns-prefix mask8swin -g RG-K8SWIN --location eastus2 --api-model examples/kubernetes.json
avec ce Resource Group dans Azure :
pour une architecture de ce type dans Azure et un service de LoadBalancing disponible comme dans l’ensemble des clusters AKS :
et je possède le fichier kubeconfig en JSON nécessaire pour invoquer les commandes dans le cluster Kubernetes :
Je lance une instance Ubuntu dans Outscale pour y faire tourner un serveur Rancher :
Je vais importer ce cluster AKS dans ce serveur Rancher :
Le cluster est alors importé :
Dans Grafana, je ne vois que les infos relatives au noeud Linux pour le moment …
Je peux “labelliser” les noeuds Windows pour les selectionner spécifiquement lors de l’exécution de certains POD :
Il est possible d’augmenter le nombre de Noeuds Windows Server dans ce cluster AKS via le binaire AKS-Engine :
$ aks-engine scale --subscription-id <your subscription ID> --resource-group RG-K8SWIN --location eastus2 \
--client-id '<service principal client ID>' \
--client-secret '<service principal client secret>' \
--deployment-dir _output \
--new-node-count 5 \
--node-pool windowspool1 --master-FQDN <AKS Master FQDN>
Ces nouveaux noeuds Windows Server Core sont alors disponibles et je peux leur attribuer le fameux label :
J’effectue un test de déploiement d’une image Windows Server Core avec un serveur web en exécution via Powershell :
et ces deux manifests YAML (déploiement et service):
Une adresse IP publique m’a bien été attribuée pour le loadbalancer :
Mise à l’échelle automatique ici du déploiement, avec un nombre de pods compris entre 5 et 10, aucune utilisation cible du CPU n’étant spécifiée, une politique de mise à l’échelle automatique par défaut sera utilisée :
Les pods sont répartis sur l’ensemble des noeuds Windows Server Core …
On peut réaliser un déploiement de ce type depuis la console de Rancher :
en y spécifiant le label selector :
Le déploiement est effectif :
avec l’id du container via l’adresse IP publique pour le load balancer …*
Pour conclure, Kubernetes 1.14 a souhaité la bienvenue aux containers Windows mais même si le support des containers Windows par l’orchestrateur open source est désormais stable, il comporte encore quelques limites …
AKS-Engine est donc un outil open source de Microsoft, disponible sur GitHub et en ligne de commande qui permet de générer le template Azure Resource Manager, qui permettra le déploiement du clusters (masters et agents) ainsi que l’installation et la configuration de Kubernetes (y compris avec des noeuds Windows) …
A suivre !
