Cours 5 - Le réseau dans Kubernetes

Les solutions réseau dans Kubernetes ne sont pas standard. Il existe plusieurs façons d’implémenter le réseau.

Les objets Services

Les Services sont de trois types principaux :

  • ClusterIP: expose le service sur une IP interne au cluster appelée ClusterIP. Les autres pods peuvent alors accéder au service mais pas l’extérieur.

  • NodePort: expose le service depuis l’IP publique de chacun des noeuds du cluster en ouvrant port directement sur le nœud, entre 30000 et 32767. Cela permet d’accéder aux pods internes répliqués. Comme l’IP est stable on peut faire pointer un DNS ou Loadbalancer classique dessus.

Crédits à Ahmet Alp Balkan pour les schémas

  • LoadBalancer: expose le service en externe à l’aide d’un Loadbalancer de fournisseur de cloud. Les services NodePort et ClusterIP, vers lesquels le Loadbalancer est dirigé sont automatiquement créés.

Crédits Ahmet Alp Balkan

Les implémentations du réseau

Beaucoup de solutions de réseau qui se concurrencent, demandant un comparatif un peu fastidieux.

  • plusieurs solutions très robustes
  • diffèrent sur l’implémentation : BGP, réseau overlay ou non (encapsulation VXLAN, IPinIP, autre)
  • toutes ne permettent pas d’appliquer des NetworkPolicies : l’isolement et la sécurité réseau
  • peuvent parfois s’hybrider entre elles (Canal = Calico + Flannel)

  • ces implémentations sont souvent concrètement des DaemonSets : des pods qui tournent dans chacun des nodes de Kubernetes

  • Calico, Flannel, Weave ou Cilium sont très employées et souvent proposées en option par les fournisseurs de cloud

  • Cilium a la particularité d’utiliser la technologie eBPF de Linux qui permet une sécurité et une rapidité accrue

Comparaisons :

Les network policies

Crédits Ahmet Alp Balkan

Par défaut, les pods ne sont pas isolés au niveau réseau : ils acceptent le trafic de n’importe quelle source.

Les pods deviennent isolés en ayant une NetworkPolicy qui les sélectionne. Une fois qu’une NetworkPolicy (dans un certain namespace) inclut un pod particulier, ce pod rejettera toutes les connexions qui ne sont pas autorisées par cette NetworkPolicy.

Le loadbalancing

Le loadbalancing permet de balancer le trafic à travers plusieurs nodes Kubernetes.

Pas de solution de loadbalancing par défaut :

  • soit on se base sur ce que le fournisseur de cloud propose,
  • soit on configure MetalLB, seule alternative en dehors des fournisseurs de cloud

Les objets Ingresses

Crédits Ahmet Alp Balkan

Un Ingress est un objet pour gérer le reverse proxy dans Kubernetes : il a besoin d’un ingress controller installé sur le cluster, qui agit donc au niveau du protocole HTTP et écoute sur un port (80 ou 443 généralement), pour pouvoir rediriger vers différents services (qui à leur tour redirigent vers différents ports sur les pods) selon l’URL.

  • Un ingress basé sur Nginx plus ou moins officiel à Kubernetes et très utilisé
  • Traefik est optimisé pour k8s
  • il en existe d’autres : celui de l’entreprise Nginx, Istio, Contour, HAProxy….

Comparaison : https://medium.com/flant-com/comparing-ingress-controllers-for-kubernetes-9b397483b46b

Le mesh networking et les service meshes

Envoy et Istio sont des service meshes.

  • Il faut y penser comme des super-ingresses : des proxy qui font beaucoup plus que du reverse proxy
    • en particulier : ajouter des fonctions de monitoring et de sécurité

Ressources sur le réseau

Vidéos

Des vidéos assez complètes sur le réseau, faites par Calico :

Sur MetalLB, les autres vidéos de la chaîne sont très bien :