Fédération

Cet article porte sur la fédération v2 dans Kubernetes, son fonctionnement et différents cas d’utilisation possibles. En préambule, il faut savoir que la fédération v1, qui reprenait en quasi intégralité l’api Kubernetes, est dépréciée et que la nouvelle version v2 est actuellement distribuée en version alpha.

Audience ciblée : Administrateur/trice Kubernetes

Par Maud Laurent, Administratrice système @Objectif Libre

La Fédération v2 dans Kubernetes

Fédération k8s : qu’est-ce que c’est ?

La fédération permet de regrouper plusieurs clusters et de les contrôler en un seul point.

  • La fédération s’assure que les mêmes ressources existent sur les différents clusters identifiés.
  • Elle offre une haute disponibilité au niveau du cluster, si deux clusters ou plus sont totalement fédérés et répliqués.
  • Elle permet de faire du cloud hybride : les clusters peuvent être fournis par différents cloud providers.
  • Elle permet aussi le multi-région : les clusters sont hébergés sur des sites distants.
  • La fédération propose l’auto-configuration DNS entre les clusters (avec CoreDNS ou un DNS externe).
  • Cependant, les services doivent obligatoirement être de type LoadBalancer pour être découverts à travers les clusters.

Attention: la mise en place de la fédération réduit l’isolation des clusters. Elle augmente la consommation de la bande passante en fonction du positionnement des clusters chez un même cloud provider, une même région ou non.

Déploiement de la fédération v2

Un guide utilisateur est disponible sur la page Github et décrit l’intégralité du processus d’installation : https://github.com/kubernetes-sigs/kubefed/blob/master/docs/userguide.md.

Le déploiement de la fédération se fait avec un chart Helm depuis un cluster qui sert de cluster hôte (par défaut c’est le contexte courant de notre kubectl qui est utilisé).

Ce cluster hôte héberge un déploiement federation-controller-manager dans le namespace federation-system. Il utilise aussi, par défaut, le namespace kube-multicluster-public pour enregistrer les clusters dans un « registre de clusters ».

Après avoir installé la fédération, toute la gestion se fait avec la commande kubefed2.
Les ressources Kubernetes peuvent être ajoutées, dans la liste des ressources fédérées, avec la commande kubefed2 enable ou supprimées avec kubefed2 disable. Les ressources fédérées sont écrites de la même manière que leur ressource classique correspondante, seul le champ kind change pour être du type federated<ressource>.

Les ressources sont ajoutées dans le groupe api types.federation.k8s.io. Les nouvelles ressources créées sont visibles avec la commande kubectl api-resources | grep federation.

L’ajout et la suppression de clusters dans la fédération se font aisément avec kubefed2 et les mots clefs join ou unjoin. Par exemple, l’ajout d’un cluster à la fédération se ferait comme suit :

kubefed2 join clusterName --cluster-context clusterContext \
--host-cluster-context clusterHost --add-to-registry --v=2

Les contextes se basent sur le fichier kubeconfig local (~/.kube/config).
Attention, les noms ne doivent pas contenir le symbole « @ » pour ne pas interférer avec le format des domaines et sous-domaines DNS identifiant les clusters. La liste des clusters fédérés est disponible avec la commande kubectl get clusters.clusterregistry.k8s.io -n kube-multicluster-public.

Utilisation

Tous les déploiements fédérés ont besoin d’avoir un namespace fédéré de type federatednamespaces qui correspond à un namespace classique du cluster hôte Kubernetes. Ces deux namespaces doivent avoir le même nom.

Pour chaque ressource fédérée, il est possible d’ajouter une partie placement et overrides.
La partie placement sert à définir les clusters utilisés pour les déploiements. Les clusters peuvent être filtrés avec les labels.
La partie overrides est optionnelle et offre la possibilité de surcharger certaines valeurs comme le nombre de replicas.

placement:
  clusterNames:
    - cluster2-fede
    - cluster1-fede
  # Il est aussi possible de filtrer les clusters par labels
  overrides: # optionnel, les valeurs peuvent être surchargées par cluster
    - clusterName: cluster2-fede
      clusterOverrides:
        - path: spec.replicas
          value: 5

Les ressources fédérées, créées au travers de fichiers yaml, s’appliquent à partir du cluster hôte et seront dispatchées automatiquement en fonction du bloc placement. Sans bloc de placement, la totalité des clusters fédérés est utilisée.

Il est possible de convertir une ressource du cluster hôte en ressource fédérée avec la commande
kubefed2 federate ressourceType ressourceName -n namespace si le namespace est lui aussi fédéré.

Cas d’utilisation

Réplication

La fédération peut être utilisée pour mettre en place un mécanisme de réplication. Selon l’infrastructure, cela sera plus ou moins utile. Par exemple, une infrastructure avec 3 clusters (1 dev, 1 pre-prod, 1 prod) ne nécessite pas de déployer des applications sur plusieurs clusters en même temps. Dans le cas où deux clusters ou plus sont de même niveau (dev, pre-prod ou prod), il devient intéressant de déployer simultanément et de gérer des ressources communes au sein de ces deux clusters, pour éviter les décalages entre ces clusters.

Migration

La fédération peut aussi être utilisée pour la migration d’applications, par exemple pour passer d’un cloud privé à un cloud public. Un cluster ajouté à la fédération peut être retiré à tout moment et gardera les applications et ressources déployées sur ce dernier.

Et le stockage dans tout ça ?

S’ajoute à tout cela une problématique de stockage en fonction des applications déployées. Si elles utilisent une connexion à une base de données externe, les différents clusters peuvent peut-être la joindre, auquel cas il n’y a pas de réel problème.
Si l’application utilise des volumes, la réplication des données entre les clusters doit être faite soit en utilisant des volumes persistants fédérés, soit en utilisant un backend adéquat gérant cette réplication.

Conclusion

La fédération est un outil performant qui répond à un besoin particulier qui saura satisfaire des infrastructures multi-clusters importantes.
La fédération v2 est actuellement en alpha, et passera sûrement en bêta avec Kubernetes 1.16 ou 1.17. L’évolution du projet est donc à suivre.