Connexions VLAN pour les noeuds worker

Tous les noeuds worker doivent être connectés à un VLAN privé de sorte que chaque noeud worker puisse envoyer des informations à et recevoir des informations d'autres noeuds worker. Le VLAN privé fournit des sous-réseaux privés qui sont utilisés pour affecter des adresses IP privées à vos noeuds worker et à vos services d'application privés. Vous pouvez créer un cluster avec des noeuds worker qui sont également connectés à un VLAN public. Le VLAN public fournit des sous-réseaux publics qui sont utilisés pour affecter des adresses IP publiques à vos noeuds worker et à vos services d'application publics. Toutefois, si vous devez sécuriser vos applications depuis l’interface réseau publique, plusieurs options s’offrent à vous pour sécuriser votre cluster, telles que la création de politiques réseau Calico ou l’isolation des charges de travail du réseau externe vers des nœuds de travail périphériques.

La première fois que vous créez un cluster dans une zone, un VLAN public et un VLAN privé dans cette zone sont automatiquement provisionnés pour vous dans votre compte d'infrastructure IBM Cloud. Si vous spécifiez que des noeuds worker doivent être connectés à un VLAN privé uniquement, un VLAN privé uniquement est mis à disposition automatiquement. Pour tous les autres clusters que vous créez dans cette zone, vous pouvez spécifier la paire de VLAN que vous souhaitez utiliser. Vous pouvez réutiliser le même VLAN public et le même VLAN privé que vous avez créés pour vous car les VLAN peuvent être partagés par plusieurs clusters.

Pour plus d'informations sur les VLAN, les sous-réseaux et les adresses IP, voir Présentation de la mise en réseau dans IBM Cloud Kubernetes Service.

Besoin de créer votre cluster à l'aide de sous-réseaux personnalisés ? Consultez la rubrique Utilisation de sous-réseaux existants pour créer un cluster.

Communication de nœud worker sur les sous-réseaux et les réseaux locaux virtuels

Dans de nombreuses situations, les composants présents dans votre cluster doivent être autorisés à communiquer sur plusieurs VLAN privés. Par exemple, si vous souhaitez créer un cluster à zones multiples, si vous avez plusieurs réseaux locaux virtuels pour un cluster, ou si vous avez plusieurs sous-réseaux sur le même réseau local virtuel, les nœuds worker sur différents sous-réseaux du même réseau local virtuel ou dans des réseaux locaux virtuels différents ne peuvent pas communiquer automatiquement entre eux. Vous devez activer la fonction VRF ou Spanning VLAN pour votre compte d'infrastructure IBM Cloud.

• Virtual Routing and Forwarding (VRF) : Une fonction VRF active tous les VLAN et les sous-réseaux dans votre compte d'infrastructure pour qu'ils communiquent entre eux. De plus, une fonction VRF est requise pour autoriser vos noeuds worker et le maître à communiquer via le noeud final de service cloud privé et pour communiquer avec d'autres instances IBM Cloud qui prennent en charge les noeuds finaux de service de cloud privé. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Pour activer VRF, exécutez la commande ibmcloud account update --service-endpoint-enable true. Le résultat de cette commande vous invite à ouvrir un cas de support pour permettre à votre compte d'utiliser une fonction VRF et des points finaux de service. La fonction VRF élimine l'option Spanning VLAN de votre compte car tous les VLAN sont en mesure de communiquer. Lorsque la fonction VRF est activée, tout système qui est connecté à l'un de vos VLAN privés dans le même compte IBM Cloud peut communiquer avec les noeuds worker du cluster. Vous pouvez isoler votre cluster des autres systèmes sur le réseau privé en appliquant des règles réseau privé Calico.
• Extension VLAN: vous ne pouvez pas activer le point de terminaison du service de cloud privé si vous choisissez d'activer l'extension VLAN plutôt que le VRF. Activez le VLAN spanning lorsque vous ne pouvez pas ou ne souhaitez pas activer le VRF, par exemple lorsque vous n'avez pas besoin que le maître soit accessible sur le réseau privé ou si vous utilisez un appareil passerelle pour accéder au maître via le VLAN public. Remarque : par exemple, si vous disposez déjà d’un appareil passerelle et que vous ajoutez ensuite un cluster, les nouveaux sous-réseaux portables commandés pour le cluster ne sont pas configurés sur l’appareil passerelle, mais la fonction VLAN Spanning permet le routage entre les sous-réseaux.

