Service quick start - Container Service for Kubernetes - Centre de documentation Alibaba Cloud

Concepts clés

Service

L'accès direct aux pods après leur création peut entraîner plusieurs problèmes :

Un contrôleur, tel qu'un Deployment, peut terminer et recréer des pods à tout moment, ce qui rend l'accès direct peu fiable.
L'adresse IP d'un pod est attribuée dynamiquement au démarrage et ne peut pas être prédite à l'avance.
Une application se compose souvent de plusieurs pods exécutant la même image, ce qui rend peu pratique l'accès individuel à chaque pod.

Pour résoudre ces problèmes, Kubernetes propose l'objet Service, qui offre aux pods une interface réseau stable et une adresse IP persistante. Un Service utilise un sélecteur d'étiquettes pour identifier un groupe de pods cibles et répartit le trafic entre eux grâce à l'équilibrage de charge. Cette approche résout les problèmes liés à l'accès direct aux pods et garantit la haute disponibilité et l'efficacité de votre application.

Endpoint

Dans Kubernetes, un endpoint est une ressource clé utilisée par un Service pour la découverte de services. Il suit en temps réel les modifications apportées aux pods correspondant au sélecteur du Service. Lorsqu'un pod est supprimé ou recréé et que son adresse IP change, la ressource endpoint met immédiatement à jour sa liste d'adresses IP et de ports de pods. Cela garantit que le Service dirige toujours le trafic vers des pods actifs et sains.

IPVS

IPVS est un équilibreur de charge basé sur la fonctionnalité Linux Virtual Server (LVS) du noyau Linux. Il gère le trafic des Services en créant une adresse IP virtuelle qui distribue les requêtes aux pods backend.

Lorsque vous créez un Service dans Kubernetes, kube-proxy configure des règles dans la table IPVS. Ces règles définissent la manière dont le trafic est transféré depuis l'IP virtuelle du nœud vers les pods backend. Vous pouvez afficher la table de routage IPVS actuelle et ses règles sur un nœud du cluster à l'aide de la commande ipvsadm.

Important

Si l'outil ipvsadm n'est pas installé, exécutez la commande sudo yum install ipvsadm pour l'installer.

iptables

iptables fonctionne avec un ensemble de tables et de chaînes configurables. Chaque chaîne contient un ensemble de règles qui contrôlent le flux des paquets réseau.

Lorsque vous créez un Service dans Kubernetes, kube-proxy ajoute les règles correspondantes à iptables. Ces règles utilisent le sélecteur d'étiquettes du Service pour transférer les paquets vers les pods corrects. Vous pouvez afficher la table NAT iptables actuelle et ses règles sur un nœud du cluster à l'aide de la commande iptables -t nat -L.

nftables

nftables est le framework de filtrage de paquets de nouvelle génération du noyau Linux, conçu pour remplacer iptables. Il utilise un ensemble de règles unifié et un mécanisme de correspondance de paquets plus efficace pour gérer les règles de trafic réseau.

Lorsque vous créez un Service dans un cluster Kubernetes, kube-proxy utilise l'API nftables pour créer des tables et des chaînes qui gèrent les règles de transfert de trafic du Service. Vous pouvez afficher toutes les règles nftables actives et les structures de tables sur un nœud du cluster à l'aide de la commande nft list ruleset.

Types de services

Important

Si la version de Cloud Controller Manager est la v2.5.0 ou ultérieure, l'utilisation d'une instance CLB pour créer un Service dans la console devient une fonctionnalité sur liste blanche qui prend uniquement en charge la facturation au paiement à l'utilisation. Pour créer un Service de type CLB dans la console, soumettez une demande sur la page du Quota Center.

