Perché non esiste alcun dominio secondario Ingress dopo la creazione del cluster?

Virtual Private Cloud Infrastruttura classica

Si crea un cluster e si esegue il comando ibmcloud oc cluster get --cluster CLUSTER per verificarne lo stato. Lo Stato del cluster è normal, ma il Dominio secondario Ingress e il Segreto Ingress non sono disponibili.

Anche se il cluster si trova in uno stato normal, il dominio secondario e il segreto Ingress potrebbero essere ancora in corso. La creazione del sottodominio e del segreto di Ingress potrebbe richiedere più di 15 minuti:

Cluster classici:

  1. Quando i nodi di lavoro sono completamente distribuiti e pronti sulle VLAN, vengono ordinate una sottorete pubblica portatile e una privata portatile per le VLAN.
  2. Dopo che gli ordini delle sottoreti portatili sono stati eseguiti correttamente, la mappa di configurazione ibm-cloud-provider-vlan-ip-config viene aggiornata con gli indirizzi IP pubblici e privati portatili.
  3. Quando viene aggiornata la mappa di configurazione " ibm-cloud-provider-vlan-ip-config ", viene attivato il controller Ingress per la creazione.
  4. Viene creato un servizio di bilanciamento del carico che espone il controller Ingress e gli viene assegnato un indirizzo IP.
  5. L'indirizzo IP del bilanciatore di carico viene utilizzato per registrare il sottodominio Ingress su IBM NS1. IBM NS1 potrebbero verificarsi ritardi durante la procedura di registrazione.

Cluster VPC:

  1. Quando crei un cluster VPC, vengono creati automaticamente due programmi di bilanciamento del carico VPC, uno privato e uno pubblico, all'esterno del tuo cluster nel tuo VPC.
  2. Viene avviata la creazione di un controller pubblico di Ingress per ogni zona.
  3. Viene creato un servizio di bilanciamento del carico che espone il controller Ingress e gli viene assegnato un nome host.
  4. Il nome host del bilanciatore di carico viene utilizzato per registrare il sottodominio Ingress su IBM NS1. IBM NS1 potrebbero verificarsi ritardi durante la procedura di registrazione.

Creare un cluster dopo aver eliminato un cluster con lo stesso nome o un nome simile? Vedi: non esiste alcun sottodominio "Ingress" dopo aver creato cluster con lo stesso nome o con nomi simili.

In genere, dopo che il cluster è pronto, il dominio secondario e il segreto Ingress vengono creati dopo 15 minuti. Se il dominio secondario e il segreto Ingress non sono ancora disponibili dopo che il tuo cluster si trova in uno stato normal per più di 15 minuti, puoi controllare l'avanzamento del processo di creazione seguendo questi passi:

  1. Accedi al tuo cluster. Poiché il sottodominio non è disponibile, non è possibile aprire la console di Red Hat OpenShift. In alternativa, è possibile impostare il contesto del cluster utilizzando l'opzione " --admin " tramite la CLI.

    ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID --admin
    
  2. Verifica che per i nodi di lavoro il valore State sia normal e il valore Status sia Ready. Dopo aver creato il cluster, possono essere necessari fino a 20 minuti prima che i nodi di lavoro siano pronti.

    ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
    

    Output di esempio

    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
    
  3. Verifica che siano state completate le operazioni preliminari necessarie per la creazione del tuo controller Ingress.

    • Cluster classici: ottieni i dettagli della mappa di configurazione ibm-cloud-provider-vlan-ip-config.
    oc describe cm ibm-cloud-provider-vlan-ip-config -n kube-system
    

    Output di esempio di una mappa di configurazione popolata con indirizzi 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>
    
    • Cluster VPC: verificare che sia presente il bilanciatore di carico VPC per i controller Ingress. Nell'output, individua il nome del bilanciatore di carico VPC che inizia con kube-<cluster_ID>. Se non hai installato il plug-in infrastructure-service, installalo eseguendo ibmcloud plugin install infrastructure-service.
    ibmcloud is load-balancers
    

    Anche se il programma di bilanciamento del carico VPC viene elencato, la sua voce DNS potrebbe essere ancora in fase di registrazione. Quando un programma di bilanciamento del carico VPC viene creato, il nome host viene registrato tramite un DNS pubblico. A volte possono essere necessari diversi minuti prima che questa voce DNS venga replicata sul server DNS specifico utilizzato dal cliente.

  4. Verifica che il controller Ingress sia stato creato correttamente.

    1. Verifica se per il tuo cluster esiste una distribuzione del controller Ingress.
      • Se è presente un'installazione di un controller di Ingress, passare al passaggio successivo.
      • Se dopo alcuni minuti non viene creata alcuna distribuzione di controller Ingress, consulta le modalità per ottenere assistenza.
        oc get deployment -n openshift-ingress
        ```
        Output di esempio
        ```sh {: screen}
        NAME             READY   UP-TO-DATE   AVAILABLE   AGE
        router-default   2/2     2            2           26m
        ```
    2. Verificare che il servizio di bilanciamento del carico del controller Ingress esista e che gli sia stato assegnato un indirizzo IP esterno pubblico (cluster classici) o un nome host (cluster VPC).
        * Se viene elencato un servizio denominato `router-default` a cui è assegnato un indirizzo IP (cluster classici) o un nome host (cluster VPC), vai al passo successivo.
        * Se non viene creato alcun servizio `router-default` dopo alcuni minuti, [riesamina i modi per ottenere assistenza](/docs/openshift?topic=openshift-get-help).
    
    ```sh {: pre}
        oc get svc -n openshift-ingress
        ```
        Output di esempio
        ```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
        ```
    
  5. Controlla di nuovo se il dominio secondario e il segreto Ingress sono stati creati. Se non sono disponibili, ma hai verificato che tutti i componenti indicati nei passaggi da 1 a 3 siano presenti, valuta le modalità per ottenere assistenza.

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID