Aventure dans le réseautage multinuage avec Kubernetes et Tungsten Fabric

Il ne reste plus que quelques semaines avant KubeCon, et ma présentation imminente; j’ai donc décidé de me lancer dans une petite aventure et d’essayer de réunir en réseau, avec Tungsten Fabric, deux grappes Kubernetes différentes, dans le but de faire une démonstration, en direct, au Sommet des Développeurs Tungsten Fabric.

La démo a été conçue pour illustrer simplement des cas généraux d’utilisation de nuages hybrides et/ou multiples, lors de connexions entre deux réseaux distincts, dans un contexte Kubernetes. Ce cas est particulièrement intéressant dans le cadre de la migration d’un ensemble de services, vers Kubernetes, tout en maintenant le lien aux autres services dans le réseau hérité. Je savais que Tungsten Fabric (TF) soutenait la connectivité entre différents sites avec Border Gateway Protocol (BGP) mais je n’avais jamais installé ni utilisé Tungsten Fabric. Je m’attendais à ce que cette expérience me fasse vivre un « baptême du feu » alors j’ai tenté l’aventure !

Comme pour la majorité de l’expérimentation que j’ai effectuée, je savais que l’automatisation allait me servir de boussole dans mon cheminement afin de produire les résultats désirés. Ce n’est que par l’automatisation qu’il est possible de reproduire ma configuration de façon constante et garantir que ma démo se déroule sans incident. Avec l’expérience acquise dans l’automatisation de Kubernetes (K8s) chez CloudOps, j’avais déjà un point de départ. Ceci dit, notre automatisation est quelque peu draconienne en matière de sécurité de réseau et de « qui peut parler à qui ». Comme je ne connaissais pas les exigences de connectivité dont TF aurait besoin, j’ai décidé de prendre du recul et de mettre en œuvre un déploiement K8s extrêmement minimaliste afin de réduire le nombre de pièces mobiles.

Après un peu de recherche, j’ai découvert les deux références suivantes qui traitaient de la configuration que j’essayais d’atteindre initialement : une version plus ancienne de l’installation TF en une étape sur K8s et Installation K8s avec kubeadm (qui traite de la désactivation de la config. CNI par défaut). Ces deux références étaient une base solide sur laquelle déployer TF comme interface de réseau de conteneur (CNI) pour K8s.

Au moment d’entrer dans le cycle d’installation initiale d’un environnement de travail (déployer, tester, réparer puis redéployer), j’ai rencontré des difficultés avec la documentation. Cela a engendré certains problèmes.

• La commande stipulée dans le guide en une étape engendrait des problèmes avec la génération de site Web statique qui enlevait des parties spécifiques de la commande. À cause de cela, l’information sur le site Web n’était pas valide ni utilisable et il fallait aller chercher le code source du site pour connaitre les commandes fonctionnelles. Je crois que c’est dû au fait que les caractères spéciaux `{{` et `}}` sont traités comme des variables sur la plateforme de génération de site statique et sont donc remplacés par des chaînes vides.
• Il n’y a pas de documentation concernant le matériel minimum pour exploiter TF. Après quelques essais et pertes de temps sur la chaîne TF Slack channel j’ai compris que pour lancer TF, il me fallait au moins 32 Go mémoire vive et 50 Go d’espace sur le disque dur.
• Les versions soutenues de Docker et Kubernetes ne sont pas publiées (à ce que je sache). La dernière version de K8s n’était pas soutenue au moment où je faisais mes essais (ce n’est peut-être plus le cas) mais la documentation devrait idéalement préciser quelles versions de K8s sont soutenues lors du déploiement de TF en tant que CNI.

La majorité des problèmes rencontrés relativement au manque de documentation ont été surmontés grâce aux commentaires reçus de la part de la communauté TF sur sa chaîne ‘Slack’ active.

À ce moment-là, j’étais assez certain d’être passé à travers les difficultés et d’être sur une lancée mais c’est vraiment là que les choses sont devenues intéressantes. Je regardais tous mes pods TF surgir dans K8s, tout paraissait aller correctement, puis tout d’un coup, pouf, j’ai perdu ma connexion à l’hôte. Je me suis dit: pas de panique, je n’ai qu’à retourner dans la machine virtuelle (MV) avec le protocole SSH et reprendre là où j’étais. Ce fut plus facile à dire qu’à faire, puisque ma MV ne répondait plus au SSH. J’ai configuré ma MV pour utiliser les clés SSH et je n’avais pas de mot de passe local. Sans le SSH, j’ai perdu l’accès à ma machine virtuelle. J’ai même eu des problèmes à configurer un mot de passe sur la MV parce que la fonctionnalité exigeait la connectivité au réseau et il semblait que la pile de réseau de mon hôte était complètement inutilisable.

