Deploy enterprise grade AKS environments

Dans cet article, je souhaite présenter un exemple d'infrastructure de niveau entreprise, basé sur le modèle hub-and-spoke, pour héberger des environnements Kubernetes.

Architecture

Il y a beaucoup d'exemples sur Internet pour apprendre à construire rapidement un cluster AKS sur Azure, mais c'est souvent sans se soucier des problématiques de sécurité ou d'intégration dans l'entreprise. C'est bien pour faire des tests mais pas vraiment pour la production ou l'utilisation à grande échelle.

Avec cet exemple, je propose de construire une infrastructure avec un cluster AKS dédié pour chacun des environnements tout en contrôlant l'exposition des services et en utilisant un point de terminaison public unique et sécurisé.

Le point de terminaison public est mis en œuvre par une Azure Application Gateway qui est un équilibreur de charge L7 ; dans cet exemple, il est également protégé par un Web Application Firewall (WAF). Le Vnet auquel il appartient est également sécurisé par une protection DDOS.

Dernière chose avant de démarrer :

  • Vous pouvez cloner le projet depuis Github, l'ensemble de l'article est basé dessus
  • J'utilise Terraform pour provisionner les ressources. Je travaille régulièrement avec des fournisseurs d'infrastructure différents et j'apprécie cet outil, principalement pour son positionnement agnostique.
  • Les commandes sont faite pour une plateforme d'exécution Linux ou MacOS

Prérequis

Azure

Avoir accès à une souscription Azure avec un haut niveau de permission, idéalement le rôle de owner.

Outillage

Ces outils doivent être installés dans votre environnement :

Astuce: Il est possible de créer une image Docker contenant l'ensemble des prérequis pour avoir la garantie que tous les membres de votre équipe ainsi que votre outil de CI utilisent un environnement d'exécution identique.

Authentification Terraform pour Azure

Comme pour tout projet d'Infrastructure as Code, Terraform a besoin d'une identité technique pour intéragir avec l'API du fournisseur d'infrastructure, Azure dans le cadre de cet article.

Azure offre plusieurs méthodes d'authentification qui permettent à Terraform de déployer des ressources, l'une d'elles repose sur l'utilisation d'un Service Principal (SP).

La raison pour laquelle j'ai retenu cette méthode, c'est qu'elle ne nécessite pas de se logguer intéractivement avant d'exécuter le projet. Avec les autres méthodes (Azure CLI ou Cloud Shell), il faut se connecter à Azure avec az login ou Cloud Shell au préalable.

Suivre cette procédure pour configurer l'authentification Azure pour Terraform

Voici les étapes principales qu'elle contient :

  • Création d'un Service Principal en utilisant Azure CLI
  • Configuration de Terraform pour utiliser ce Service Principal
  • Configuration des permissions de ce Service Principal dans Azure AD

Backend Terraform

Le backend Terraform peut être créé avec Terraform, mais le fichier d'état correspondant ne sera pas stocké dans un stockage partagé parce qu'aucun backend n'est encore configuré, c'est le dilemne de l'oeuf et de la poule.

Oeuf ou poule ?

D'un autre côté, on le crée une fois et on a rarement besoin de le modifier ensuite. Nous allons donc le créer avec la CLI Azure.

Suivre cette procédure pour créer le backent Terraform sur Azure

Vault

Les projets d'Infrastructure as Code nécessitent de gérer des secrets, et c'est une bonne pratique d'utiliser un gestionnaire de secrets digne de ce nom. Nous allons donc provisionner un Azure Key Vault avant de créer notre infrastructure hub-and-spoke.

1$ cd terraform/vault
2$ terraform init
3$ terraform apply

Cette stack crée l'Azure Key Vault mais porte aussi la responsabilité de gérer les permissions des utilisateurs, groupes, applications de l'entreprise afin de consommer et/ou gérer les secrets, clés et certificats.


Déploiement de l'infrastructure

Dans ce projet d'exemple, chaque stack sera déployée dans un groupe de ressource dédié.

Selon votre façon de travailler, vous pouvez préférer avoir le backend et le Key Vault dans le même groupe de ressources Common, ou dans le groupe de ressources hub.

