J'espère que la lecture sur eBPF dans la Partie 1 vous a plu ! Penchons-nous maintenant sur Cilium, une solution eBPF populaire pour Kubernetes, et voyons comment elle s'articule avec Dataplane V2.
Cilium 🐝 est une technologie en vogue, propulsée par eBPF. C'est souvent la première chose que l'on cite lorsqu'on parle d'eBPF, en particulier dans le contexte de Kubernetes. Cilium est un logiciel open-source qui fait office de plugin CNI pour Kubernetes. Il offre du networking, de l'observabilité et de la sécurité basés sur eBPF, avec une scalabilité et des performances optimales pour les équipes plateforme exploitant des environnements Kubernetes dans le cloud comme on-premise.
En tirant parti d'Extended Berkeley Packet Filter (eBPF), Cilium apporte de nombreuses fonctionnalités intéressantes à Kubernetes. Regardons cela de plus près.
Network Policies 🕸
Il est recommandé d'appliquer le principe de moindre privilège lorsque vos pods Kubernetes communiquent entre eux. Les Network Policies Kubernetes de base (qui opèrent en L3/L4) font bien le travail, mais vous pouvez aller plus loin avec les Cilium Network Policies (qui opèrent de L3 à L7).
C'est particulièrement utile dans l'univers de Kubernetes et des microservices, car examiner et contrôler le trafic réseau via des métadonnées (comme les IP et les ports) apporte peu de valeur. Les IP et les ports changent constamment au gré des services qui apparaissent et disparaissent. Avec Cilium, vous pouvez aussi contrôler le trafic via les Pods, HTTP, gRPC, Kafka, DNS et d'autres métadonnées.
Par exemple, vous pouvez définir des règles HTTP autorisant un appel API spécifique depuis un pod donné via le chemin, l'en-tête et la méthode de requête. Autre exemple : définir des règles DNS basées sur le FQDN, afin que seules les requêtes vers un domaine précis soient autorisées. Cela permet de définir des politiques de sécurité bien plus pertinentes et exploitables dans les cas d'usage réels.
Connectivité multi-cluster 🔗
Grâce à un cluster mesh, Cilium permet aux pods Kubernetes de communiquer et d'être découverts à travers plusieurs clusters. Parmi les cas d'usage : haute disponibilité et multi-cloud (interconnexion de clusters Kubernetes entre fournisseurs cloud).
Load Balancing ⚖️
Cilium remplace kube-proxy par BPF. kube-proxy utilise iptables, qui est en cours de remplacement par BPF. Ce changement améliore considérablement les performances.
Fonctionnalités complémentaires
- Chiffrement transparent entre pods. Support d'IPsec/Wireguard
- Performances réseau accrues
- Forte scalabilité de l'infrastructure
- Visibilité enrichie sur les flux de trafic, non seulement par IP et ports mais aussi par protocoles L7. Découvrez cet article sur une session de débogage DNS particulièrement intéressante
- Monitoring et meilleure visibilité sur les erreurs réseau entre vos microservices. Cilium fournit des métriques compatibles Prometheus
Quelques mots sur les alternatives. D'autres plugins CNI performants existent sur le marché. Voici une comparaison (potentiellement subjective). Calico a également récemment introduit un Dataplane eBPF.
Dataplane V2 ✈
Google Cloud Platform fait évoluer GKE (Google Kubernetes Engine) en intégrant Cilium dans son propre mécanisme, Dataplane V2. Mais Dataplane V2 est-il vraiment un Cilium managé par Google pour GKE ? Nous adorons les services managés, n'est-ce pas ? Cela mérite un examen approfondi.
En parcourant la documentation de Google sur les concepts de Dataplane V2, on ne trouve aucune mention ni référence au projet Cilium (au moment de la rédaction de cet article). En revanche, dans l'article de blog officiel et dans une partie de la documentation, on relève quelques références mineures.
Le control plane de Dataplane V2 est déployé sous la forme d'un DaemonSet Kubernetes appelé anetd. Un rapide kubectl describe daemonsets.apps -n kube-system anetd révèle qu'il utilise l'image gke.gcr.io/cilium/cilium:v1.9.4-gke.17.
Alors, est-ce vraiment Cilium ? Lançons kubectl exec -n kube-system -ti ds/anetd — cilium version. Voici la sortie :
Client: 1.9.4 609a63dfb 2021-04-12T15:01:54-07:00 go version go1.15.7 linux/amd64
Oui ! Il s'agit bien de Cilium 1.9.4 ! Cependant, en comparant avec l'image officielle Cilium v1.9.4, on obtient un résultat légèrement différent :
Client: 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64
Comparons maintenant les images Docker gke.gcr.io/cilium/cilium:v1.9.4-gke.17 et quay.io/cilium/cilium:v1.9.4 avec un outil comme Dive. Il semble qu'il y ait quelques modifications dans les couches, mais difficile de dire s'il existe un changement logique majeur entre les deux concernant les fonctionnalités de Cilium.
Il convient également de mentionner que dans cet article de blog, il est affirmé que Google s'est impliqué et a contribué à plusieurs fonctionnalités significatives au projet Cilium. Cela témoigne, à mon sens, d'un véritable engagement.
Alors, Dataplane V2 = Cilium managé ?
À ce stade, impossible de conclure si Dataplane V2 est un Cilium managé pour GKE. Et sans confirmation officielle, on peut affirmer qu'au moins en tant que produit, Dataplane V2 ≠ Cilium. On dirait que Cilium est utilisé sous le capot, en coulisses. La documentation de Google n'en parle simplement pas et ne renvoie pas vers celle de Cilium. C'est une offre totalement différente.
D'après les tests que j'ai menés, certaines fonctionnalités de Cilium semblent fonctionner sur Dataplane V2. Toutefois, il n'y a pas de support officiel de Google. Inutile de préciser que les fonctionnalités Cilium hors documentation sur Dataplane V2 peuvent fonctionner aujourd'hui, mais cesser de le faire à tout moment et sans préavis. Mieux vaut donc éviter de s'aventurer en terrain inconnu. Suivez la documentation officielle pour rester du bon côté.
Cilium vanilla ou Dataplane V2 ? 🤔
Voici une comparaison des fonctionnalités :
Les fonctionnalités communes à Cilium et Dataplane V2 sont actuellement :
- les Network Policies Kubernetes (pas les CiliumNetworkPolicy, même si Dataplane V2 ne semble pas les rejeter pour le moment),
- le remplacement de
kube-proxypar eBPF, - le Network Policy Logging. Ce n'est pas vraiment une fonctionnalité Cilium, mais elle s'appuie sur Cilium. Elle vous permet de surveiller le résultat des hits de vos network policies.
Mon avis 💭
J'essaie toujours d'opter pour la solution la plus simple possible. Si elle est managée, c'est encore mieux ! Cela fait gagner un temps précieux à toutes les parties impliquées. Dataplane V2 paraît être une solution managée plus simple et plus accessible si tout ce dont vous avez besoin se résume à exploiter les Network Policies Kubernetes, à remplacer kube-proxy par eBPF pour les performances et la scalabilité, et à profiter d'une journalisation simple des résultats des network policies.
Veillez simplement à bien connaître ses limitations. Si vous avez besoin des fonctionnalités supplémentaires de Cilium telles que Hubble, les Cilium L7 Network Policies, le Cluster Mesh, ou si vous utilisez un environnement auto-hébergé ou un autre fournisseur cloud, vous opterez probablement pour Cilium vanilla.
Dataplane V2 : les avantages 👍
- D'abord, son installation est simple. Il suffit d'ajouter le flag
—enable-dataplane-v2lors de la création d'un nouveau cluster GKE viagcloud container clusters create. - Il s'appuie sur le projet open-source Cilium.
- Dataplane V2 sert de socle au Network Policy Logging dans GKE. Une fonctionnalité bien pratique qui génère des logs lorsqu'une connexion est autorisée ou refusée par une network policy.
- Le plugin
anted, qui fait partie de Dataplane V2 (basé sur Cilium), est managé par Google et est actuellement en GA (General Availability). Cela signifie qu'il est prêt pour les workloads de production, avec des mises à jour et un support continus. - Il est raisonnable de penser que Google ajoutera davantage d'intégrations avec les fonctionnalités natives de GKE, et peut-être aussi avec celles de Cilium. Cela rend ce choix d'autant plus convaincant dans une perspective long terme.
Dataplane V2 : les inconvénients 👎
- À l'heure actuelle, je n'ai pas trouvé de moyen d'utiliser Hubble avec Dataplane V2. Hubble est un excellent outil d'observabilité de Cilium qui apporte une visibilité précieuse en s'appuyant sur eBPF. Vous pouvez suivre l'évolution ici.
- Officiellement, Dataplane V2 n'est pas une solution Cilium managée. Vous ne pouvez donc pas compter sur certaines fonctionnalités Cilium qui fonctionnent aujourd'hui pour vous avec Dataplane V2. Vous risquez de rencontrer des dysfonctionnements à l'avenir.
- Vous ne pouvez l'activer que sur un cluster GKE nouvellement créé. Impossible donc de l'utiliser sur vos clusters GKE existants.
- D'autres limitations sont à connaître.
Pour bien démarrer 🏃🏽♀️
Pour démarrer avec Cilium sur Kubernetes — cliquez ici.
Pour démarrer avec Dataplane V2 sur GKE — cliquez ici.
Astuce de pro : lorsque vous rédigez ou planifiez vos manifests Kubernetes/Cilium Network Policy, utilisez le Cilium Editor pour une expérience ludique et sécurisée.
L'avenir d'eBPF
Aussi novatrice que soit cette technologie, je peux prédire que nous continuerons à voir émerger de nombreuses solutions et évolutions intéressantes basées sur eBPF.
L'un des domaines potentiellement impactés est celui du service mesh. La plupart des solutions de service mesh existantes (par exemple Istio, Linkerd) reposent sur des proxys sidecar attachés à vos pods. Cela pèse sur les performances, ajoute de la complexité et introduit des points de défaillance supplémentaires. eBPF a le potentiel d'apporter des fonctionnalités de service mesh en remplaçant les proxys sidecar par de la logique eBPF, ce qui pourrait rendre le service mesh accessible à davantage de cas d'usage.
Restez à l'écoute !
Merci de votre lecture ! Pour rester en contact, suivez-nous sur le DoiT Engineering Blog, le canal LinkedIn DoiT et le canal Twitter DoiT. Pour découvrir les opportunités de carrière, rendez-vous sur https://careers.doit-intl.com.