GKE Dataplane V2

Cette page présente GKE Dataplane V2 et son fonctionnement.

Avant de lire ce document, assurez-vous de maîtriser la mise en réseau dans des clusters GKE.

Présentation de GKE Dataplane V2

GKE Dataplane V2 est un plan de données optimisé pour la mise en réseau Kubernetes. Caractéristiques de GKE Dataplane V2 :

  • Expérience utilisateur cohérente pour la mise en réseau.
  • Visibilité en temps réel sur l'activité réseau.
  • Architecture plus simple qui facilite la gestion et le dépannage des clusters.

GKE Dataplane V2 est activé par défaut pour tous les nouveaux clusters Autopilot.

Fonctionnement de GKE Dataplane V2

GKE Dataplane V2 est mis en œuvre à l'aide de eBPF. Lorsque les paquets arrivent sur un nœud GKE, les programmes eBPF installés dans le noyau déterminent comment acheminer et traiter les paquets. Contrairement au traitement des paquets par iptables, les programmes eBPF peuvent utiliser des métadonnées propres à Kubernetes dans le paquet. Cela permet à GKE Dataplane V2 de traiter plus efficacement les paquets réseau dans le noyau et de signaler les actions annotées dans l'espace utilisateur à des fins de journalisation.

Le schéma suivant illustre le chemin d'un paquet au sein d'un nœud utilisant GKE Dataplane V2 :

GKE déploie le contrôleur GKE Dataplane V2 en tant que DaemonSet nommé anetd sur chaque nœud du cluster. anetd interprète les objets Kubernetes et programme les topologies de réseaux dans eBPF. Les pods anetd s'exécutent dans l'espace de noms kube-system.

GKE Dataplane V2 et NetworkPolicy

GKE Dataplane V2 est mis en œuvre à l'aide de Cilium. L'ancien plan de données pour GKE est mis en œuvre à l'aide de Calico.

Ces deux technologies gèrent les règles NetworkPolicy Kubernetes. Cilium utilise eBPF et l'interface CNI (Container Network Interface) de Calico utilise iptables dans le kernel Linux.

Avantages de GKE Dataplane V2

Évolutivité

GKE Dataplane V2 présente des caractéristiques d'évolutivité différentes de celles de l'ancien plan de données.

Pour les versions de GKE où GKE Dataplane V2 n'utilise pas kube-proxy et ne s'appuie pas sur iptables pour le routage de services, GKE supprime certains goulots d'étranglement liés à iptables, tels que le nombre de services.

GKE Dataplane V2 s'appuie sur des cartes eBPF qui sont limitées à 64 000 points de terminaison pour tous les services.

Sécurité

Les règles de réseau Kubernetes sont toujours actives sur les clusters utilisant GKE Dataplane V2. Vous n'avez pas besoin d'installer et de gérer des modules complémentaires de logiciels tiers tels que Calico pour appliquer les règles de réseau.

Opérations

Lorsque vous créez un cluster avec GKE Dataplane V2, la journalisation des règles de réseau est intégrée. Configurez la CRD de journalisation sur votre cluster pour savoir quand les connexions sont autorisées ou refusées par vos pods.

Cohérence

GKE Dataplane V2 offre une expérience de mise en réseau cohérente.

Pour en savoir plus, consultez la section Disponibilité de GKE Dataplane V2.

Spécifications techniques de GKE Dataplane V2

GKE Dataplane V2 est compatible avec les spécifications de cluster suivantes :

Spécification GKE Cloud distribué de Google Cloud distribué de Google
Nombre de nœuds par cluster 5 000 500 500
Nombre de pods par cluster 50 000 15 000 27 500
Nombre de services LoadBalancer par cluster 750 500 1 000

GKE Dataplane V2 tient à jour un mappage des services. Celui-ci permet d'identifier les pods auxquels les services font référence en tant que backends. Le total du nombre de backends (pods) de chaque service sur l'ensemble des services doit pouvoir tenir dans le mappage de service, qui peut contenir jusqu'à 64 000 entrées. Si cette limite est dépassée, votre cluster risque de ne pas fonctionner comme prévu.

Augmentation de la limite de nœuds dans la version 1.23

À partir de la version 1.23 de Kubernetes, la limite de 500 nœuds par cluster GKE Dataplane V2 a été augmentée à 5 000, les conditions supplémentaires suivantes étant imposées aux clusters :

  • Clusters privés ou clusters publics qui utilisent Private Service Connect. Pour vérifier si votre cluster utilise Private Service Connect, consultez la page Clusters publics avec Private Service Connect.
  • Clusters régionaux uniquement
  • Seuls les clusters créés avec GKE version 1.23 ou ultérieure disposent d'une limite de 5 000 nœuds. Les clusters créés avec des versions antérieures de GKE peuvent nécessiter l'augmentation de la limite de quota des clusters. Contactez l'assistance pour obtenir de l'aide.
  • Les clusters qui utilisent des CRD Cilium (CiliumNetworkPolicy et CiliumClusterwideNetworkPolicy) ne peuvent pas évoluer jusqu'à 5 000 nœuds.

