Tout d’abord laissez-moi rappeler brièvement ce qu’est un plugin réseau (Network plugin).
Initialement dans Kubernetes, les pods n’ont pas d’interface réseau. Afin que ces pods puissent communiquer entre eux, il faut ajouter une couche de réseau avec ce fameux plugin réseau. Il existe différent plugins réseau pour Kubernetes qui gèrent le réseau différemment. Nous nous pencherons dans cet article plus spécifiquement sur “Kubenet” et “Azure CNI” pour AKS, le cluster managé d’Azure.
D’après Azure : "avec kubenet, seuls les nœuds reçoivent une adresse IP dans le sous-réseau de réseau virtuel."
On voit sur le schéma ci-dessous que seuls les nœuds reçoivent des adresses IP dans le sous-réseau du réseau virtuel. Il n'y a pas de communication directe entre les Pods, car ceux-ci sont dans un réseau virtuel appartenant au cluster mais qui n’est pas un subnet Azure. En fait, lorsqu’un pod veut communiquer avec un autre pod, le traffic va passer par un NAT géré par Kubenet.
En revanche, Azure CNI propose une autre approche.
D’après Azure : "avec Azure CNI, chaque pod reçoit une adresse IP dans le sous-réseau IP et peut communiquer directement avec d’autres pods et services."
L’avantage de ce type de configuration est que la sécurité du réseau se gère au niveau d’Azure et non pas au niveau dans le cluster. On peut donc ajouter des règles de sécurité réseau à l’aide de groupe de sécurité et ainsi autoriser ou non les services Azure à avoir accès aux services déployés dans le cluster.
En revanche, comme chaque pod reçoit une IP du sous réseau Azure défini, le plan d’adressage IP doit être défini à l’avance et laisse moins de place à l’imprévu.
Par défaut Azure déploie un cluster AKS avec un network Kubenet.
Pour un client, nous devions déployer un cluster Kubernetes privé dans Azure. Une de nos grosse contrainte était d’avoir une isolation entre les applications accessibles depuis internet et les applications accessibles depuis un VPN.
Pour répondre à ce besoin nous avons fait plusieurs choix :
Pour répondre au deuxième point, nous voulions descendre la sécurité et gérer le traffic via Azure (avec des NSG) et non plus dans Kubernetes.
Nous avons donc fait le choix d’une mise en réseau Azure CNI, en préparant notre plan d’adressage IP, faisant les calculs pour le bon nombre d’IP par sous réseaux, etc.
Les éléments de notre infrastructure devant être privés, nous utilisions pour chaque ressource un Private Link. Nous avons donc déployé un private link pour notre base de données et c’est là qu’intervient notre problème. En effet il nous était impossible de communiquer avec la base de données depuis le cluster. Après plusieurs recherches nous avons trouvé le problème qui n’est pas explicitement expliqué. Sur la documentation de “Private Link Service”, il est indiqué tout en bas de la page que “At this moment, PLS connectivity is broken if AzureCNI V2 is used in cluster. Azure networking team is working on supporting the feature.”
Nous avons donc été dans l’obligation de redéployer notre cluster avec Kubenet. Ce changement de stratégie nous a fait repartir de zero et nous avons par la même occasion du redéployer tous les services que nous avions déjà configuré dans l’ancien cluster (comme ArgoCD par exemple). Heureusement avec ArgoCD le redéploiement des outils à été très rapide.
Pour tout de même répondre à notre problématique de séparation réseau entre les applications nous avons fait le choix de mettre des network policy et donc de gérer la sécurité dans le cluster et non plus dans Azure. Pour en savoir plus sur la sécurité dans Kubernetes, voici un article qui explique comment gérer la sécurité dans Kubernetes.
En conclusion, on retiendra de cette expérience que les Private Link ne sont pas encore compatibles avec Azure CNI, et c’est toujours le cas au moment ou j’écris cet article.