Paso 1: Comprobar la configuración de la cuenta

Compruebe que la cuenta de IBM Cloud se ha configurado correctamente. Algunos escenarios comunes que pueden impedir que los componentes predeterminados se ejecuten correctamente son los siguientes:

• Si el clúster clásico tiene varias zonas, o si tiene un clúster de VPC, asegúrese de que habilita la expansión de VLAN o VRF. Para comprobar si VRF ya está habilitado, ejecute ibmcloud account show. Para comprobar si la expansión de VLAN está habilitada, ejecute ibmcloud oc vlan spanning get.
• Si algunos usuarios de la cuenta utilizan una autenticación multifactorial (MFA), como TOTP, asegúrate de habilitar la MFA para todos los usuarios de la cuenta de IBM Cloud.

No se da soporte a la habilitación de MFA a nivel de usuario. Si MFA está habilitado para algunos usuarios pero no está habilitado para todos los usuarios a nivel de cuenta, pueden producirse errores de autenticación.

Paso 2: Comprobar la pasarela pública

• Para los clústeres de VPC con puntos finales de servicio de nube pública y privada habilitados:

  Compruebe que una pasarela pública esté habilitada en cada subred de VPC a la que está conectado el clúster. Se necesita una pasarela pública para que los componentes predeterminados, como la consola web y OperatorHub, utilicen una conexión pública segura para completar acciones como, por ejemplo, extraer imágenes de registros remotos y privados.

  1. Utilice la consola o la CLI de IBM Cloud para asegurarse de que haya una pasarela pública habilitada en cada subred a la que está conectado el clúster.
  2. Reinicie los componentes para el catálogo del desarrollador en la consola web.
     1. Edite el mapa de configuración del operador de muestras (samples operator).

        oc edit configs.samples.operator.openshift.io/cluster
        

  3. Cambie el valor de managementState, Removed, por Managed. 3. Guarde y cierre el mapa de configuración. Los cambios se aplican automáticamente.

