Après la création d'un cluster de version 4.15, les applications qui s'exécutent dans d'autres clusters de mon VPC échouent

{: tag-vpc}[Virtual Private Cloud] 4.15 et versions ultérieures

Dépannage des problèmes liés aux clusters non satellites lors de l'utilisation du stockage Satellite.

Vous utilisez uniquement des groupes de sécurité personnalisés et vous constatez des échecs de création de travailleurs et des erreurs d'extraction d'images dans d'autres clusters au sein de votre VPC après avoir créé un cluster de la version 4.15.

Les étapes suivantes s'appliquent uniquement dans les scénarios où vous avez choisi de ne pas utiliser les groupes de sécurité gérés et que vous utilisez à la place vos propres groupes de sécurité personnalisés.

Avec l'introduction de Secure by Default Cluster VPC Networking dans la version 4.15, de nouvelles passerelles VPE et des groupes de sécurité gérés sont utilisés pour gérer le trafic réseau.

Ces nouvelles ressources et règles pourraient entraîner des erreurs de réseau au sein des clusters existants de votre VPC, selon la manière dont vous avez créé vos clusters précédents.

Avant de créer un cluster de version 4.15, vous avez créé un cluster qui n'utilise pas le groupe de sécurité de cluster géré.

Par exemple, vous avez précédemment créé des clusters à l'aide de la commande cluster create vpc-gen2 avec l'option --cluster-security-group et n'avez pas inclus l'option cluster.

La première fois que vous créez un cluster Secure by Default, les ressources suivantes sont créées.

• Un groupe de sécurité de passerelle VPE partagé sera créé (kube-vpegw-<vpcID>). Toutes les passerelles VPE partagées nouvelles et existantes sont mises à jour pour pouvoir être utilisées.

• Tous les groupes de sécurité gérés existants précédemment, tels que kube-<clusterID> dans le même VPC, sont mis à jour avec de nouvelles règles pour autoriser le trafic via le nouveau groupe de sécurité de passerelle VPE partagé.

• Tout futur cluster non sécurisé par défaut dans le même VPC autorisera le trafic via le nouveau groupe de sécurité de passerelle VPE partagé via le groupe de sécurité de cluster géré par IKS (kube-<clusterID>).

Tout cluster existant ou futur non sécurisé par défaut qui n'utilise PAS le groupe de sécurité de cluster géré ne pourra pas accéder aux services via les passerelles VPE. Par exemple, le registre, Red Hat OpenShift on IBM Cloud API, etc.

Pour corriger ce problème, ajoutez une règle de groupe de sécurité entrante sur le groupe de sécurité de la passerelle VPE partagée à partir de l'un de vos groupes de sécurité définis par le client.

1. Recherchez les ID de groupe de sécurité pour votre groupe de sécurité et le groupe de sécurité kube-vpegw-<vpcID>.

   ibmcloud is security-groups
   

2. Ajoutez une règle distante à kube-vpegw-<vpcID> à partir de votre groupe de sécurité personnalisé.

   ibmcloud is sg-rulec KUBE-VPEGW-VPCID inbound icmp_tcp_udp --remote YOUR_SG_ID
   

3. Ajoutez une règle distante de votre groupe de sécurité personnalisé à kube-vpegw-<vpcID>.

   ibmcloud is sg-rulec  <your SG> outbound icmp_tcp_udp --remote  <ID of kube-vpegw-vpcID>