Pourquoi n'existe-t-il aucun sous-domaine Ingress après la création du cluster ?

Cloud privé virtuel Infrastructure classique

Vous créez un cluster et exécutez ibmcloud oc cluster get --cluster CLUSTER pour vérifier son état. L'état du cluster est normal, mais le sous-domaine Ingress et le secret Ingress ne sont pas disponibles.

Même si le cluster est à l'état normal, il se peut que le sous-domaine et le secret Ingress soient toujours en cours. La création du sous-domaine Ingress et du secret peut prendre plus de 15 minutes :

Clusters classiques :

Lorsque les noeuds worker sont complètement déployés et prêts sur les VLAN, un sous-réseau privé portable et un sous-réseau public portable pour les VLAN sont commandés.
Une fois les commandes de sous-réseau portable satisfaites, la mappe de configuration ibm-cloud-provider-vlan-ip-config est mise à jour avec les adresses IP des sous-réseaux public et privé portables.
Lorsque la mappe de configuration ibm-cloud-provider-vlan-ip-config est mise à jour, le contrôleur Ingress est déclenché pour la création.
Un service d'équilibrage de charge qui expose le contrôleur Ingress est créé et affecté une adresse IP.
L'adresse IP de l'équilibreur de charge est utilisée pour enregistrer le sous-domaine Ingress sur IBM NS1. IBM NS1 peut présenter un temps de latence pendant le processus d'enregistrement.

Clusters VPC :

Lorsque vous créez un cluster VPC, un équilibreur de charge VPC public et un équilibreur de charge VPC privé sont automatiquement créés en dehors de votre cluster dans votre VPC.
Un contrôleur d'entrée public par zone est déclenché pour la création.
Un service d'équilibrage de charge qui expose le contrôleur Ingress est créé et affecté un nom d'hôte.
Le nom d'hôte de l'équilibreur de charge est utilisé pour enregistrer le sous-domaine Ingress dans IBM NS1. IBM NS1 peut présenter un temps de latence pendant le processus d'enregistrement.

Création d'un cluster après la suppression d'un cluster de nom identique ou similaire ? Voir Il n'existe aucun sous-domaine Ingress après la création de clusters avec un nom identique ou similaire.

Généralement, une fois que le cluster est prêt, le sous-domaine et le secret Ingress sont créés au bout de 15 minutes. Si le sous-domaine et le secret Ingress sont toujours indisponibles alors que votre cluster est resté à l'état normal plus de 15 minutes, vous pouvez vérifier le processus de la création comme suit :

Connectez-vous à votre cluster. Étant donné que le sous-domaine n'est pas disponible, la console Red Hat OpenShift ne peut pas s'ouvrir. Vous pouvez également définir le contexte du cluster à l'aide de l'option --admin via l'interface de ligne de commande (CLI).
```
ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID --admin
```

Vérifiez que les noeuds worker sont à l'état (State) normal et ont pour statut (Status) Ready. Une fois le cluster créé, il peut s'écouler jusqu'à 20 minutes pour que les noeuds worker soient prêts.

ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID

Exemple de sortie

ID                                                     Public IP         Private IP      Flavor              State     Status   Zone    Version
kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx    10.xxx.xx.xxx   u3c.2x4.encrypted   deployed   Ready    dal10   1.35

Vérifiez que les étapes pré requises pour la création de votre contrôleur d'entrée soient terminées.

Clusters classiques : obtenez les détails de la mappe de configuration ibm-cloud-provider-vlan-ip-config.

oc describe cm ibm-cloud-provider-vlan-ip-config -n kube-system

Si la mappe de configuration contient des adresses IP, passez à l'étape suivante.
Si la section Events contient un message d'avertissement semblable à ErrorSubnetLimitReached: There are already the maximum number of subnets permitted in this VLAN, reportez-vous à la rubrique relative au traitement des incidents liés à la capacité VLAN.

Exemple de sortie d'une mappe de configuration remplie avec des adresses IP :

