Description de l'équilibrage de charge de charge pour les applications via la reconnaissance de service Kubernetes

La reconnaissance de service Kubernetes fournit une connexion réseau aux applications en utilisant des services de réseau et un proxy Kubernetes local.

Tous les pods qui sont déployés sur un noeud worker bénéficient d'une adresse IP privée dans la plage 172.30.0.0/16 et sont uniquement acheminés entre des noeuds worker. Pour éviter des conflits, n'utilisez pas cette plage d'adresses IP sur des noeuds qui communiquent avec vos noeuds worker. Les noeuds worker et les pods peuvent communiquer de manière sécurisée sur le réseau privé en utilisant des adresses IP privées. Toutefois, lorsqu'un pod tombe en panne ou qu'un noeud worker a besoin d'être recréé, une nouvelle adresse IP privée lui est affectée.

Au lieu d'essayer de suivre les adresses IP privées fluctuantes pour des applications qui doivent être hautement disponibles, vous pouvez utiliser les fonctions de reconnaissance de service Kubernetes intégrées pour exposer les applications sous forme de services. Un service Kubernetes regroupe un ensemble de pods et procure une connexion réseau vers ces pods. Le service sélectionne les pods ciblés vers lesquels il achemine le trafic via des libellés.

Un service fournit la connectivité entre vos pods d'application et d'autres services dans le cluster sans exposer l'adresse IP privée réelle de chaque pod. Les services se voient affecter une adresse IP interne, clusterIP, accessible uniquement au sein du cluster. Cette adresse IP est liée au service pendant l'intégralité de son cycle de vie et ne change pas tant que le service existe. Les services reçoivent une adresse IP de l'une des 65 000 adresses IP de la plage 172.21.0.0/16.

Pour éviter des conflits, n'utilisez pas cette plage d'adresses IP sur des noeuds qui communiquent avec vos noeuds worker. Une entrée de recherche DNS est également créée pour le service et stockée dans le composant kube-dns du cluster. L'entrée DNS contient le nom du service, l'espace de noms dans lequel il a été créé et le lien vers l'adresse IP interne au cluster.

Si vous prévoyez de connecter votre cluster à des réseaux sur site via IBM Cloud ou un service VPN, des conflits de sous-réseau peuvent se produire avec la plage 172.30.0.0/16 par défaut pour les pods et la plage 172.21.0.0/16 pour les services. Vous pouvez éviter les conflits de sous-réseau lorsque vous créez un cluster en spécifiant un sous-réseau CIDR personnalisé pour les pods dans l'option --pod-subnet et un sous-réseau CIDR personnalisé pour les services dans l'option --service-subnet.

Pour assurer l'équilibrage de charge de base de tout le trafic réseau TCP et UDP pour les services, un proxy de réseau local Kubernetes, kube-proxy, s'exécute en tant que démon sur chaque noeud worker dans l'espace de nom kube-system. kube-proxy utilise des règles Iptables, une fonction du noyau Linux pour diriger uniformément les demandes vers le pod derrière un service, indépendamment des adresses IP en cluster et du noeud worker sur lequel elles sont déployées.

Par exemple, les applications au sein du cluster peuvent accéder à un pod situé derrière un service de cluster en utilisant l'adresse IP interne au cluster des services ou en envoyant une demande ay nom du service. Lorsque vous utilisez le nom du service, kube-proxy recherche ce nom dans le fournisseur DNS de cluster et achemine la demande vers l'adresse IP interne au cluster du service.

Si vous utilisez un service qui fournit à la fois une adresse IP de cluster interne et une adresse IP externe, les clients en dehors du cluster peuvent envoyer des demandes au public externe ou à l'adresse IP privée du service. kube-proxy transmet les demandes à l'adresse IP du service en cluster et les équilibres de charge entre les pods d'application derrière le service.

Description des types de service Kubernetes

Kubernetes prend en charge quatre types de service réseau : ClusterIP, NodePort, LoadBalancer et Ingress. Les services ClusterIP rendent vos applications accessibles en interne pour permettre la communication entre les pods de votre cluster uniquement. Les services NodePort, LoadBalancer et Ingress rendent vos applications accessibles en externe à partir de l'internet public ou d'un réseau privé.

Le tableau suivant compare les fonctions de chaque type de service réseau :