Il se peut aussi que vous n'ayez pas suffisamment d'autorisations pour créer un groupe de ressources dans votre souscription et que quelqu'un d'autre de l'équipe informatique vous les fournisse. Dans ces différents cas d'utilisation, vous devrez adapter un peu le code pour répondre à vos besoins/contraintes.

L'infrastructure qui va être déployée est divisé en deux stacks Terraform. Chacune de ces stacks contient un ensemble de ressources qui partagent un même cycle de vie.

La stack AKS

Elle implémente tout ce qui compose un environnement type et utilise les Terraform workspaces pour gérer de multiples instances d'environnements avec le même code.

Actuellement, la stack ne construit qu'un cluster AKS avec une Azure Container Registry, mais on pourrait imaginer d'instancier d'autres composants dans l'environnement (gérés ou non) comme des serveurs de base de données, de messaging ou de stockage par exemple.

Suivre cette procédure pour déployer le premier environnement AKS

Voici les étapes principales qu'elle contient :

  • Création les workspaces pour chaque environnement
  • Création des paires de clés SSH
  • Revue des variables du projet
  • Déploiement du premier environnement avec Terraform
  • Récupération des informations de connexion au cluster
  • Déploiement de l'ingress controller Nginx
  • Déploiement d'une application de démo dans le cluster
  • Vérification que tout fonctionne correctement

A ce stade nous avons un cluster AKS opérationnel, et un ingress controller qui permet l'exposition de l'application via un load balancer privé.

Vous pouvez importer le cluster dans Mirantis Lens pour contrôler, un outil graphique pratique et gratuit pour gérer vos clusters Kubernetes:

Mirantis Lens

La stack Hub

Elle implémente le hub qui contient toutes les ressources communes à l'ensemble des environnements comme la connectivité avec Internet ou le datacenter, la gestion des DNS, éventuellement un bastion, etc.

Suvire cette procédure pour déployer le hub

Voici les étapes principales qu'elle contient :

  • Revue des variables du projet
  • Déploiement du hub avec Terraform
  • Vérification que l'Application Gateway est correctement configurée

Nous disposons désormais d'un point d'accès public unique et sécurisé pour accéder aux applications déployées dans nos différents environnements. L'Application Gateway reçoit toutes les requêtes et les transmet au bon environnement en fonction des règles de routage que nous avons configurées. Ensuite, l'ingress controller prend le relais pour acheminer la requête vers le bon service au sein du cluster kubernetes en fonction des règles d'ingress.

Test de bout en bout

C'est le moment de tester si tout fonctionne de bout en bout comme espéré.

Récupérez l'IP publique de l'Application Gateway et accédez à l'application de démonstration déployée dans l'environnement de développement en appelant l'IP publique de l'Application Gateway.

Vous pouvez le faire directement depuis votre navigateur si vous utilisez un vrai DNS ou avec curl si vous utilisez un DNS factice comme moi. La chose la plus importante est que l'en-tête HTTP doit contenir le DNS correspondant à la fois à un listner de l'Application Gateway et à une règle d'ingress existante dans le cluster AKS cible :

1$ curl -H "Host: dev.linkbynet.com" 20.74.8.233

Résultat

Si vous obtenez la page d'accueil NGINX de notre application de démonstration, tout fonctionne bien, félicitations !


Conclusion

Avec ce projet nous avons couvert plusieurs sujets importants.

L'importance de la conception de l'infrastructure. Une infrastructure de niveau entreprise doit prendre en compte des considérations globales telles que :

  • Evolutivité et sécurité
  • Séparation des responsabilités
  • Provisionner mais surtout privilégier la facilité de maintenance dans le temps
  • La gestion des accès

Ce projet démontre également l'importance de coder l'infrastructure en utilisant des pratiques de développement. L'Infrastructure as Code, en particulier pour le cloud, rend l'infrastructure plus auditable, donc plus facile à maintenir, et facilite la collaboration et le partage au sein de l'entreprise.

Merci pour votre lecture. N'hésitez pas à me faire des commentaires et à me faire part de vos remarques pour m'aider à améliorer cet article/ce projet.