Pourquoi manque-t-il le sous-domaine public containers.appdomain.cloud dans mon cluster ?

Virtual Private Cloud Infrastructure classique

Lorsque vous exposez une application via un sous-domaine de contrôleur Ingress, vous obtenez un sous-domaine local au lieu d'une route publique, au format : <service_name>-<project_name>.router.default.svc.cluster.local.

Lorsque vous tentez d'ouvrir la console Web Red Hat OpenShift ou une autre route d'application dans votre navigateur, un message d'erreur semblable à celui présenté ci-après peut s'afficher.

Application is not available
The application is currently not serving requests on this endpoint.

Une fois que le cluster est créé et qu'il entre un état Normal, le déploiement des composants de l'équilibrage de charge et du sous-domaine du contrôleur Ingress prend encore un certain temps.

Si vous exposez votre application avant la mise à disposition complète des composants réseau, ou si les composants subissent une erreur, vos applications ne peuvent être exposées qu'en interne avec le domaine svc.cluster.local du contrôleur Ingress par défaut.

Lorsque les composants sont entièrement provisionnés, un sous-domaine public du contrôleur Ingress est disponible pour vos applications, au format<cluster-name>-<accountID-hashed>-<ssll>.<region>.containers.appdomain.cloud.

1. Lorsque vous avez créé un cluster, patientez quelques instants avant d'exposer vos applications, même une fois que le cluster est passé à l'état normal.

2. Vérifiez la zone Etat du maître (Master Status). Si l'état du maître n'est pas Prêt (Ready), vérifiez son état et suivez les informations de traitement des incidents pour résoudre le problème.

   ibmcloud oc cluster get -c <cluster_name_or_ID>
   

3. Vérifiez que votre cluster dispose d'une connectivité publique pour que les composants de mise en réseau puissent communiquer avec le maître lors de leur déploiement.

   • Clusters VPC avec points d'extrémité de services de clouds publics et privés activés : Assurez-vous qu'une passerelle publique est activée sur chaque sous-réseau auquel votre cluster est rattaché. Une passerelle publique est requise pour les composants par défaut, tels que la console Web et OperatorHub, pour utiliser une connexion publique et sécurisée et effectuer des actions, telles que l'extraction d'images de registres privés distants. Notez que si seul le noeud final de service privé est activé pour votre cluster, aucune passerelle publique n'est requise car le noeud final de service de cloud privé est utilisé par défaut pour accéder aux composants OpenShift, tels que la console Web OpenShift ou OperatorHub.
   • Clusters classiques :
     • Dans la sortie de l'étape 2, vérifiez que votre cluster dispose d'une URL de noeud final de service public. Si votre cluster ne dispose pas d'un point d'extrémité de service de cloud public, activez-le.
     • Vérifiez qu'au moins certains nœuds worker de votre cluster ont une adresse IP publique. Si aucun nœud de travailleur ne le fait, vous devez configurer des VLAN publics pour au moins un pool de travailleurs.

       ibmcloud oc workers -c <cluster_name_or_ID>
       

4. Dans la sortie de l'étape 2, vérifiez que le sous-domaine Ingress est disponible. Les composants Ingress de votre cluster doivent être mis à disposition avant que les composants du contrôleur Ingress puissent être créés. Si le sous-domaine Ingress et le secret Ingress ne sont pas disponibles, voir Pourquoi n'existe-t-il aucun sous-domaine Ingress après la création du cluster ?

5. Vérifiez que le Nom d'hôte du sous-domaine du contrôleur d'entrée est au format suivant : <cluster-name>-<accountID-hashed>-<ssll>.<region>.containers.appdomain.cloud.

   ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
   

   • Si le sous-domaine du contrôleur d'entrée n'est pas mis à jour après deux heures de création du cluster, consultez à nouveau le État maître du cluster et suivez les étapes de résolution des incidents pour résoudre le problème.

Si la procédure de résolution des incidents ne résout pas le problème, voir Obtention de l'aide.