Noeud final de service public

Si vous ne voulez pas ou ne pouvez pas activer VRF pour votre compte, vos nœuds worker peuvent automatiquement se connecter au maître Kubernetes sur le VLAN via le nœud final de service de cloud public.

• La communication entre les noeuds worker et le maître est établie de manière sécurisée sur le réseau public via le noeud final de service cloud public.
• Le maître est accessible au public pour les utilisateurs de cluster autorisés uniquement via le noeud final de service cloud public. Les utilisateurs de votre cluster peuvent accéder de manière sécurisée à votre maître Kubernetes sur Internet pour exécuter des commandes kubectl, par exemple.
• Vous pouvez éventuellement sécuriser l'accès aux points d'extrémité des services publics et privés de votre cluster en utilisant des restrictions basées sur le contexte.

Nœuds finaux de service de cloud public et privé

Pour rendre votre maître accessible au public ou en privé aux utilisateurs du cluster, vous pouvez activer les noeuds finaux de service cloud publics et privés. La fonction VRF est requise dans votre compte IBM Cloud et vous devez activer votre compte pour l'utilisation de noeuds finaux de service. Pour activer la fonction VRF et des noeuds finaux de service, exécutez ibmcloud account update --service-endpoint-enable true.

• Si des noeuds worker sont connectés aux VLAN publics et privés, la communication entre les noeuds worker et le maître est établie sur le réseau privé via le noeud final de service cloud privé et sur le réseau public via le noeud final de service cloud public. En acheminant la moitié du trafic worker vers maître via le noeud final public et l'autre moitié via le noeud final privé, votre communication maître vers worker est protégée contre d'éventuelles pannes du réseau public ou privé. Si des noeuds worker sont connectés aux VLAN privés uniquement, la communication entre les noeuds worker et le maître est établie sur le réseau privé via le noeud final de service cloud privé uniquement.
• Le maître est accessible au public pour les utilisateurs de cluster autorisés via le noeud final de service cloud public. Le maître est accessible en privé via le noeud final de service cloud privé si les utilisateurs de cluster autorisés se trouvent dans votre réseau privé IBM Cloud ou s'ils sont connectés au réseau privé via une connexion VPN ou IBM Cloud Direct Link. Notez que vous devez exposer le noeud final maître via un équilibreur de charge privé de sorte que les utilisateurs puissent accéder au maître via une connexion VPN ou IBM Cloud Direct Link.
• Vous pouvez éventuellement sécuriser l'accès aux points d'extrémité des services publics et privés de votre cluster en utilisant des restrictions basées sur le contexte.

Noeud final de service privé uniquement

Pour rendre votre maître accessible uniquement en privé, vous pouvez activer le noeud final de service de cloud privé. La fonction VRF est requise dans votre compte IBM Cloud et vous devez activer votre compte pour l'utilisation de noeuds finaux de service. Pour activer la fonction VRF et des noeuds finaux de service, exécutez ibmcloud account update --service-endpoint-enable true. Notez que l'utilisation de noeud final de service cloud privé entraîne des frais de bande passante non facturés ou non mesurés.

• La communication entre les noeuds worker et le maître est établie sur le réseau privé via le noeud final de service de cloud privé.
• Le maître est accessible en privé si les utilisateurs de cluster autorisés figurent dans votre réseau privé IBM Cloud ou s'ils sont connectés au réseau privé via une connexion VPN ou Direct Link. Notez que vous devez exposer le noeud final maître via un équilibreur de charge privé de sorte que les utilisateurs puissent accéder au maître via une connexion VPN ou Direct Link.
• Vous pouvez éventuellement sécuriser l'accès aux points d'extrémité des services publics et privés de votre cluster en utilisant des restrictions basées sur le contexte.