Nom	Description	Cas d'utilisation	Facturation
ClusterIP	Type de Service par défaut. Un Service ClusterIP reçoit une adresse IP virtuelle accessible uniquement depuis l'intérieur du cluster.	Idéal pour les services qui doivent communiquer uniquement au sein du même cluster. Par exemple, si un pod d'application frontend doit accéder à une base de données backend au sein du même cluster, vous pouvez exposer la base de données en tant que Service ClusterIP.	Gratuit.
NodePort	Un Service NodePort ouvre un port spécifique sur chaque nœud du cluster. Vous pouvez accéder au Service depuis l'extérieur du cluster en utilisant `<NodeIP>:<NodePort>`. Ce mécanisme opère principalement au niveau de la couche 4 (couche Transport) du modèle OSI.	Convient pour exposer un service à Internet pour le développement, les tests ou d'autres applications à faible trafic. Par exemple, vous pouvez utiliser un Service NodePort pour déployer et déboguer une application web dans un environnement de test. Contrairement à un Service LoadBalancer, il ne fournit pas d'équilibrage de charge entre les nœuds. Le trafic est envoyé vers un seul nœud, ce qui peut facilement devenir un goulot d'étranglement des ressources.	Gratuit. Pour activer l'accès à Internet public, vous devez associer une EIP au nœud. Pour plus d'informations sur la facturation des EIP, consultez la Vue d'ensemble de la facturation.
LoadBalancer	Un Service LoadBalancer étend le type NodePort en provisionnant un équilibreur de charge externe qui distribue le trafic entre les pods du cluster. Le Service fournit automatiquement une adresse IP externe que les clients peuvent utiliser pour y accéder. Il prend en charge la gestion du trafic de couche 4 (TCP/UDP) et de couche 7 (HTTP/HTTPS).	Idéal pour les applications s'exécutant sur un cloud public qui nécessitent un point d'entrée externe stable et facile à gérer. Par exemple, les services publics dans un environnement de production qui doivent être accessibles depuis Internet et gérer de grands volumes de trafic externe avec une haute disponibilité, tels que les applications web ou les services API. Important Pour la communication intra-cluster, utilisez toujours un Service `ClusterIP`. C'est la méthode la plus stable, efficace et architecturalement solide. En revanche, l'accès à un Service de type `LoadBalancer` depuis le même cluster peut entraîner un comportement incohérent. Sa disponibilité est affectée par plusieurs facteurs, notamment : L'implémentation spécifique du LoadBalancer par le fournisseur de cloud. Le plugin réseau CNI utilisé par le cluster (tel que Flannel, Terway-Eniip ou Cilium). Le mode de fonctionnement (iptables, IPVS ou nftables) et la version de `kube-proxy`. Le paramètre `externalTrafficPolicy` du Service (`Cluster` ou `Local`). Par conséquent, l'accès à une IP LoadBalancer depuis l'intérieur du cluster peut varier considérablement, voire échouer, selon les environnements et les versions de Kubernetes. Scénario d'exemple : Flannel + IPVS + externalTrafficPolicy=Local Considérons un cluster qui utilise le plugin réseau CNI Flannel où un Service `LoadBalancer` est configuré avec `externalTrafficPolicy: Local`. Si une requête est envoyée à l'IP externe du LoadBalancer depuis un nœud qui ne possède pas de pod backend correspondant : Version Kubernetes < 1.24 : la requête ne sera pas transférée correctement et l'accès échouera. Version Kubernetes ≥ 1.24 : `kube-proxy` peut revenir du comportement `Local` au comportement `Cluster` pour prendre en charge l'accès intra-cluster. La requête sera transférée avec succès vers un pod backend sur un autre nœud.	Pour plus d'informations sur les frais relatifs aux instances d'équilibrage de charge, consultez Vue d'ensemble de la facturation CLB Règles de facturation NLB.
Service Headless	Un Service Headless ne possède pas d'adresse IP virtuelle. Une requête DNS pour le nom du service renvoie une liste d'adresses IP de pods au lieu d'une seule IP de service. Cela vous permet de découvrir et de vous connecter directement à des pods spécifiques.	Idéal pour les applications qui doivent communiquer directement avec des pods backend spécifiques plutôt que via un proxy ou un équilibreur de charge. Par exemple, si vous déployez une application stateful telle qu'un service de base de données ClickHouse, vous pouvez utiliser un Service Headless. Cela permet aux pods d'application d'accéder directement à chaque pod ClickHouse, équilibrant ainsi les lectures de données ou effectuant des écritures ciblées pour améliorer l'efficacité du traitement des données.	Gratuit.
ExternalName	Un Service ExternalName mappe un nom de service interne à un nom de domaine externe. Cela permet aux pods à l'intérieur du cluster d'accéder au domaine externe en utilisant le nom de service interne.	Idéal lorsqu'un cluster doit accéder à un service exposé sous un nom de domaine public. Par exemple, si vos pods d'application doivent accéder à un domaine de base de données externe, vous pouvez utiliser un Service ExternalName pour mapper le domaine à un nom de service interne, ce qui permet un accès direct depuis l'intérieur du cluster.	Gratuit.

Fonctionnement

ClusterIP

Création et allocation

Lorsque vous créez un Service ClusterIP dans un cluster ACK, le plan de contrôle lui attribue une adresse IP virtuelle (ClusterIP) accessible uniquement depuis l'intérieur du cluster.
Transfert de trafic

Lorsque vous accédez au ClusterIP, kube-proxy intercepte le trafic et le transfère vers un pod backend en utilisant un algorithme d'ordonnancement round-robin.
Découverte de service

Lorsqu'un Service ClusterIP est créé, CoreDNS enregistre un enregistrement DNS pour celui-ci, permettant au service d'être résolu et consulté par son nom. Le format est service-name.namespace.svc.cluster.local:port, par exemple nginx.default.svc.cluster.local:80.
Étiquettes de pod et suivi des endpoints

Un Service utilise un sélecteur d'étiquettes pour identifier ses pods backend.