* Un certificat SSL pour l'équilibrage de charge HTTPS est fourni par les commandes ibmcloud ks nlb-dns. Dans les clusters classiques, ces commandes sont prises en charge uniquement pour les équilibreurs de charge de réseau public.

NodePort

Lorsque vous exposez des applications avec un service NodePort, un NodePort compris entre 30000 et 32767 et une adresse IP interne au cluster sont attribués au service. Pour accéder au service depuis l'extérieur de la grappe, vous devez utiliser l'adresse IP publique ou privée d'un nœud de travail et le NodePort au format <IP_address>:<nodeport>. Toutefois, les adresses IP publique et privée du noeud worker ne sont pas permanentes. Lorsqu'un noeud worker est supprimé ou recréé, une nouvelle adresse IP publique et une nouvelle adresse IP privée sont affectées au noeud worker.

Les valeurs NodePort sont idéales pour tester un accès public ou privé ou pour fournir un accès sur une courte période. Remarque : comme les noeuds worker des clusters VPC n'ont pas d'adresse IP publique, vous pouvez accéder à une application via un port de nœud uniquement si vous êtes connecté à votre réseau VPC privé, par exemple, via une connexion VPN.

LoadBalancer

Le type de service LoadBalancer est implémenté différemment selon le fournisseur d'infrastructure de votre cluster.

Services LoadBalancer dans les clusters classiques

Infrastructure classique

Equilibreur de charge de réseau(NLB). Chaque cluster standard est mis à disposition avec quatre adresses IP publiques portables et quatre adresses IP privées portables que vous pouvez utiliser pour créer un équilibreur de charge de réseau (NLB) TCP/UDP pour votre application. Vous pouvez personnaliser votre équilibreur de charge de réseau en exposant n'importe quel port dont votre application a besoin. Les adresses IP publiques et privées portables affectées au NLB sont permanentes et ne changent pas lorsqu'un noeud worker est recréé dans le cluster. Vous pouvez créer un sous-domaine pour votre application, qui enregistrera les adresses IP d'équilibreur de charge de réseau (NLB) publiques avec une entrée DNS. Vous pouvez également activer des moniteurs de diagnostic d'intégrité sur les adresses IP d'équilibreur de charge de réseau (NLB) pour chaque sous-domaine.

Services LoadBalancer dans les clusters de VPC

Virtual Private Cloud

Equilibreur de charge pour VPC. Lorsque vous créez un service Kubernetes LoadBalancer pour une application dans votre cluster, un équilibreur de charge VPC est automatiquement créé dans votre VPC, en dehors de votre cluster. L'équilibreur de charge VPC comprend plusieurs zones et achemine des demandes pour votre application via les ports de noeud privés qui sont automatiquement ouverts sur vos noeuds worker. Par défaut, l'équilibreur de charge est également créé avec un nom d'hôte que vous pouvez utiliser pour accéder à votre application.

Ingress

Exposez plusieurs applications dans un cluster en configurant le routage avec l'équilibreur de charge d'application (ALB) d'Ingress. L'équilibreur de charge d'application utilise un point d'entrée public ou privé unique et sécurisé, un sous-domaine Ingress, pour acheminer les demandes entrantes vers vos applications. Vous pouvez utiliser un seul sous-domaine pour exposer plusieurs applications dans votre cluster sous forme de services. Ingress comporte trois composants :

• La ressource Ingress définit les règles de routage et d'équilibrage de charge des demandes entrantes pour une application.
• L'équilibreur de charge d'application (ALB) est à l'écoute des demandes de service HTTP, HTTPS ou TCP entrantes. Il transmet les demandes aux pods des applications en fonction des règles que vous avez définies dans la ressource Ingress.
• L'équilibreur de charge multizone (MZLB) pour les clusters classiques ou l'équilibreur de charge VPC pour les clusters VPC gère toutes les demandes entrantes vers vos applications et équilibre la charge des demandes en les répartissant entre les ALB dans les différentes zones. Il active également des diagnostics d'intégrité pour les adresses IP Ingress publiques.

Planification d'un équilibrage de charge externe public

Exposez au public une application de votre cluster sur Internet.

Dans les clusters classiques, vous pouvez connecter des noeuds worker à un VLAN public. Le VLAN public détermine l'adresse IP publique qui est affectée à chaque noeud worker, ce qui offre à chaque noeud worker une interface réseau publique. Les services de mise en réseau public se connectent à cette interface de réseau public en fournissant à votre application une adresse IP publique et, le cas échéant, une URL publique.