NAME:         ibm-cloud-provider-vlan-ip-config
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
Data
====
reserved_public_vlan_id:
----
vlanipmap.json:
----
{
    "vlans": [
    {
      "id": "2234947",
      "subnets": [
        {
          "id": "2215454",
          "ips": [
            "10.XXX.XXX.XXX",
            "10.XXX.XXX.XXX",
            "10.XXX.XXX.XXX",
            "10.XXX.XXX.XXX",
            "10.XXX.XXX.XXX"
          ],
          "is_public": false,
          "is_byoip": false,
          "cidr": "10.XXX.XXX.X/29"
        }
      ],
      "zone": "dal10",
      "region": "us-south"
    },
    {
      "id": "2234945",
      "subnets": [
        {
          "id": "2219170",
          "ips": [
            "169.XX.XXX.XX",
            "169.XX.XXX.XX",
            "169.XX.XXX.XX",
            "169.XX.XXX.XX",
            "169.XX.XXX.XX"
          ],
          "is_public": true,
          "is_byoip": false,
          "cidr": "169.XX.XXX.X/29"
        }
      ],
      "zone": "dal10",
      "region": "us-south"
    }
    ],
    "vlan_errors": [],
    "reserved_ips": []
}
cluster_id:
----
bmnj1b1d09lpvv3oof0g
reserved_private_ip:
----
reserved_private_vlan_id:
----
reserved_public_ip:
----
Events:  <none>

Clusters VPC: vérifiez que l'équilibreur de charge VPC de vos contrôleurs Ingress existe bien. Dans la sortie, recherchez l'équilibreur de charge VPC Nom qui commence par kube-<cluster_ID>. Si vous n'avez pas installé le plug-in infrastructure-service, installez-le en exécutant ibmcloud plugin install infrastructure-service.

ibmcloud is load-balancers

Même si l'équilibreur de charge VPC est répertorié, son entrée DNS est peut-être toujours en cours d'enregistrement. Lorsqu'un équilibreur de charge VPC est créé, le nom d'hôte est enregistré via un DNS public. Parfois, il peut prendre plusieurs minutes pour que cette entrée DNS soit répliquée sur le DNS spécifique que votre client utilise.

Vérifiez que le contrôleur Ingress a été créé avec succès.

Vérifiez si un déploiement de contrôleur d'entrée existe pour votre cluster.
- Si un déploiement de contrôleur d'entrée est répertorié, passez à l'étape suivante.
- Si aucun déploiement de contrôleur d'entrée n'est créé après plusieurs minutes, examinez les moyens pour obtenir de l'aide.

    oc get deployment -n openshift-ingress
    ```
    Exemple de sortie
    ```sh {: screen}
    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
    router-default   2/2     2            2           26m
    ```
2. Vérifiez que le service d'équilibrage de charge du contrôleur d'entrée existe et qu'une adresse IP externe publique (clusters classiques) ou un nom d'hôte (clusters VPC) soit affecté.
    * Si un service nommé `router-default` est répertorié et qu'une adresse IP (clusters classiques) ou un nom d'hôte (clusters de VPC) lui est affecté, passez à l'étape suivante.
    * Si aucun service `router-default` n'est créé au bout de plusieurs minutes, [passez en revue les différents moyens vous permettant d'obtenir de l'aide](/docs/openshift?topic=openshift-get-help).

```sh {: pre}
    oc get svc -n openshift-ingress
    ```
    Exemple de sortie
    ```sh {: screen}
    NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
    router-default            LoadBalancer   172.21.47.119   169.XX.XX.XX   80:31182/TCP,443:31154/TCP   27m
    router-internal-default   ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26m
    ```

Vérifiez à nouveau si le sous-domaine et le secret Ingress sont créés. S'ils ne sont pas disponibles, mais que vous avez vérifié que tous les composants des étapes 1 à 3 existent, examinez les moyens pour obtenir de l'aide.
```
ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
```