Le plan de contrôle surveille en continu les modifications des pods. Lorsque des pods correspondant au sélecteur d'étiquettes du Service sont ajoutés, mis à jour ou supprimés, le plan de contrôle met à jour l'endpoint.

NodePort

Création et allocation

Lorsque vous créez un Service NodePort, le cluster ouvre un port (le NodePort) sur ses nœuds pour permettre l'accès externe.
Transfert de trafic

kube-proxy écoute sur le NodePort, qui est choisi automatiquement dans une plage par défaut de 30000-32767. Il achemine les requêtes externes vers le ClusterIP, qui les transfère ensuite aux pods backend.
Accès externe

Vous pouvez accéder au Service de l'extérieur en utilisant l'adresse IP du nœud et le port statique (NodePort) au format <NodeIP>:<NodePort>.

LoadBalancer

Création et allocation

Lorsque vous créez un Service LoadBalancer, le plan de contrôle interagit automatiquement avec le service d'équilibrage de charge pour créer une instance d'équilibreur de charge afin de gérer le trafic. Pour plus d'informations, consultez Utiliser une instance Server Load Balancer existante pour exposer une application et Exposer une application avec un service LoadBalancer provisionné automatiquement.
Transfert de trafic

Lorsque le trafic externe atteint l'IP externe de l'instance d'équilibreur de charge, il est acheminé vers le port sur les nœuds. Ensuite, kube-proxy transfère le trafic vers les pods backend.
Configuration des routes et des vérifications d'état

L'équilibreur de charge configure automatiquement les ports d'écoute et effectue des vérifications d'état pour garantir que le trafic n'est acheminé que vers des pods sains.

Stratégie de trafic externe

Les Services LoadBalancer et NodePort disposent d'un paramètre externalTrafficPolicy qui contrôle la manière dont le trafic externe est acheminé. Le comportement de ce paramètre diffère entre les clusters utilisant les plugins réseau Terway-Eniip et Flannel.

Remarque

Connectez-vous à la console ACK. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans l'onglet Basic Information, vous pouvez consulter le plugin réseau CNI utilisé par votre cluster.

Plugin réseau Flannel

Élément	Local	Cluster
Ajout des serveurs backend	Seuls les nœuds hébergeant des pods backend sont ajoutés en tant que serveurs backend à l'équilibreur de charge.	Tous les nœuds du cluster sont ajoutés en tant que serveurs backend à l'équilibreur de charge.
Quota d'équilibreur de charge	Consomme moins de ressources de quota d'équilibreur de charge. Pour plus d'informations, consultez les Limites de quota.	Consomme un grand nombre de ressources de quota d'équilibreur de charge car tous les nœuds du cluster sont attachés en tant que backends. Pour plus d'informations, consultez les Limites de quota.
Accès intra-cluster au Service	Seuls les nœuds hébergeant des pods backend pour le Service peuvent y accéder.	N'importe quel nœud du cluster peut accéder au Service.
Équilibrage de charge des pods	L'équilibrage de charge entre les pods est désactivé par défaut. Pour activer l'équilibrage de charge, définissez l'ordonnanceur sur WRR en ajoutant l'annotation `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` au Service.	L'équilibrage de charge entre les pods est activé par défaut.
Préservation de l'IP source	Prise en charge.	Non pris en charge.
Persistance de session	Prise en charge.	Non pris en charge.
Cas d'utilisation	Applications nécessitant de préserver l'adresse IP client d'origine, par exemple pour la journalisation basée sur l'IP source.	Lorsqu'une haute disponibilité du service est requise et que la préservation de l'IP source n'est pas une préoccupation, comme dans les grands clusters d'applications web.

Plugin réseau Terway-Eniip

Élément	Local	Cluster
Ajout des serveurs backend	Les pods sont directement ajoutés à l'équilibreur de charge en tant que serveurs backend.
Quota d'équilibreur de charge	Consomme moins de ressources de quota d'équilibreur de charge car seuls les pods d'application sont attachés. Pour plus d'informations, consultez les Limites de quota.
Accès intra-cluster au Service	Lors de l'accès au Service depuis l'intérieur du cluster, le trafic passe par kube-proxy sur le nœud et est soumis au paramètre `externalTrafficPolicy`. Par conséquent, seuls les nœuds hébergeant des pods backend pour le Service peuvent y accéder.	N'importe quel nœud du cluster peut accéder au Service.
Équilibrage de charge des pods	L'équilibrage de charge entre les pods est activé par défaut.
Préservation de l'IP source	Prise en charge.
Persistance de session	Prise en charge.

Remarques d'utilisation

Avant d'utiliser la fonctionnalité d'équilibrage de charge des Services, examinez les considérations pertinentes. Pour plus d'informations, consultez la section Considérations pour la configuration de l'équilibrage de charge des Services.

Container Service for Kubernetes:Service quick start