• Para los clústeres clásicos con puntos finales de servicio de nube pública y privada habilitados:

  Compruebe que el clúster tiene conectividad pública para que los componentes de red puedan comunicarse con el nodo maestro a medida que se despliegan.

  1. Compruebe el estado del nodo maestro (Master Status). Si Master Status no es Ready, revise su estado y siga la información sobre resolución de problemas para solucionar el problema.

      ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
      ```
  1. En la salida de **Estado maestro**, compruebe que el clúster tenga un **URL de punto final de servicio**. Si tu clúster no dispone de un punto final de servicio en la nube pública, actívalo.
  1. Compruebe que al menos algunos nodos de trabajador del clúster tengan una dirección **IP pública**. Si ningún nodo de trabajo lo hace, debe configurar VLAN públicas para al menos un grupo de trabajadores.
  
  ```sh {: pre}
      ibmcloud oc workers -c CLUSTER_NAME_OR_ID
      ```
  

Paso 3: Comprobar cortafuegos y políticas de red

Compruebe los cortafuegos o las políticas de red para verificar que no bloquea ningún tráfico de entrada o salida para OperatorHub u otros componentes de Red Hat OpenShift.

• Si ha generado una lista de elementos permitidos de IBM Cloud Identity and Access Management (IAM) especificando las direcciones IP que tienen acceso al clúster, debe añadir los CIDR del plano de control de Red Hat OpenShift on IBM Cloud para las zonas en la región donde se encuentra el clúster en la lista de elementos permitidos.
• Solo clásico: si tiene un cortafuegos, abra los puertos necesarios y las direcciones IP en el cortafuegos.
• Solo VPC: si controla el tráfico con ACL de VPC o grupos de seguridad, asegúrese de permitir las reglas de entrada y salida mínimas necesarias.

Paso 4: Comprobar la configuración del clúster

Compruebe que el clúster está configurado correctamente. Si acaba de crear el clúster, espere hasta que los componentes del clúster se suministren por completo.

1. Obtenga los destalles del clúster.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

2. Revise la salida del paso anterior para comprobar el Subdominio de ingreso.
   • Si el clúster no tiene un subdominio, consulte No existe ningún subdominio de Ingress después de la creación del clúster.
   • Si el clúster no tiene un subdominio, continúe en el paso siguiente.
3. Verifique que el clúster la última Versión de parche. Si el clúster no ejecuta la última versión de parche, actualice el clúster y los nodos trabajadores.
   1. Actualice el maestro de clúster a la última versión de parche para la versión principal y menor del clúster.

       ibmcloud oc cluster master update -c CLUSTER_NAME_OR_ID --version MAJOR.MINOR_openshift-f
       ```
   2. Liste los nodos de trabajador.
   ```sh {: pre}
       ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
       ```
   3. [Actualice los nodos trabajadores](/docs/openshift?topic=openshift-update#worker_node) para que coincida con la versión del nodo maestro del clúster.
   ```sh {: pre}
       ibmcloud oc worker update -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID -w WORKER3_ID
       ```
   

4. Compruebe el Estado del clúster. Si el estado no es normal, revise el estado del clúster y resuelva cualquier problema.
5. Compruebe el estado del nodo maestro (Master health). Si el estado no es normal, revise el estado de salud maestro y resuelva cualquier problema.
6. Compruebe los nodos trabajadores en los que se pueden ejecutar los componentes de Red Hat OpenShift. Si el estado no es normal, consulte Depuración de nodos trabajadores.

   ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
   

Paso 5: Iniciar sesión en el clúster

Inicie la sesión en el clúster. Tenga en cuenta que si la consola web de Red Hat OpenShift no funciona para que obtenga la señal de inicio de sesión, puede acceder al clúster desde la CLI.

Solo VPC: si ha habilitado solo el punto final de servicio en la nube privado, debe estar conectado a la red privada a través de la conexión VPN de VPC para acceder a la consola web.

Paso 6: Comprobar los pods de los componentes

Compruebe el estado de los pods de componente de Red Hat OpenShift que no funcionan.

1. Compruebe el estado del pod.

   oc get pods -n <project>
   

2. Si un pod no está en el estado Running, describa el pod y compruebe si hay sucesos. Por ejemplo, es posible que vea un error que indica que el pod no se puede planificar porque faltan recursos de CPU o de memoria, que es común si tiene un clúster con menos de 3 nodos de trabajador. Redimensione la agrupación de nodos trabajadores clásica o Redimensione la agrupación de nodos trabajadores de VPC e inténtelo de nuevo.

   oc describe pod -n <project> <pod>
   

3. Si no ve ninguna información útil en la sección de sucesos, consulte los registros del pod para ver si hay algún mensaje de error u otra información de resolución de problemas.

   oc logs pod -n <project> <pod>
   

4. Reinicie el pod y compruebe si alcanza el estado Running.

   oc delete pod -n <project> <pod>
   

Paso 7: Comprobar los pods del sistema

Si los pods están en buen estado, compruebe si otros pods del sistema están experimentando problemas. A menudo, para funcionar correctamente, un componente depende de otro componente para estar en buen estado.

Por ejemplo, OperatorHub tiene un conjunto de imágenes que se almacenan en registros externos como quay.io. Estas imágenes se extraen en el registro interno para que las puedan utilizar los proyectos del clúster de Red Hat OpenShift. Si alguno de los componentes de registro interno o de OperatorHub no está configurado correctamente, por ejemplo, porque faltan permisos o recursos de cálculo, OperatorHub y el catálogo no se visualizan.

1. Busque si hay algún pod pendiente.

   oc get pods --all-namespaces | grep Pending
   

2. Describa los pods y compruebe si hay Sucesos.

   oc describe pod -n <project_name> <pod_name>
   

   Por ejemplo, algunos de los mensajes comunes que puede ver desde los pods openshift-image-registry son:
   • Un mensaje de error de Volume could not be created porque ha creado el clúster sin el permiso de almacenamiento correcto. Los clústeres de Red Hat OpenShift on IBM Cloud vienen con un dispositivo de almacenamiento de archivos de forma predeterminada para almacenar imágenes para el sistema y otros pods. Revise los permisos de infraestructura y reinicie el pod.
   • Un mensaje de error que indica que order will exceed maximum number of storage volumes allowed porque ha sobrepasado la cuota combinada de dispositivos de almacenamiento en bloque y de archivos que permite la cuenta. Elimine los dispositivos de almacenamiento que no utilice o aumente la cuota de almacenamiento y reinicie el pod.
   • Un mensaje que indica que las imágenes no se pueden almacenar porque el dispositivo de almacenamiento de archivos está lleno. Redimensione el dispositivo de almacenamiento y reinicie el pod.
   • Un mensaje de error de Pull image still failed due to error: unauthorized: authentication required porque el registro interno no puede extraer imágenes de un registro externo. Compruebe que los secretos de extracción de imágenes estén establecidos para el proyecto y reinicie el pod.
3. Compruebe el Nodo en el que se ejecutan los pods anómalos. Si todos los pods se ejecutan en el mismo nodo trabajador, es posible que el nodo trabajador tenga un problema de conectividad de red. Vuelva a cargar el nodo de trabajador.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Paso 8: Comprueba la VPN

Comprueba que la VPN del clúster esté configurada correctamente.

1. Comprueba que el pod de VPN esté en ejecución.

   oc get pods -n kube-system -l app=vpn
   

2. Comprueba los registros de la VPN y busca un mensaje ERROR como WORKERIP:<port>, por ejemplo WORKERIP:10250, que indique que el túnel VPN no funciona.

   oc logs -n kube-system <vpn_pod> --tail 10
   

3. Si ve el error de IP de nodo trabajador, compruebe si la comunicación entre nodo trabajador y nodo trabajador se ha interrumpido. Inicie una sesión en un pod calico-node en el proyecto calico-system y compruebe si se produce el mismo error WORKERIP:10250.

   oc exec -n calico-system <calico-node_pod> -- date
   

4. Si la comunicación entre nodo trabajador y nodo trabajador se ha interrumpido, asegúrese de que habilita la expansión de VLAN o VRF.
5. Si aparece un error distinto al de la VPN o al del pod calico-node, reinicia el pod de la VPN.

   oc delete pod -n kube-system <vpn_pod>
   

6. Si la VPN sigue sin funcionar, comprueba el nodo de trabajo en el que se ejecuta el pod.

   oc describe pod -n kube-system <vpn_pod> | grep "Node:"
   

7. Aislar el nodo de trabajo para que el pod de la VPN se reasigne a otro nodo de trabajo.

   oc cordon <worker_node>
   

8. Comprueba de nuevo los registros del pod de la VPN. Si el pod ya no contiene un error, es posible que el nodo trabajador tenga un problema de conectividad de red. Vuelva a cargar el nodo de trabajador.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Paso 9: Renovar el nodo maestro del clúster

Renueve el nodo maestro del clúster para configurar los componentes predeterminados de Red Hat OpenShift. Después de renovar el clúster, espere unos minutos para permitir que finalice la operación.

ibmcloud oc cluster master refresh -c CLUSTER_NAME_OR_ID

Paso 10: Reintentar

Intente utilizar de nuevo el componente Red Hat OpenShift.

Si el error todavía existe, consulte Comentarios, preguntas y soporte.