Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Services de réseau

Cette page explique comment fonctionnent CoreDNS, le contrôleur d’entrée Traefik, le contrôleur de stratégie réseau et le contrôleur de répartition de charge ServiceLB au sein de K3s.

Consultez la page Options de configuration du réseau d’installation pour des détails sur les options de configuration de Flannel et la sélection de backend, ou sur la façon de configurer votre propre CNI.

Pour des informations sur les ports à ouvrir pour K3s, consultez Exigences réseau.

CoreDNS

CoreDNS est déployé automatiquement au démarrage du serveur. Pour le désactiver, configurez tous les serveurs du cluster avec l’option --disable=coredns.

Si vous n’installez pas CoreDNS, vous devrez installer vous-même un fournisseur DNS de cluster.

Contrôleur d’entrée Traefik

Traefik est un proxy inverse HTTP moderne et un répartiteur de charge conçu pour déployer des microservices facilement. Il simplifie la complexité du réseau lors de la conception, du déploiement et de l’exécution d’applications.

Le contrôleur d’entrée Traefik déploie un Service LoadBalancer qui utilise les ports 80 et 443, et annonce les adresses IP externes de ce service dans le Status des Ingress qu’il gère.

Par défaut, ServiceLB utilisera tous les nœuds du cluster pour héberger le Traefik LoadBalancer Service, ce qui signifie que les ports 80 et 443 ne seront pas utilisables pour d’autres pods HostPort ou NodePort, et le Status des Ingress affichera les adresses IP des nœuds de tous les membres du cluster.

Pour restreindre les nœuds utilisés par Traefik, et par extension les adresses IP des nœuds annoncées dans le Status des Ingress, vous pouvez suivre les instructions dans la section Contrôle de la sélection des nœuds ServiceLB ci-dessous pour limiter les nœuds sur lesquels ServiceLB s’exécute, ou en ajoutant certains nœuds à un pool LoadBalancer et en restreignant le Service Traefik à ce pool en définissant des étiquettes correspondantes dans le Traefik HelmChartConfig.

Traefik est déployé par défaut lors du démarrage du serveur. Les valeurs par défaut du chart peuvent être trouvées dans /var/lib/rancher/k3s/server/manifests/traefik.yaml, mais ce fichier ne doit pas être modifié manuellement, car K3s le remplace par des valeurs par défaut au démarrage. Au lieu de cela, vous devriez personnaliser Traefik en créant un manifeste HelmChartConfig supplémentaire dans /var/lib/rancher/k3s/server/manifests. Pour plus de détails et un exemple, voir Personnalisation des composants empaquetés avec HelmChartConfig. Pour plus d’informations sur les valeurs de configuration possibles, consultez values.yaml du Traefik Helm Chart inclus avec votre version de K3s.

Pour supprimer Traefik de votre cluster, démarrez tous les serveurs avec l’option --disable=traefik. Pour plus d’informations, voir Gestion des composants empaquetés.

Pour plus de détails sur la version spécifique de Traefik incluse dans K3s, consultez les notes de version correspondantes.

Les versions de K3s à partir de 1.32 incluent Traefik v3. Les installations existantes de Traefik v2 sont automatiquement mises à niveau vers v3 lorsque K3s est mis à niveau. Traefik v3 devrait être compatible avec la configuration de v2 ; consultez la documentation de migration de v2 à v3 pour plus d’informations.
Les versions de K3s 1.21 à 1.31 incluent Traefik v2, sauf si une installation existante de Traefik v1 est trouvée, auquel cas Traefik n’a pas été mis à niveau vers v2.
Les versions de K3s 1.20 et antérieures incluent Traefik v1.

Contrôleur de stratégie réseau

K3s inclut un contrôleur de stratégie réseau intégré. L’implémentation sous-jacente est la bibliothèque de contrôleur netpol de kube-router (aucune autre fonctionnalité de kube-router n’est présente) et peut être trouvée ici.

Pour le désactiver, démarrez chaque serveur avec l’option --disable-network-policy.

Les règles iptables de stratégie réseau ne sont pas supprimées si la configuration de K3s est modifiée pour désactiver le contrôleur de stratégie réseau. Pour nettoyer les règles de stratégie réseau kube-router configurées après avoir désactivé le contrôleur de stratégie réseau, utilisez le script k3s-killall.sh, ou nettoyez-les en utilisant iptables-save et iptables-restore. Ces étapes doivent être exécutées manuellement sur tous les nœuds du cluster.

iptables-save | grep -v KUBE-ROUTER | iptables-restore
ip6tables-save | grep -v KUBE-ROUTER | ip6tables-restore

Équilibreur de charge de service

Tout contrôleur LoadBalancer peut être déployé dans votre cluster K3s. Par défaut, K3s fournit un équilibreur de charge connu sous le nom de ServiceLB (anciennement Klipper LoadBalancer) qui utilise les ports hôtes disponibles.

Kubernetes en amont permet de créer des services de type LoadBalancer, mais n’inclut pas d’implémentation d’équilibreur de charge par défaut, donc ces services resteront pending jusqu’à ce qu’un soit installé. De nombreux services hébergés nécessitent un fournisseur de cloud tel qu’Amazon EC2 ou Microsoft Azure pour offrir une implémentation d’équilibreur de charge externe. En revanche, le ServiceLB de K3s permet d’utiliser des services de type LoadBalancer sans fournisseur de cloud ni configuration supplémentaire.

Comment fonctionne ServiceLB

Le contrôleur ServiceLB surveille les Services Kubernetes avec le champ spec.type défini sur LoadBalancer.

Pour chaque Service LoadBalancer, un DaemonSet est créé dans l’espace de noms kube-system. Ce DaemonSet crée à son tour des Pods ServiceLB avec un préfixe svc- sur chaque nœud. Ces pods utilisent hostPort avec le port de service, donc ils ne seront déployés que sur les nœuds ayant ce port disponible. S’il n’y a pas de nœuds avec ce port disponible, le LB restera en attente. Notez qu’il est possible d’exposer plusieurs Services sur le même nœud, tant qu’ils utilisent des ports différents.

Lorsque le Pod ServiceLB s’exécute sur un nœud ayant une IP externe configurée, l’IP externe du nœud est ajoutée à la liste d’adresses status.loadBalancer.ingress du Service avec ipMode: VIP. Sinon, l’IP interne du nœud est utilisée.

Si le trafic vers l’IP externe est soumis à Network Address Translation (NAT) - par exemple dans les clouds publics lorsque l’IP publique du nœud est utilisée comme IP externe - le trafic est acheminé vers le pod ServiceLB via le hostPort. Le pod utilise ensuite iptables pour rediriger le trafic vers l’adresse et le port ClusterIP du Service. Si le trafic n’est pas soumis au NAT et arrive avec une adresse de destination correspondant à l’adresse LoadBalancer, le trafic est intercepté (normalement par les chaînes iptables de kube-proxy ou ipvs) et redirigé vers l’adresse et le port ClusterIP du Service.

Syntaxe

Créez un Service de type LoadBalancer dans K3s.

Problème connu

Si le trafic externe atteint le nœud en utilisant un NAT (par exemple dans les clouds publics) et que vous avez besoin de externalTrafficPolicy=local pour des raisons telles que la préservation de l’IP source du client, veuillez ne pas définir la configuration de K3s node-external-ip sur aucun des nœuds, car cela ne fonctionnera pas correctement.

Contrôle de la sélection des nœuds ServiceLB

Ajouter l’étiquette svccontroller.k3s.cattle.io/enablelb=true à un ou plusieurs nœuds met le contrôleur ServiceLB en mode liste autorisée, où seuls les nœuds portant l’étiquette sont éligibles pour héberger des pods LoadBalancer. Les nœuds qui restent sans étiquette seront exclus de l’utilisation par ServiceLB.

Par défaut, les nœuds ne sont pas étiquetés. Tant que tous les nœuds restent sans étiquette, tous les nœuds avec des ports disponibles seront utilisés par ServiceLB.

Création de pools de nœuds ServiceLB

Pour sélectionner un sous-ensemble particulier de nœuds pour héberger des pods pour un LoadBalancer, ajoutez l’étiquette enablelb aux nœuds souhaités et définissez des valeurs d’étiquette correspondantes lbpool sur les Nœuds et les Services. Par exemple :

Étiquetez le Nœud A et le Nœud B avec svccontroller.k3s.cattle.io/lbpool=pool1 et svccontroller.k3s.cattle.io/enablelb=true.
Étiquetez le Nœud C et le Nœud D avec svccontroller.k3s.cattle.io/lbpool=pool2 et svccontroller.k3s.cattle.io/enablelb=true.
Créez un Service LoadBalancer sur le port 443 avec l’étiquette svccontroller.k3s.cattle.io/lbpool=pool1. Le DaemonSet pour ce service ne déploie que des Pods sur le Nœud A et le Nœud B.
Créez un autre Service LoadBalancer sur le port 443 avec l’étiquette svccontroller.k3s.cattle.io/lbpool=pool2. Le DaemonSet ne déploiera que des Pods sur le Nœud C et le Nœud D.

Désactivation de ServiceLB.

Pour désactiver ServiceLB, configurez tous les serveurs du cluster avec l’option --disable=servicelb.

Ceci est nécessaire si vous souhaitez exécuter un autre LB, tel que MetalLB.

Déploiement d’un Gestionnaire de Contrôleur Cloud Externe.

K3s fournit un Gestionnaire de Contrôleur Cloud (CCM) intégré qui fait ce qui suit :

Héberge le contrôleur LoadBalancer Service Load Balancer.
Supprime le taint node.cloudprovider.kubernetes.io/uninitialized.
Définit les champs d’adresse des nœuds en fonction des options --node-ip, --node-external-ip, --node-internal-dns et --node-external-dns.

Avant de déployer un CCM externe, vous devez démarrer tous les serveurs K3s avec le drapeau --disable-cloud-controller pour désactiver le CCM intégré. Lors de l’utilisation d’un CCM externe, les adresses des nœuds seront fournies par les API de métadonnées des instances du fournisseur de cloud, au lieu des valeurs de drapeau K3s.

Si vous désactivez le CCM intégré et ne déployez ni ne configurez correctement un substitut externe, les nœuds resteront marqués et non planifiables.