Dans les clusters VPC, vos noeuds worker sont connectés uniquement aux sous-réseaux VPC privés. Toutefois, lorsque vous créez des services de réseau public, un équilibreur de charge VPC est automatiquement créé. L'équilibreur de charge VPC peut acheminer les demandes publiques vers votre application en fournissant une URL publique à votre application. Lorsqu'une application est exposée au public, quiconque disposant de l'URL publique peut envoyer une demande à votre application.

Lorsqu'une application est exposée au public, quiconque disposant de l'adresse IP de service public ou de l'URL que vous avez configurée pour votre application peut envoyer une demande à cette dernière. C'est pourquoi il est recommandé d'exposer le moins d'applications possible. Exposez une application au public uniquement lorsque vous êtes prêt à accepter du trafic provenant de clients Web ou d'utilisateurs externes.

L'interface réseau publique des noeuds worker est protégée par des paramètres de règles réseau Calico prédéfinis qui sont configurés sur tous les noeuds worker lors de la création du cluster. Par défaut, tout le trafic réseau sortant est autorisé pour tous les noeuds worker. Le trafic réseau entrant est bloqué à l'exception de quelques ports. Ces ports sont ouverts de sorte qu'IBM puisse surveiller le trafic réseau et installer automatiquement les mises à jour de sécurité pour le maître Kubernetes et que les connexions puissent être établies avec les services NodePort, LoadBalancer et Ingress. Pour plus d'informations sur ces règles, y compris comment les modifier, voir Règles réseau.

Choix d'un modèle de déploiement pour les clusters classiques

Pour rendre une application accessible au public sur Internet dans un cluster classique, choisissez un modèle de déploiement d'équilibrage de charge qui utilise des services NodePort, LoadBalancer ou Ingress publics. Le tableau ci-après décrit chaque modèle de déploiement possible, et explique pour quelle raison l'utiliser et comment le configurer. Pour obtenir des informations de base sur les services de mise en réseau utilisés par ces modèles de déploiement, utilisez Description des types de service Kubernetes.

Choix d'un modèle de déploiement pour les clusters VPC

Pour rendre une application accessible au public sur Internet dans un cluster VPC, choisissez un modèle de déploiement d'équilibrage de charge qui utilise des services LoadBalancer ou Ingress publics. Le tableau ci-après décrit chaque modèle de déploiement possible, et explique pour quelle raison l'utiliser et comment le configurer. Pour obtenir des informations de base sur les services de mise en réseau utilisés par ces modèles de déploiement, utilisez Description des types de service Kubernetes.

Planification d'un équilibrage de charge externe privé

Exposez en privé une application de votre cluster sur le réseau privé uniquement.

Lorsque vous déployez une application dans un cluster Kubernetes dans IBM Cloud Kubernetes Service, vous souhaitez peut-être rendre l'application accessible uniquement aux utilisateurs et services qui se trouvent sur le même réseau privé que votre cluster. L'équilibrage de charge privé est idéal pour rendre votre application disponible pour des demandes depuis l'extérieur du cluster sans exposer l'application au public général. Vous pouvez également utiliser l'équilibrage de charge privé pour tester des accès, demander du routage et d'autres configurations pour votre application avant de l'exposer ultérieurement au public avec des services réseau public.

A titre d'exemple, admettons que vous ayez créé un équilibreur de charge de réseau privé pour votre application. Cet équilibreur de charge de réseau privé est accessible à :

• Tout pod figurant dans le même cluster.
• Tout pod figurant dans n'importe quel cluster dans le même compte IBM Cloud.
• Si vous n'êtes pas dans le compte IBM Cloud mais toujours derrière le pare-feu de l'entreprise, tout système via une connexion VPN au sous-réseau sur lequel figure l'adresse IP de l'équilibreur de charge.
• Si vous n'êtes pas dans le compte IBM Cloud, tout système via une connexion VPN au sous-réseau sur lequel figure l'adresse IP de l'équilibreur de charge.
• Dans les clusters classiques, si la fonction VRF ou Spanning VLAN est activée, tout système connecté à l'un des VLAN privés dans le même compte IBM Cloud.
• Dans les clusters de VPC :
  • Si vous autorisez le trafic entre les sous-réseaux VPC, n'importe quel système sur le même VPC.
  • Si vous autorisez le trafic entre les VCP, tout système qui a accès au VPC dans lequel se trouve le cluster.