Mon été avec Cilium et EKS (Épilogue)
Lors de cet été, j’ai pu voir beaucoup de fonctionnalités de Cilium sur EKS. Via ce blog, j’ai parlé de pas mal de possibilités si on veut installer cilium avec EKS :
- le mode ENI et la délégation de préfixe
- le chaining mode avec le vpc cni et la limitation de la bande passante
- le mode overlay
- le mode sans kube-proxy.
J’ai également parlé de la nouvelle version qui est sortie en plein été. J’aurais pu parler de la nouvelle version de aws vpc cni qui permet d’utiliser les network policies (cela utilise eBPF).
J’aurais pu parler de chiffrement avec Wireguard et IPsec permettant ainsi de chiffrer les communication entre les nœuds. J’aurais aussi pu parler de la communication entre cluster kubernetes avec clustermesh ou de la communication entre l’extérieur et le cluster via un load balancer (ELB) en utilisant une API Gateway.
Bilan
C’est en faisant des labs d’Isovalent et le cours edx sur Cilium que j’ai eu l’idée de tester Cilium sur EKS. Ok ça marche sur kind (cluster kubernetes facilement installable sur sa machine) mais qu’en est-il sur EKS ? Est-ce que c’est aussi simple à tester que dans les labs ? Non évidemment, il y a toute la machinerie AWS à ne pas oublier par exemple. J’ai souvent rendu le cluster complètement non sécurisé en ouvrant tout pour gagner du temps (À effectuer que par des professionnels, ne faites pas ça à la maison !).
Un petit bilan de ce qui a marché ou non sur EKS. Concernant l’installation et le cycle de vie :
Je n’ai pas testé l’installation avec Fluxcd (je ne connais pas très bien cet outil) mais j’ai vu la possibilité de le faire.
On peut installer cilium sur AMD64 et ARM64 :
On peut installer cilium en IPv4 et en IPv6 :
Mais seulement en mode overlay pour l’IPv6. Il y a déjà eu du travail pour que ça fonctionne en mode eni : https://github.com/cilium/cilium/issues/18405#issuecomment-1496915954
Concernant ce qui est spécifique à AWS :
Je n’ai pas pu tester Custom Networking, ça permet de rajouter des réseaux si on est à court d’IP. Je ne connais pas du tout VPC Lattice. Concernant les security groups, on peut seulement mettre dans une network policy un sg, pour dire qu’on accepte la communication entre le pod et un EC2 qui a ce security group. C’est assez loin de ce qui pourrait avoir : rajouter un security group à un pod. Il y a aussi Fargate qui ne peut pas fonctionner car on ne peut pas accéder à ebpf du kernel avec Fargate.
Concernant d’autres fonctionnalités :
J’avais testé l’ingress controller dans Cilium 1.12. Mais ça ne répondait pas au besoin que j’avais à l’époque, j’étais resté sur une valeur sûre (nginx). Pour cet été, j’ai préféré testé API gateway vu que c’est “le futur” des ingress controllers. Ça fonctionne mais uniquement avec des Classic Load Balancer qui sont déconseillés par AWS (enfin on peut arriver à se connecter sur NLB ou ALB avec une rustine via Kyverno, pas super sérieux pour de la production). Si j’ai bien compris, ce n’est pas de la faute du projet Cilium. Mais du standard qui n’a pas été encore défini pour cela. Sinon j’ai réussi à faire fonctionner.
Conclusion
Pour cet été, cette série d’article sur ce sujet est terminée. Si vous restez sur votre faim, je vous conseille vivement le lien suivant :
N’hésitez pas à donner des idées via les issues. Peut-être que ça me donnera l’envie de créer de nouvelles parties !
