Communication d'agent à agent à l'aide de sous-réseaux VPC

Avant de créer un cluster VPC pour la première fois, vous devez créer un sous-réseau VPC dans chaque zone où vous souhaitez déployer des nœuds de travail. Un sous-réseau VPC correspond à une plage d'adresses IP privées spécifique (bloc CIDR) et configure un groupe de noeuds worker et de pods comme s'ils étaient reliés physiquement au même câble.

Lorsque vous créez un cluster, vous spécifiez un sous-réseau VPC existant pour chaque zone. Chaque noeud worker que vous ajoutez dans un cluster est déployé avec une adresse IP privée issue du sous-réseau VPC dans cette zone. Une fois le noeud worker mis à disposition, l'adresse IP de noeud worker est conservée après une opération reboot, mais l'adresse IP de noeud worker est modifiée après des opérations replace et update.

Les sous-réseaux fournissent un canal pour établir la connectivité entre les noeuds worker au sein du cluster. De plus, tout système connecté à l'un des sous-réseaux privés du même VPC peut communiquer avec les noeuds worker. Par exemple, tous les sous-réseaux d'un VPC peuvent communiquer via un routage de couche 3 privé avec un routeur VPC intégré. Si vous possédez plusieurs clusters qui doivent communiquer entre eux, vous pouvez créer les clusters dans le même VPC. Cependant, si vos clusters n'ont pas besoin de communiquer, vous pouvez réaliser une meilleure segmentation du réseau en créant des clusters dans des VPC distincts. Vous pouvez également créer des listes de contrôle d'accès (ACL) pour vos sous-réseaux VPC pour effectuer une médiation du trafic sur le réseau privé. Les ACL sont constituées de règles entrantes et sortantes qui définissent les entrées et les sorties autorisées pour chaque sous-réseau VPC.

Lorsque vous créez un cluster de VPC et activez les noeuds finaux de service cloud public et privé lors de la création du cluster, le noeud final de service cloud public est utilisé par défaut pour accéder aux composants tels que la console Web Red Hat OpenShift de votre cluster. Pour que les pods de la console puissent établir une connexion publique sécurisée sur Internet via le noeud final de service public, vous devez activer une passerelle publique sur chaque sous-réseau VPC sur lequel vos noeuds worker sont déployés.

Lorsque vous créez un cluster de VPC et n'activez que le noeud final de service cloud privé lors de la création du cluster, le noeud final de service cloud privé est utilisé par défaut pour accéder aux composants Red Hat OpenShift tels que la console Web Red Hat OpenShift ou OperatorHub. Vous devez être connecté au réseau VPC privé (par exemple, via une connexion VPN) pour accéder à ces composants ou exécuter des commandes kubectl sur votre cluster.

La plage d'adresses IP par défaut des sous-réseaux VPC est 10.0.0.0 - 10.255.255.255. Pour obtenir une liste de plages d'adresses IP par zone VPC, reportez-vous à la rubrique présentant les préfixes d'adresse par défaut du VPC.

Si vous activez l'accès classique lorsque vous créez votre VPC, des préfixes d'adresse par défaut d'accès classique déterminent automatiquement les plages d'adresses IP de tous les sous-réseaux que vous créez. Cependant, les plages d'adresses IP par défaut des sous-réseaux VPC d'accès classique entrent en conflit avec les sous-réseaux du plan de contrôle Red Hat OpenShift on IBM Cloud. Vous devez plutôt créer le VPC sans les préfixes d'adresse par défaut automatiques, puis créer vos propres préfixes d'adresse et sous-réseaux au sein de ces plages pour votre cluster.

Besoin de créer votre cluster à l'aide des sous-réseaux d'une plage personnalisée ? Suivez le tutoriel sur les préfixes d'adresse personnalisés. Si vous utilisez des sous-réseaux personnalisés pour vos nœuds worker, vous devez vérifier que les sous-réseaux de vos nœuds worker ne se chevauchent pas avec le sous-réseau pod de votre cluster.

Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.

Lorsque vous créez des sous-réseaux VPC pour vos clusters, gardez à l'esprit les fonctions et limitations décrites ci-après. Pour plus d'informations sur les sous-réseaux VPC, voir Caractéristiques des sous-réseaux dans le cloud privé virtuel.

• La taille de routage CIDR par défaut de chaque sous-réseau VPC est /24, qui peut prendre en charge jusqu'à 253 noeuds worker. Si vous prévoyez de déployer plus de 250 noeuds worker par zone dans un cluster, pensez à créer un sous-réseau plus grand.
• Une fois que vous avez créé un sous-réseau VPC, vous ne pouvez pas le redimensionner ou modifier sa plage d'adresses IP.
• Plusieurs clusters compris dans le même VPC peuvent partager des sous-réseaux.
• Les sous-réseaux VPC sont associés à une seule zone ou région et ne peuvent pas s'étendre sur plusieurs zones ou régions.
• Après avoir créé un sous-réseau, vous ne pouvez pas le déplacer vers une autre zone, région ou VPC.
• Si des nœuds worker sont connectés à un sous-réseau existant dans une zone, vous ne pouvez pas modifier le sous-réseau de cette zone dans le cluster.
• Les plages 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 et 172.20.0.0/16 sont interdites.