Après avoir essayé de diagnostiquer les pannes et de communiquer avec la communauté sur ‘Slack’, Moh Ahmed (@Moh), un des ingénieurs de CENGN, m’a dirigé vers la cause fondamentale. Essentiellement, le script d’installation TF en une étape configure le code suivant : `VROUTER_GATEWAY: {{ K8S_MASTER_IP }}`, malheureusement, c’est incorrect. À la place de l’adresse IP du maître K8s, la variable `VROUTER_GATEWAY` devrait être fixée à la passerelle du réseau sous-jacent. Après avoir effectué ce changement suivi d’un redéploiement, cela a fonctionné et j’avais maintenant un déploiement Tungsten Fabric fonctionnel comme CNI de ma grappe Kubernetes. Il restait quelques petits soucis de connectivité au nœud lorsque TF modifie la pile de réseau de l’hôte mais tout est revenu comme prévu.

Maintenant que j’avais une grappe K8s fonctionnelle avec TF agissant comme CNI, je croyais n’avoir qu’à lancer une deuxième grappe K8s ayant la même config et puis rassembler les homologues avec BGP. J’ai pu configurer facilement ma deuxième grappe K8s avec TF grâce à mon automatisation. De plus, la configuration de l’homologuage BGP entre les deux déploiements TF fut aussi assez facile. Je n’avais qu’à enregistrer chaque déploiement TF avec l’autre comme BGP Router après avoir changé l’identifiant unique BGP AS par défaut sur l’un des déploiements TF pour qu’ils aient chacun leur unique numéro AS. J’ai été impressionné par la facilité que fut cette configuration, même par moi-même qui n’avais jamais travaillé avec TF auparavant. Je pouvais maintenant sonder par PING les services entre deux grappes K8s différentes. La vie était belle. Par contre, j’ai trouvé qu’au fil du temps, les choses ont commencé à agir bizarrement. Je pouvais, entre autres choses, sonder les services K8s par PING dans une direction et non dans l’autre. J’étais presque certain que c’était un problème de configuration de ma part et non de celle de TF puisqu’honnêtement, je ne m’attendais pas à ce que cette configuration fonctionne du tout. J’utilisais le même espace d’adresse IP dans les deux grappes pour les sous-réseaux du pod, le sous-réseau de service et le sous-réseau de la matrice IP et je m’attendais à ce que cela cause des problèmes lors de l’assemblage des environnements homologues avec BGP.

Alors, comment puis-je changer les sous-réseaux utilisés lors du déploiement de ces environnements K8s + TF afin que leurs sous-réseaux ne se chevauchent pas ? Naturellement, j’ai commencé par ajouter les drapeaux `–pod-network-cidr` et `–service-cidr` à la commande `kubeadm init`, mais cela n’a pas eu l’effet escompté. Tungsten Fabric utilisait encore les sous-réseaux par défaut même si Kubernetes était configuré pour différents CIDR. Je ne trouvais aucune documentation sur le site de TF ou ressource reliée qui indiquait comment modifier ces sous-réseaux. Après avoir vérifié le code et effectué des essais et erreurs, j’ai pu découvrir que la configuration doit être appliquée à la ConfigMap dans K8s `kube-manager-config`. Une fois que cela a été confirmé, j’ai dû déterminer le nom des champs qui contrôlait la configuration pertinente puisque je n’ai pas pu trouver de documentation sur ce sujet. J’ai pu isoler et vérifier que le fait de configurer les champs suivants : `KUBERNETES_POD_SUBNETS`, `KUBERNETES_SERVICE_SUBNETS`, `KUBERNETES_IP_FABRIC_SUBNETS`, dans la ConfigMap, combiné à l’ajout de drapeaux de config à la commande `kubeadm init` afin de référencer les mêmes CIDR, produisait les résultats désirés.

Voici la ConfigMap produite et utilisée pour configurer des CIDR sur mesure pour mon déploiement.

