Impossible de créer ou de supprimer des clusters ou des noeuds worker en raison d'erreurs d'autorisation et de données d'identification

Vous ne pouvez pas gérer les nœuds de travail pour votre cluster et vous recevez un message d'erreur qui mentionne permissions, credentials, SoftLayer, API keys, ou role.

Consultez les informations sur les erreurs d'admission et de références et suivez les étapes correspondantes.

Impossible de créer ou de supprimer des noeuds worker en raison d'une erreur de compte incorrect

Infrastructure classique

Vous ne pouvez pas gérer les nœuds de travail de votre cluster ni afficher les nœuds de travail du cluster dans votre compte d'infrastructure classique IBM Cloud. Toutefois, vous pouvez mettre à jour et gérer d'autres clusters du compte.

De plus, vous avez vérifié que vous disposiez des données d'identification d'infrastructure appropriées.

Il se peut que vous receviez un message d'erreur dans l'état de votre nœud de travail, similaire à l'exemple suivant.

incorrect account for worker - The 'classic' infrastructure user credentials changed and no longer match the worker node instance infrastructure account.

Il est possible que le cluster soit mis à disposition dans un compte d'infrastructure IBM Cloud classique qui n'est plus lié à votre compte Red Hat OpenShift on IBM Cloud. Le cluster est orphelin. Étant donné que les ressources se trouvent dans un autre compte, vous ne disposez pas des données d'identification de l'infrastructure pour modifier les ressources.

Envisagez l'exemple de scénario suivant pour savoir comment les clusters peuvent devenir orphelins.

1. Vous disposez d'un compte IBM Cloud Paiement à la carte.
2. Vous créez un cluster nommé Cluster1. Les noeuds worker et d'autres ressources d'infrastructure sont mises à disposition dans le compte d'infrastructure fourni avec votre compte Paiement à la carte.
3. Par la suite, vous constatez que votre équipe utilise un compte d'infrastructure IBM Cloud classique existant ou partagé. Vous utilisez la commande ibmcloud oc credential set pour modifier les données d'identification du compte d'infrastructure IBM Cloud afin d'utiliser le compte de votre équipe.
4. Vous créez un autre cluster nommé Cluster2. Les noeuds worker et d'autres ressources d'infrastructure sont mises à disposition dans le compte d'infrastructure de l'équipe.
5. Vous remarquez que le cluster Cluster1 nécessite une mise à jour ou un rechargement de noeud worker ou vous voulez juste le nettoyer en le supprimant. Toutefois, comme Cluster1 a été mis à disposition dans un autre compte d'infrastructure, vous ne pouvez pas modifier ses ressources d'infrastructure. Cluster1 est orphelin.
6. Vous suivez les étapes de résolution de la section suivante, mais ne définissez pas vos données d'identification d'infrastructure sur votre compte d'équipe. Vous pouvez supprimer Cluster1, mais Cluster2 est orphelin.
7. Vous restaurez vos données d'identification du compte d'infrastructure dans le compte de l'équipe qui a créé Cluster2. Désormais vous n'avez plus de cluster orphelin.

Suivez les étapes pour passer en revue vos données d'identification d'infrastructure et déterminer la raison pour laquelle vous voyez une erreur de données d'identification.

1. Connectez-vous à la console.

2. Accédez à votre cluster Red Hat OpenShift...

3. Vérifiez quel est le compte d'infrastructure que la région dans laquelle se trouve votre cluster utilise pour mettre à disposition des clusters. Remplacez REGION par la région IBM Cloud dans laquelle se trouve le cluster.

   ibmcloud oc credential get --region REGION
   

   Si un message similaire au suivant s'affiche, cela signifie que le compte utilise le compte d'infrastructure lié par défaut.

   No credentials set for resource group <resource group>.: The user credentials could not be found.
   

4. Vérifiez quel est le compte d'infrastructure qui a été utilisé pour mettre à disposition le cluster.

   1. Dans l'onglet Noeuds worker, sélectionnez un noeud worker et notez son ID.
   2. Ouvrez le menu () et cliquez sur Infrastructure > Infrastructure classique.
   3. Dans le volet de navigation de l'infrastructure, cliquez sur Périphériques > Liste des périphériques.
   4. Recherchez l'ID du noeud worker que vous avez noté précédemment.
   5. Si vous ne trouvez pas l'ID de nœud worker, celui-ci n'est pas mis à disposition dans ce compte d'infrastructure. Passez à un autre compte d'infrastructure et réessayez.