Communication d'agent à maître et d'utilisateur à maître à l'aide de nœuds finaux privés virtuels ou de nœuds finaux de service de cloud

Red Hat OpenShift on IBM Cloud utilise différents types de points de terminaison de service pour établir une connexion entre les utilisateurs autorisés du cluster et les nœuds de travail, d'une part, et le maître d' Kubernetes, d'autre part. Les utilisateurs de cluster autorisés communiquent avec le maître Kubernetes via des noeuds finaux de service cloud. En fonction de la version de votre cluster, les noeuds worker communiquent avec le maître Kubernetes via des noeuds finaux de service cloud ou des noeuds finaux privés virtuels VPC.

Avant de créer un cluster, vous devez activer votre compte pour utiliser les noeuds finaux de service. Pour activer les noeuds finaux de service, exécutez ibmcloud account update --service-endpoint-enable true.

Dans les clusters de cloud privé virtuel dans Red Hat OpenShift on IBM Cloud, vous ne pouvez pas désactiver le nœud final de service de cloud privé ou configurer un cluster avec le nœud final de service de cloud public uniquement.

Par défaut, votre cluster de VPC est créé avec un noeud final de service cloud public et un noeud final de service cloud privé. Pour créer des clusters avec des noeuds worker connectés uniquement au réseau privé, vous devez activer uniquement le noeud final de service privé lors de la création du cluster. N'activez pas le noeud final de service public. Par exemple, pour créer un cluster VPC comportant uniquement un point de terminaison de service cloud privé via l'interface de ligne de commande(CLI), utilisez l'option « --disable-public-service-endpoint ». Si vous activez cette option, votre cluster sera créé avec des routeurs et des contrôleurs Ingress qui, par défaut, n'exposent vos applications que sur le réseau privé. Si vous souhaitez ultérieurement exposer des applications sur un réseau public, vous devez créer manuellement des routeurs publics et des contrôleurs Ingress.

Communication d'agent à maître dans les clusters de cloud privé virtuel

La communication entre les nœuds de travail et le maître d' Kubernetes s s'effectue par défaut via le point de terminaison privé virtuel(VPE)du VPC. La passerelle VPE de votre cluster utilise l'un de ces deux formats de nom d'hôte selon la région : CLUSTERID.vpe.private.REGION.containers.cloud.ibm.com ou CLUSTERID.private.REGION.containers.cloud.ibm.com. Tout le trafic entre les nœuds de travail et le nœud maître transite par cette passerelle VPE privée.

Si la connexion à la passerelle VPE échoue et que la protection du trafic sortant est désactivée sur votre cluster, les nœuds de travail se rabattent sur le point de terminaison du service cloud public. Ce basculement ne se produit que lorsque la passerelle VPE est inaccessible, et non en conditions normales de fonctionnement. Si la protection du trafic sortant est activée, il n'y a pas de basculement vers le point de terminaison public.

Afin de sécuriser les communications via les points de terminaison des services cloud publics et privés ou les VPE, l' Red Hat OpenShift on IBM Cloud configure automatiquement une connexion Konnectivity entre les nœuds maîtres et les nœuds de travail d' Kubernetes lors de la création du cluster. Les nœuds de travail communiquent en toute sécurité avec le maître via des certificats « TLS », et le maître communique avec les nœuds de travail via la connexion Konnectivity.

Communication utilisateur à maître dans les clusters de cloud privé virtuel

Vous pouvez permettre aux utilisateurs de cloud autorisés de communiquer avec le maître Kubernetes en activant les noeuds finaux de service cloud publics et privés ou le noeud final de service cloud privé uniquement.

• Noeuds finaux de service cloud publics et privés : par défaut, tous les appels vers le maître qui sont initiés par les utilisateurs de cluster autorisés sont routés via le noeud final de service cloud public. Si les utilisateurs de cluster autorisés figurent dans votre réseau VPC ou sont connectés via une connexion VPN VPC, le maître est accessible de façon privée via le noeud final de service cloud privé.
• Noeud final de service cloud privé uniquement : pour accéder au maître via le noeud final de service cloud privé, les utilisateurs de cluster autorisés doivent figurer dans votre réseau VPC ou être connectés via une connexion VPN VPC.

Vous pouvez sécuriser l'accès réseau aux points d'extrémité des services de votre cluster en utilisant des restrictions basées sur le contexte. Seules les requêtes autorisées adressées au maître de votre cluster et provenant de sous-réseaux figurant dans la liste blanche sont autorisées à transiter par les points de terminaison de service du cluster. L'utilisation de restrictions basées sur le contexte permet d'empêcher les activités d'analyse non autorisées. Pour plus d'informations, voir Utilisation des restrictions basées sur le contexte.