Communication avec d'autres services IBM Cloud sur le réseau privé ou public

Vos noeuds worker peuvent communiquer automatiquement et en toute sécurité avec d'autres services IBM Cloud qui prennent en charge des noeuds finaux de service de cloud privé, par exemple, IBM Cloud® Container Registry, sur votre réseau privé d'infrastructure IBM Cloud. Si un service IBM Cloud ne prend pas en charge des noeuds finaux de service de cloud privé, vos noeuds worker doivent être connectés à un VLAN public de manière à pouvoir communiquer en toute sécurité avec les services sur le réseau public.

Si vous utilisez des stratégies Calico ou un dispositif de passerelle pour contrôler les réseaux public ou privé de vos noeuds worker, vous devez autoriser l'accès aux adresses IP publiques des services qui prennent en charge les noeuds finaux de service cloud publics et éventuellement aux adresses IP privées des services qui prennent en charge les noeuds finaux de service de cloud privé.

• Autoriser l'accès aux adresses IP publiques des services dans les règles Calico
• Autoriser l'accès aux adresses IP privées des services qui prennent en charge les noeuds finaux de service de cloud privé dans les stratégies Calico
• Autoriser l'accès aux adresses IP publiques des services et aux adresses IP privées des services qui prennent en charge les noeuds finaux de service de cloud privé dans un pare-feu de dispositif de passerelle

IBM Cloud® Direct Link pour la communication sur le réseau privé avec des ressources dans les centres de données sur site

Pour connecter votre cluster à votre centre de données sur site, par exemple avec IBM Cloud Private, vous pouvez configurer IBM Cloud Direct Link. Avec IBM Cloud Direct Link, vous pouvez créer une connexion privée directe entre vos environnements de réseau distants et IBM Cloud Kubernetes Service sans routage sur l'internet public.

Connexion VPN pour la communication via le réseau public avec des ressources situées dans des centres de données sur site

• Les nœuds de travail qui sont connectés à des VLAN publics et privés : Configurez un service VPN dans votre cluster pour fournir un canal de communication sécurisé de bout en bout sur Internet entre votre cluster et un réseau sur site. Plusieurs options open source existent, voir Connectivité VPN classique.

• Nœuds de travail connectés uniquement à un VLAN privé : configurez un point d'accès VPN sur un appareil de passerelle, tel qu'un Vyatta ( Virtual Router Appliance ).

Si vous prévoyez de connecter votre cluster à des réseaux sur site, reportez-vous aux informations utiles suivantes :

• Des conflits de sous-réseau peuvent se produire avec la plage 172.30.0.0/16 fournie par défaut par IBM pour les pods et la plage 172.21.0.0/16 pour les services. Vous pouvez éviter les conflits de sous-réseaux lorsque vous créez un cluster à partir de l'interface de ligne de commande(CLI) en spécifiant un CIDR de sous-réseau personnalisé pour les pods dans l'option --pod-subnet et un CIDR de sous-réseau personnalisé pour les services dans l'option --service-subnet.
• Si votre solution VPN conserve les adresses IP source des demandes, vous pouvez créer des routes statiques personnalisées pour vous assurer que vos noeuds worker peuvent acheminer des réponses depuis votre cluster vers votre réseau sur site.
• Sachez que les plages de sous-réseaux 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 et 172.20.0.0/16 sont interdites car elles sont réservées pour la fonctionnalité de plan de contrôle IBM Cloud Kubernetes Service.

Trafic privé vers applications de cluster

Lorsque vous déployez une application dans votre cluster, 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. Pour autoriser les demandes de trafic privées depuis l'extérieur du cluster vers vos applications, vous pouvez créer des services de mise en réseau Kubernetes privés, tels que des ports de noeud privés, des équilibreurs de charge de réseau et des équilibreurs de charge d'application Ingress. Vous pouvez ensuite utiliser des règles pré-DNAT Calico pour bloquer le trafic vers des ports de noeud publics de services de mise en réseau privés. Pour plus d'informations, voir Planification de l'équilibrage de charge externe privé.