5. Comparez les comptes d'infrastructure.

   • Si les nœuds de travail se trouvent dans le compte d’infrastructure associé: utilisez la commandeibmcloud oc credential unset pour reprendre l’utilisation des identifiants d’infrastructure par défaut associés à votre compte Pay-As-You-Go.

   • Si les nœuds de travail se trouvent dans un autre compte d’infrastructure: utilisez la commandeibmcloud oc credential set pour modifier vos identifiants d’infrastructure et les remplacer par ceux du compte dans lequel les nœuds de travail du cluster sont provisionnés, que vous avez identifié à l’étape précédente.

     Si vous n'avez plus accès aux données d'identification de l'infrastructure, vous pouvez ouvrir un cas de support IBM Cloud pour déterminer l'adresse e-mail de l'administrateur de l'autre compte d'infrastructure. Toutefois, le support IBM Cloud ne peut pas supprimer le cluster orphelin pour vous, et vous devez contacter l'administrateur de l'autre compte pour obtenir les données d'identification de l'infrastructure.

   • Si les comptes d'infrastructure correspondent: vérifiez les autres nœuds de travail du cluster et voyez si certains sont affectés à un compte d'infrastructure différent. Assurez-vous d'avoir vérifié les nœuds de travail du cluster qui présentent un problème d'identifiants. Consultez les autres problèmes courants liés aux données d'identification d'infrastructure.

6. Maintenant que les données d'identification d'infrastructure sont mises à jour, tentez à nouveau d'exécuter l'action bloquée, par exemple, la mise à jour ou la suppression d'un noeud worker, et vérifiez qu'elle aboutit.

7. Si d'autres clusters résidant dans la même région et la même ressource nécessitent les données d'identification d'infrastructure précédentes, répétez l'étape 3 pour réinitialiser les données d'identification d'infrastructure avec celles du compte précédent. Notez que si vous avez créé des clusters avec un autre compte d'infrastructure que le compte où vous avez basculé, vous pouvez rendre ces clusters orphelins.

   Vous en avez assez de devoir passer d'un compte d'infrastructure à une autre chaque fois que vous devez effectuer une action sur un cluster ou un noeud worker ? Songez à recréer tous les clusters résidant dans la région et le groupe de ressources dans le même compte d'infrastructure. Ensuite, faites migrer vos charges de travail et retirez les anciens clusters du compte d'infrastructure différent.

Impossible de créer ou de supprimer des noeuds worker en raison d'une erreur sur les noeuds finaux

Vous ne pouvez pas gérer les nœuds worker pour votre cluster, et vous recevez un message d'erreur similaire à l'un des suivants.

Worker deploy failed due to network communications failing to master or registry endpoints. Please verify your network setup is allowing traffic from this subnet then attempt a worker replace on this worker

Pending endpoint gateway creation

Les nœuds de travail peuvent communiquer avec le maître Kubernetes par l'intermédiaire du point de terminaison privé virtuel (VPE) de la grappe.

Une ressource de passerelle VPE est créée par cluster dans votre VPC. Si la passerelle VPE de votre cluster n'est pas correctement créée dans votre VPC, elle est supprimée de votre VPC, ou si l'adresse IP qui est réservée pour le VPE est supprimée du sous-réseau de votre VPC, les noeuds worker perdent la connectivité avec le maître Kubernetes.

Etablissez de nouveau la connexion VPE entre vos noeuds worker et le maître Kubernetes.