Services LoadBalancer dans Google Distributed Cloud

Le nombre de services LoadBalancer accepté sur Google Distributed Cloud dépend du mode d'équilibrage de charge utilisé. Google Distributed Cloud accepte 500 services LoadBalancer lorsque vous utilisez le mode d'équilibrage de charge groupé (Seesaw), et 250 services lorsque vous utilisez le mode d'équilibrage de charge intégré avec F5. Pour plus d'informations, consultez la page Évolutivité.

Limites

GKE Dataplane V2 présente les limites suivantes :

  • Vous ne pouvez activer GKE Dataplane V2 que lors de la création d'un cluster. Les clusters existants ne peuvent pas être mis à niveau pour utiliser GKE Dataplane V2.
  • Dans les versions de GKE antérieures à la version 1.20.12-gke.500, si vous activez GKE Dataplane V2 avec NodeLocal DNSCache, vous ne pouvez pas configurer de pods avec dnsPolicy: ClusterFirstWithHostNet, ou vos pods rencontreront des erreurs de résolution DNS.
  • À partir de la version 1.21.5-gke.1300 de GKE, GKE Dataplane V2 n'est pas compatible avec les API CRD CiliumNetworkPolicy ou CiliumClusterwideNetworkPolicy. À partir des versions 1.28.6-gke.1095000 et 1.29.1-gke.1016000 de GKE, vous pouvez activer CiliumClusterwideNetworkPolicy sur les clusters nouveaux ou existants.
  • Les équilibreurs de charge réseau internes à stratégie directe créés manuellement et associés à un service de type NodePort ne sont pas acceptés.
  • Étant donné que GKE Dataplane V2 optimise le traitement des paquets de noyau eBPF à l'aide de eBPF, les performances de votre pod peuvent être affectées si vous avez des charges de travail avec une perte de pods élevée. L'objectif principal de GKE Dataplane V2 est d'atteindre un eBPF optimal.
  • Il existe un problème connu avec les services multiclusters avec plusieurs ports TCP/UDP sur GKE Dataplane V2. Pour plus d'informations, consultez la page Services MCS avec plusieurs ports.
  • GKE Dataplane V2 utilise cilium au lieu de kube-proxy pour mettre en œuvre les services Kubernetes. kube-proxy étant géré et développé par la communauté Kubernetes, les nouvelles fonctionnalités liées aux services sont plus susceptibles d'être mises en œuvre dans kube-proxy avant d'être mises en œuvre dans cilium pour GKE Dataplane V2. KEP-1669: Proxy Terminating Endpoints est un exemple de fonctionnalité de services mise en œuvre d'abord dans kube-proxy.
  • Pour les services NodePort exécutant la version 1.25 ou une version antérieure, et utilisant des plages SNAT et PUPI par défaut, vous devez ajouter la plage PUPI des pods dans nonMasqueradeCIDRs, dans le ConfigMap ip-masq-agent, afin d'éviter des problèmes de connectivité.
  • Dans certains cas, les pods de l'agent GKE Dataplane V2 (anetd) peuvent consommer une grande quantité de ressources de processeur, jusqu'à deux ou trois processeurs virtuels par instance. Cela se produit lorsqu'un volume élevé de connexions TCP est ouvert et fermé rapidement sur le nœud. Pour atténuer ce problème, nous vous recommandons de mettre en œuvre des messages keep-alive pour les appels HTTP et le regroupement de connexions pour les charges de travail concernées.
  • Les clusters GKE Dataplane V2 exécutant la version 1.27 ou antérieure du plan de contrôle ne sont pas compatibles avec le champ .spec.internalTrafficPolicy du service. La règle de trafic interne en vigueur pour un service est Cluster ; les backends sur n'importe quel nœud sont considérés comme des candidats pour la résolution du service. Pour en savoir plus sur ce champ, consultez la page Règle de trafic interne du service.

GKE Dataplane V2 et kube-proxy

GKE Dataplane V2 n'utilise pas kube-proxy, sauf sur les pools de nœuds Windows Server sur GKE version 1.25 ou antérieure.

Application de règles de réseau sans GKE Dataplane V2

Consultez la section Utiliser l'application de règles de réseau pour savoir comment activer l'application de la règle de réseau dans les clusters qui n'utilisent pas GKE Dataplane V2.

Étapes suivantes