Trafic public vers les applications de cluster

Pour rendre vos applications accessibles de façon externe à partir de l'internet public, vous pouvez créer des ports de noeud publics, des équilibreurs de charge de réseau (NLB) et des équilibreurs de charge d'application (ALB) Ingress. 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, selon le service, une URL publique. 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. Vous pouvez ensuite utiliser des règles pré-DNAT Calico pour contrôler le trafic vers les services de mise en réseau publics, par exemple, en autorisant le trafic provenant de certaines adresses IP source ou certains routages CIDR et en bloquant tous les autres trafics. Pour plus d'informations, voir Planification de l'équilibrage de charge externe public.

Pour plus de sécurité, vous pouvez isoler les charges de travail réseau sur des nœuds de travail en périphérie.

Les noeuds worker de périphérie peuvent améliorer la sécurité de votre cluster en limitant les accès depuis l'extérieur aux noeuds worker qui sont connectés à des VLAN publics et en isolant la charge de travail du réseau. Lorsque vous labellisez des noeuds worker en tant que noeuds de périphérie, les pods d'équilibreur de charge de réseau et d'équilibreur de charge d'application se déploient uniquement sur les noeuds worker spécifiés. De plus, pour empêcher d'autres charges de travail de s'exécuter sur les nœuds périphériques, vous pouvez marquer ces derniers. Vous pouvez ensuite déployer des équilibreurs de charge de réseau publics et privés sur des noeuds de périphérie. Par exemple, si vos noeuds worker sont connectés à un VLAN privé uniquement et que vous devez autoriser l'accès public à une application de votre cluster, vous pouvez créer un pool de noeuds worker de périphérie dans lequel les noeuds de périphérie sont connectés à des VLAN publics et privés. Vous pouvez déployer des équilibreurs de charge de réseau et des équilibreurs de charge d'application publics sur ces noeuds de périphérie afin de garantir que seuls ces noeuds worker peuvent gérer les connexions publiques.

Communication de nœud worker à nœuds worker dans des clusters classiques avec des charges de travail sur Internet

Pour réaliser cette configuration, vous créez un cluster en connectant des noeuds worker à des VLAN publics et privés.

Si vous créez le cluster avec des réseaux locaux virtuels publics et privés, vous ne pouvez pas supprimer tous les réseaux locaux virtuels publics de ce cluster. Le retrait de tous les VLAN publics d'un cluster peut provoquer l'arrêt de plusieurs composants du cluster. A la place, créez un nouveau pool de noeuds worker qui est connecté à un VLAN privé uniquement.

Communication de type " nœud worker à maître " et " utilisateur à maître " dans les clusters classiques avec des charges de travail sur Internet

Vous pouvez choisir d'autoriser la communication entre les noeuds worker et le maître et entre les utilisateurs et le maître sur les réseaux public et privé ou sur le réseau public uniquement.

• Noeuds finaux de service cloud publics et privés : votre compte doit être activé avec la fonction VRF et activé pour utiliser des noeuds finaux de service. La communication entre les noeuds worker et le maître est établie sur le réseau privé via le noeud final de service cloud privé et sur le réseau public via le noeud final de service cloud public. Le maître est accessible au public pour les utilisateurs de cluster autorisés via le noeud final de service cloud public.
• Nœud final de service public : Si vous ne souhaitez pas ou ne pouvez pas activer VRF pour votre compte, vos nœuds worker et les utilisateurs de cluster autorisés peuvent automatiquement se connecter au maître Kubernetes sur le réseau public via le nœud final de service de cloud public.

Communication des nœuds worker vers d'autres services ou réseaux avec des charges de travail sur Internet

Vos noeuds worker peuvent communiquer automatiquement et en toute sécurité avec d'autres services IBM Cloud qui prennent en charge des noeuds finaux de service de cloud privé sur votre réseau privé d'infrastructure IBM Cloud. Si un service IBM Cloud ne prend pas en charge des noeuds finaux de service de cloud privé, les noeuds worker peuvent communiquer en toute sécurité avec les services sur le réseau public. Vous pouvez verrouiller les interfaces publiques ou privées de noeuds worker en utilisant les règles réseau Calico pour l'isolement de réseau privé ou de réseau public. Vous devrez peut-être autoriser l'accès aux adresses IP publiques et privées des services que vous souhaitez utiliser dans ces règles d'isolement Calico.