Communication entre les noeuds worker et d'autres services ou réseaux

Autorisez vos noeuds worker à communiquer de façon sécurisée avec d'autres services IBM Cloud, des réseaux sur site, d'autres VPC et des ressources d'infrastructure classique IBM Cloud.

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é. Si un service IBM Cloud ne prend pas en charge des noeuds finaux de service cloud privés, les noeuds worker peuvent communiquer en toute sécurité avec les services sur le réseau public via la passerelle publique du sous-réseau.

Notez que si vous utilisez des listes de contrôle d'accès (ACL) pour vos sous-réseaux VPC, vous devez créer des règles entrantes ou sortantes pour permettre à vos noeuds worker de communiquer avec ces services.

Communication avec des ressources dans des centres de données sur site

Pour connecter votre cluster à votre centre de données sur site, vous pouvez configurer le VPN IBM Cloud® Virtual Private Cloud ou bien IBM Cloud® Direct Link.

• Pour commencer avec le VPN Virtual Private Cloud, voir Configurez une passerelle VPN sur site et Créez une passerelle VPN dans votre VPC, et créez la connexion entre la passerelle VPN VPC et votre passerelle VPN locale. Si vous disposez d'un cluster multizone, vous devez créer une passerelle VPC sur un sous-réseau dans chaque zone comportant des noeuds worker.
• Pour commencer avec Direct Link, voir Commande de IBM Cloud Direct Link Dedicated. A l'étape 8, vous pouvez créer une connexion réseau au VPC qui doit être connecté à la passerelle Direct Link.

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 une adresse CIDR de sous-réseau personnalisée pour les pods dans l'option « --pod-subnet » et une adresse CIDR de sous-réseau personnalisée 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.
• Notez 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 aux fonctions du plan de contrôle Red Hat OpenShift on IBM Cloud.

Communication externe avec des applications qui s'exécutent sur des noeuds worker

Autorisez les demandes de trafic privé ou public depuis l'extérieur du cluster vers vos applications qui s'exécutent sur des noeuds worker.

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 réseau privé depuis l'extérieur du cluster vers vos applications, vous pouvez utiliser des services de mise en réseau Kubernetes privés, tels que la création de services LoadBalancer. Par exemple, lorsque vous créez un service Kubernetes LoadBalancer dans votre cluster, un équilibreur de charge pour 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. Pour les VPC ALB et NLB, un groupe de sécurité, nommé sous la forme kube-lbaas-<cluster-id>, est automatiquement attaché à vos équilibreurs de charge.

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 à partir de l'internet public, vous pouvez créer des services de mise en réseau publics. Même si vos noeuds worker sont connectés uniquement à des sous-réseaux VPC privés, l'équilibreur de charge VPC qui est créé pour les services de mise en réseau public peut router les demandes publiques vers votre application sur le réseau privé 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.

Vous pouvez utiliser des services de mise en réseau Kubernetes publics, tels que la création de services LoadBalancer. Par exemple, lorsque vous créez un service Kubernetes LoadBalancer dans votre cluster, un équilibreur de charge pour 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. Pour les VPC ALB et NLB, un groupe de sécurité, nommé sous la forme kube-lbaas-<cluster-id>, est automatiquement attaché à vos équilibreurs de charge.

Exemples de scénario pour les configurations de réseau de cluster de VPC

Maintenant que vous comprenez les bases de la mise en réseau de cluster, consultez quelques exemples de scénarios dans lesquels différentes configurations de réseau de cluster VPC peuvent répondre à vos besoins en matière de charge de travail.

Scénario : Exécution de charges de travail d'application accessibles sur Internet dans un cluster de VPC

Dans ce scénario, vous exécutez des charges de travail dans un cluster VPC qui sont accessibles aux demandes émises depuis Internet. L'accès public est contrôlé par des groupes de sécurité de sorte que les utilisateurs finaux peuvent accéder à vos applications tandis que les demandes publiques non désirées vers vos applications sont refusées. En outre, vos noeuds worker accèdent automatiquement aux services IBM Cloud qui prennent en charge des noeuds finaux de service de cloud privé.

Extension de votre centre de données sur site à un cluster VPC

Dans ce scénario, vous exécutez des charges de travail dans un cluster VPC. Toutefois, vous souhaitez que ces charges de travail soient accessibles uniquement aux services, bases de données ou autres ressources dans vos réseaux privés, dans un centre de données sur site. Vos charges de travail de cluster auront peut-être besoin d'accéder à un petit nombre d'autres services IBM Cloud qui prennent en charge la communication sur le réseau privé.

Etapes suivantes

Pour poursuivre le processus de planification, apprenez à protéger les informations sensibles dans votre cluster en prenant des décisions sur le niveau de chiffrement que vous devez configurer. Si vous êtes prêt à commencer la mise en réseau, passez à Comprendre la mise en réseau Secure by Default Cluster VPC.