```
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-manager-config
  namespace: kube-system
data:
  KUBERNETES_API_SERVER: {{ K8S_MASTER_IP }}
  KUBERNETES_API_SECURE_PORT: "6443"
  K8S_TOKEN_FILE: "/tmp/serviceaccount/token"
  # --- additional config below --- #
  KUBERNETES_POD_SUBNETS: 10.48.0.0/12
  KUBERNETES_SERVICE_SUBNETS: 10.112.0.0/12
  KUBERNETES_IP_FABRIC_SUBNETS: 10.80.0.0/12
```

Après m’être assuré que les deux déploiements K8s + TF ne comportaient pas de chevauchements dans les éventails d’adresses IP, tous les ennuis ont disparu et tout fonctionnait comme sur des roulettes. Même si ce fut un long cheminement de déployer cette mise en œuvre, la qualité de Tungsten Fabric n’en a jamais été la cause. J’ai même trouvé qu’il était facile de travailler avec Tungsten Fabric et, une fois qu’il était mis en place, le produit était d’une grande maturité. Le fait de pouvoir assembler les environnements homologues par BGP, et que cela fonctionne, est simplement génial. J’ai évalué de nombreux logiciels et je dois dire que j’ai été très impressionné par l’architecture et l’implémentation de Tungsten Fabric. Ceci dit, la majorité des difficultés rencontrées était liées au manque de documentation ou d’erreurs dans celle-ci. C’est un problème bien connu dans la communauté et l’on tente activement de le résoudre. Puisque le projet TF continue sa transition dans l’organisme Linux Foundation Networking (LFN), on met davantage l’accent sur l’amélioration de sa disponibilité et de sa prévisibilité. Grâce à l’emphase sur l’élargissement de la disponibilité de TF vers un auditoire qui trouve des solutions pour les exigences SDN, je crois que l’on verra un intérêt renouvelé pour cette plateforme de réseautage plus mature qu’est TF.

Avec les composantes transprojets et transcommunautés, il est plus facile pour les utilisateurs de contrôler leur destin dans le nuage et dans leurs réseaux. Notre cas le favorise de trois façons. Il combat premièrement l’enferment à un fournisseur puisque c’est une solution de logiciel libre multinuages, deuxièmement, l’enfermement à une plateforme grâce à l’utilisation de Kubernetes et enfin, l’enfermement à un réseau avec l’utilisation de TF. En fin de compte, une application n’est aussi bonne que son réseautage. En faisant le pont entre les projets des fondations CNCF et LFN, notre cas aide les utilisateurs à rendre leur application infonuagique native sans compromettre le réseautage.

En conclusion, j’aimerais attirer l’attention sur quelques outils de références :

• Si l’utilisation de TF vous intéresse, je vous recommande fortement le document Tungsten Fabric Architecture. Il offre un aperçu complet des rouages de TF et orientera votre compréhension des différentes composantes et de leur importance.
• Toute l’automatisation pour déployer K8s comme CNI avec TF est disponible sur github. J’aimerais soulever le fait que cette automatisation n’est, en aucun cas, de niveau de production et au fil de l’évolution du projet, elle pourrait devenir obsolète. Je vais vérifier régulièrement la mise en œuvre et la mettre à jour pour qu’elle demeure fonctionnelle, mais à tout le moins, elle agit comme un aperçu des pièces mobiles de l’utilisation de TF comme CNI dans K8s.

Chez CloudOps, nous sommes heureux de consolider notre engagement dans la communauté TF (surtout relativement à l’utilisation de TF comme CNI pour K8s à travers des nuages multiples) et de soutenir les efforts de la communauté à accroître l’accessibilité à un plus large marché.

Si vous participez au Sommet de réseautage de logiciel libre qui aura lieu cette semaine, je présenterai une démo sur Linux Foundation Networking au kiosque de la LFN. Cette présentation démontrera comment TF complète les services maillés comme Istio et Consul Connect de HashiCorp. Elle mettra en lumière la mise en œuvre, pour Kubernetes, du réseau TF superposé et agnostique au niveau du nuage et comparera son intégration aux services maillés dans un contexte de gestion de charges de travail tant héritées qu’infonuagiques natives.

Pour en apprendre plus sur Kubernetes, inscrivez-vous à l’un de nos ateliers pratiques sur Docker et Kubernetes avec l’option d’utiliser Tungsten Fabric comme CNI.