Si vos nœuds de travail doivent accéder à des services sur des réseaux privés en dehors de votre compte IBM Cloud, voir Configuration de la connectivité au réseau privé

Communication externe aux applications qui s'exécutent sur des nœuds worker avec des charges de travail sur Internet

Pour exposer une application dans votre cluster sur Internet, vous pouvez créer un équilibreur de charge de réseau (NLB) public ou un équilibreur de charge d'application (ALB) Ingress. Vous pouvez améliorer la sécurité de votre cluster en créant un pool de noeuds worker qui sont labellisés noeuds de périphérie. Les pods des services de réseau public sont déployés sur des noeuds de périphérie de sorte que les charges de travail de trafic externe soient isolées pour un petit nombre de noeuds worker dans votre cluster. Vous pouvez contrôler davantage le trafic public vers les services de réseau qui exposent vos applications en créant des règles pré-DNAT Calico, telles que des règles d'inscription sur liste autorisée et des règles d'inscription sur liste rouge.

Prêt à utiliser un cluster pour ce scénario ? Après avoir planifié votre installation à haute disponibilité, voir Création de clusters.

Communication de noeud worker à noeud worker, communication entre les noeuds worker et les utilisateurs avec un dispositif de passerelle

Si vous configurez vos nœuds worker sur un VLAN privé uniquement et que vous ne souhaitez pas ou ne pouvez pas activer VRF pour votre compte, vous devez configurer un dispositif de passerelle pour fournir une connectivité réseau entre vos nœuds worker et le maître sur le réseau public. Par exemple, vous pouvez choisir de configurer un Virtual Router Appliance.

Vous pouvez configurer votre dispositif de passerelle avec des règles réseau personnalisées afin d'assurer une sécurité réseau dédiée pour votre cluster et détecter et parer à des intrusions réseau. Lorsque vous configurez un pare-feu sur le réseau public, vous devez ouvrir les ports et les adresses IP privées requis pour chaque région de manière à permettre au maître et aux noeuds worker de communiquer. Si vous configurez également ce pare-feu sur le réseau privé, vous devez également ouvrir les ports et les adresses IP privées requis de manière à permettre la communication entre les noeuds worker et permettre à votre cluster d'accéder aux ressources d'infrastructure sur le réseau privé. Vous devez également activer la fonction Spanning VLAN pour votre compte de sorte que les sous-réseaux puissent effectuer le routage sur le même VLAN et sur les VLAN.

Communication de noeuds worker vers d'autres services ou réseaux avec un dispositif de passerelle

Pour connecter en toute sécurité vos nœuds de travail et vos applications à un réseau sur site ou à des services extérieurs à IBM Cloud, consultez la section relative à la configuration de la connectivité du réseau privé

Vos noeuds worker peuvent communiquer en toute sécurité avec d'autres services IBM Cloud et services publics en dehors d'IBM Cloud via votre dispositif de passerelle. Vous pouvez configurer votre pare-feu pour autoriser l'accès aux adresses IP publiques et privées des seuls services que vous souhaitez utiliser.

Communication externe aux applications qui s'exécutent sur des noeuds worker avec un dispositif de passerelle

Pour fournir un accès privé à une application de votre cluster, vous pouvez créer un équilibreur de charge de réseau (NLB) privé ou un équilibreur de charge d'application (ALB) Ingress afin d'exposer votre application sur le réseau privé uniquement. Si vous devez fournir un accès public limité à une application de votre cluster, vous pouvez créer un équilibreur de charge de réseau ou équilibreur de charge d'application public afin d'exposer votre application. Etant donné que l'ensemble du trafic passe par votre pare-feu de dispositif de passerelle, vous pouvez contrôler le trafic public et le trafic privé vers les services de réseau qui exposent vos applications en ouvrant les ports et les adresses IP des services dans votre pare-feu pour permettre le trafic entrant vers ces services.