1. Pour vérifier la passerelle VPE de votre cluster dans la console d’infrastructure VPC, ouvrez le tableau de bord Passerelles de point de terminaison privé virtuel pour VPC et recherchez la passerelle VPE au format iks-<cluster_ID>.

   • Si la passerelle de votre cluster n'est pas répertoriée, passez à l'étape suivante.
   • Si la passerelle de votre cluster est répertoriée, mais que son statut n'est pas Stable, ouvrez un cas de support. Dans les détails du cas, incluez l'ID cluster.
   • Si la passerelle de votre cluster est répertoriée et que son statut est Stable, il se peut qu'un pare-feu ou des règles de groupe de sécurité bloquent les communications entre les noeuds worker et le maître cluster. Configurez vos règles de groupe de sécurité de sorte à autoriser le trafic sortant vers les ports et les adresses IP appropriés.

2. Actualisez le maître cluster. Si la passerelle VPE n'existe pas dans votre VPC, elle est créée, et la connectivité vers les adresses IP réservées sur les sous-réseaux auxquels vos nœuds de travail sont connectés est rétablie. Après avoir actualisé le cluster, patientez quelques minutes pour permettre à l'opération de s'achever.

   ibmcloud oc cluster master refresh -c <cluster_name_or_ID>
   

3. Vérifiez que la passerelle VPE de votre cluster a bien été créée en ouvrant le tableau de bord Passerelles de points de terminaison privés virtuels pour VPC et en recherchant la passerelle VPE au format iks-<cluster_ID>.

4. Si vous ne pouvez toujours pas gérer les nœuds worker une fois le cluster maître régénéré, remplacez les noeuds worker auxquels vous ne pouvez pas accéder.

   1. Répertoriez tous les noeuds worker de votre cluster et notez le nom de celui que vous souhaitez remplacer.

       oc get nodes
       ```
       Le **nom** renvoyé dans cette commande correspond à l'adresse IP privée affectée à votre noeud worker. Vous pouvez trouver plus d'informations sur votre noeud worker lorsque vous exécutez la commande `ibmcloud oc worker ls --cluster <cluster_name_or_ID>` et recherchez le poste de travail avec la même adresse **IP privée**.
   
   2. Remplacez le noeud worker. Dans le cadre du processus de remplacement, les pods qui s'exécutent sur le noeud worker sont arrêtés et replanifiés sur les noeuds worker restants dans le cluster. Le noeud worker est également bloqué ou marqué comme non disponible pour une planification de pod ultérieure. Utilisez l'ID de noeud worker renvoyé par la commande `ibmcloud oc worker ls --cluster <cluster_name_or_ID>`.
   ```sh {: pre}
       ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
       ```
   3. Vérifiez que le noeud worker a été remplacé.
   ```sh {: pre}
       ibmcloud oc worker ls --cluster <cluster_name_or_ID>
       ```
   

Impossible de créer ou de supprimer des noeuds worker en raison d'une erreur de compte payant ou de mot de passe à usage unique

Infrastructure classique

Vous ne parvenez pas à gérer les nœuds de travail de votre cluster et vous recevez un message d'erreur similaire à l'un des exemples suivants.

Unable to connect to the IBM Cloud account. Ensure that you have a paid account.

can't authenticate the infrastructure user: Time-based One Time Password authentication is required to log in with this user.

Votre compte IBM Cloud utilise sa propre infrastructure liée automatiquement via un compte de type Paiement à la carte.

Cependant, l'administrateur de compte a activé l'option de code d'accès à usage unique de sorte que les utilisateurs soient invités à saisir un code d'accès à usage unique lors de la connexion. Ce type d'authentification multi-facteur est basé sur les comptes et affecte tous les accès au compte. L'authentification multi-facteur avec un code d'accès à usage unique affecte également l'accès requis par IBM Cloud Kubernetes Service pour passer des appels vers l'infrastructure IBM Cloud. Si TOTP est activé pour le compte, vous ne pouvez pas créer et gérer des clusters et des noeuds worker dans IBM Cloud Kubernetes Service.

Le propriétaire du compte IBM Cloud ou un administrateur du compte doit prendre l'une des mesures suivantes.

• Désactiver l'option de code d'accès à usage unique pour le compte et continuer à utiliser les données d'identification de l'infrastructure liée automatiquement pour IBM Cloud Kubernetes Service, ou
• Continuer à utiliser l'option de code d'accès à usage unique, mais créer une clé d'API d'infrastructure pouvant être utilisée par IBM Cloud Kubernetes Service pour passer des appels directs à l'API d'infrastructure IBM Cloud.