Prêt à utiliser un cluster pour ce scénario ? Après avoir planifié votre installation à haute disponibilité, voir Création de clusters.

Communication entre les noeuds worker pour les clusters privés

Pour réaliser cette configuration, vous créez un cluster en connectant des noeuds worker à un VLAN privé uniquement. Pour fournir la connectivité entre le maître cluster et les noeuds worker sur le réseau privé via le noeud final de service cloud privé uniquement, votre compte doit être activé avec la fonction VRF et activé pour l'utilisation de noeuds finaux de service. Etant donné que votre cluster est visible pour n'importe quelle ressource sur le réseau privé lorsque la fonction VRF est activée, vous pouvez isoler votre cluster des autres systèmes sur le réseau privé en appliquant des règles réseau privé Calico.

Notez que des conflits de sous-réseaux peuvent survenir entre les plages par défaut pour les noeuds worker, les pods et les services, ainsi que les sous-réseaux dans vos réseaux sur site. Vous créez votre cluster sans utiliser les sous-réseaux fournis par IBM, en incluant l'option --no-subnet. Une fois le cluster créé, vous pouvez ajouter des sous-réseaux personnalisés à votre cluster. De plus, vous pouvez spécifier un CIDR de sous-réseau personnalisé pour les pods et les services à l'aide des options --service-subnet --pod-subnet et de la commande ibmcloud ks cluster create lors de la création de votre cluster.

Communication entre les noeuds worker et le maître et entre les utilisateurs et le maître pour les clusters privés

Le maître Kubernetes est accessible via le noeud final de service cloud privé si les utilisateurs de cluster autorisés se trouvent dans votre réseau privé IBM Cloud ou sont connectés au réseau privé, par exemple, via une connexion VPN classique ou IBM Cloud Direct Link. Toutefois, la communication avec le maître Kubernetes via le noeud final de service cloud privé doit passer par la plage d'adresses IP 166.X.X.X, qui n'est pas routable à partir d'une connexion VPN classique, ou par IBM Cloud Direct Link. Vous pouvez exposer le noeud final de service cloud privé du maître pour vos utilisateurs de cluster en utilisant un équilibreur de charge de réseau (NLB) privé. L'équilibreur de charge de réseau privé expose le noeud final de service cloud privé du maître en tant que plage d'adresses IP 10.X.X.X interne auxquelles les utilisateurs peuvent accéder à l'aide de la connexion VPN ou IBM Cloud Direct Link. Si vous activez uniquement le noeud final de service cloud privé, vous pouvez utiliser le tableau de bord Kubernetes ou activer temporairement le noeud final de service cloud public pour créer l'équilibreur de charge de réseau privé.

Communication entre les noeuds worker et d'autres services ou réseaux pour les clusters privés

Vos noeuds worker peuvent communiquer automatiquement et en toute sécurité avec d'autres services IBM Cloud qui prennent en charge des noeuds finaux de service de cloud privé, par exemple, IBM Cloud® Container Registry, sur votre réseau privé d'infrastructure IBM Cloud. Par exemple, des environnements de matériel dédié pour toutes les instances de plan standard de IBM Cloudant prennent en charge des noeuds finaux de service de cloud privé. Si un service IBM Cloud ne prend pas en charge les nœuds finaux de service de cloud privé, votre cluster ne peut pas accéder à ce service.

Communication externe vers les applications s'exécutant sur les nœuds de travail des clusters privés

Pour fournir un accès privé à une application de votre cluster, vous pouvez créer un équilibreur de charge de réseau (NLB) privé ou un équilibreur de charge d'application (ALB) Ingress. Ces services de réseau Kubernetes exposent votre application sur le réseau privé uniquement de sorte que n'importe quel système sur site ayant une connexion au sous-réseau sur lequel se trouve l'adresse IP NLB puisse accéder à l'application.

Prêt à utiliser un cluster pour ce scénario ? Après avoir planifié votre installation à haute disponibilité, voir Création de clusters.