Clústeres clásicos: ¿Por qué el controlador de Ingress no se despliega en una zona?
Proveedor y versión de infraestructura:
- Clásico
- Red Hat OpenShift versión 4
Cuando ejecuta oc get svc -n openshift-ingress, una o varias zonas no tienen ningún controlador de Ingress público.
- No se despliega ningún servicio
router-defaulto es posible que el servicio no tenga asignada ninguna dirección IP externa. Por ejemplo, en un clúster de una sola zona, puede ver lo siguiente:NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.21.47.119 <none> 80:32637/TCP,443:31719/TCP 26m router-internal-default ClusterIP 172.21.51.30 <none> 80/TCP,443/TCP,1936/TCP 26m - Si tiene un clúster multizona, una zona no tiene ningún servicio de controlador de Ingress. Por ejemplo, en un clúster multizona que tenga nodos de trabajo en
dal10,dal12, ydal13, es posible que veas un serviciorouter-defaultparadal10y unrouter-dal12servicio paradal12, pero ningúnrouter-dal13servicio paradal13. Ten en cuenta que el servicio de controlador de Ingress de la primera zona en la que tienes nodos de trabajo siempre se denominarouter-default, y que los servicios de controlador de Ingress de las zonas que añadas posteriormente a tu clúster tienen nombres comorouter-dal12. También puede ver que una zona no tiene ningún servicio de controlador de Ingress, pero que otra zona tiene dos o más servicios de controlador de Ingress.NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.21.47.119 169.XX.XX.XX 80:32637/TCP,443:31719/TCP 26m router-dal12 LoadBalancer 172.21.47.119 169.XX.XX.XX 80:32637/TCP,443:31719/TCP 26m router-internal-default ClusterIP 172.21.51.30 <none> 80/TCP,443/TCP,1936/TCP 26m
Los servicios de direccionador pueden no desplegarse por una de las siguientes razones:
-
Si no se despliega ningún servicio de controlador de Ingress o no se asignan servicios de controlador de Ingress a una dirección IP externa: en los clústeres estándar, la primera vez que crea un clúster en una zona, se suministran automáticamente una VLAN pública y una VLAN privada en esa zona en la cuenta de infraestructura de IBM Cloud. En esa zona, se solicita una subred portátil pública en la VLAN pública que especifiques y una subred portátil privada en la VLAN privada que especifiques. Para Red Hat OpenShift on IBM Cloud, las VLAN tienen un límite de 40 subredes. Si la VLAN del clúster en una zona ya ha alcanzado ese límite, el subdominio de Ingress no se aprovisiona y el controlador de Ingress público predeterminado tampoco se aprovisiona. Para ver cuántas subredes tiene una VLAN, desde la consola de infraestructura de IBM Cloud, selecciona Red > Gestión de IP > VLAN. Pulse el Número de VLAN de la VLAN que utilizó para crear el clúster. Revise la sección Subnets para ver si hay 40 o más subredes.
-
Si una zona no tiene servicio de controlador Ingress: cuando se crean los servicios de controlador de Ingress, se propagan automáticamente por las zonas del clúster. Si la red de la primera zona con la que se ha creado el clúster no está preparada cuando se crean los servicios de controlador de Ingress, el servicio de controlador de Ingress para esa zona puede colocarse en una zona diferente. Se pueden crear dos servicios de controlador de Ingress en una zona, y no se crea ningún servicio de controlador de Ingress en la zona inicial.
Resuelva los problemas de VLAN para los servicios de controlador de Ingress que no tienen direcciones IP, o los problemas de servicio del controlador de Ingress multizona para las zonas sin servicios de controlador de Ingress.
Resolución de problemas de VLAN
Para resolver problemas de VLAN para los servicios de controlador de Ingress que no tienen ninguna dirección IP:
Opción 1: Si necesitas una nueva VLAN, solicítala poniéndote en contacto con el servicio de asistencia de IBM Cloud. A continuación, cree un clúster que utilice esta nueva VLAN.
Opción 2: Si dispone de otra VLAN, puede configurar la extensión de VLAN en su clúster actual. Para comprobar si la extensión de VLAN ya está activada, utiliza
el. ibmcloud ks vlan spanning get --region REGIONcomando A continuación, puede añadir nuevos nodos trabajadores al clúster que utilicen
otra VLAN con subredes disponibles. Crea al menos dos nodos de trabajo por zona. Ahora, hay disponibles direcciones IP para que los controladores de Ingress puedan desplegarse automáticamente.
Opción 3: Si no está utilizando todas las subredes de la VLAN, puede reutilizar las subredes de la VLAN añadiéndolas a su clúster.
-
Compruebe que la subred que desea utilizar está disponible. La cuenta de infraestructura que utiliza podría compartirse entre varias cuentas de IBM Cloud. En este caso, aunque ejecute el mandato
ibmcloud oc subnetspara ver subredes con Clústeres enlazados, solo puede ver información de sus clústeres. Compruebe con el propietario de la cuenta de infraestructura para asegurarse de que las subredes están disponibles y que no las estén utilizando otra cuenta o equipo. -
Utilice el mandato
ibmcloud ks cluster subnet addpara que una subred existente esté disponible para el clúster. -
Compruebe que la subred se haya creado y añadido correctamente al clúster. El CIDR de subred se muestra en la sección Subnet VLANs.
ibmcloud ks cluster get --cluster CLUSTER_NAME --show-resourcesEn esta salida de ejemplo, se ha añadido una segunda subred a la VLAN pública
2234945:Subnet VLANs VLAN ID Subnet CIDR Public User-managed 2234947 10.xxx.xx.xxx/29 false false 2234945 169.xx.xxx.xxx/29 true false 2234945 169.xx.xxx.xxx/29 true false -
Verifique que las direcciones IP portátiles de la subred que ha añadido se utilizan para el controlador de Ingress del clúster. Los servicios puede tardar varios minutos en utilizar las direcciones IP portátiles de la nueva subred.
- No hay subdominio de Ingress: ejecute
ibmcloud ks cluster get --cluster CLUSTERpara verificar que el Subdominio de Ingress se ha rellenado. - Un controlador de Ingress no se despliega en una zona: ejecute
oc get svc -n openshift-ingresspara verificar que el controlador de Ingress que falta se despliega con una dirección IP externa.
- No hay subdominio de Ingress: ejecute
Resolución de problemas de despliegue del servicio del controlador de Ingress de multizona
Crea un servicio de controlador Ingress en la zona en la que no se haya implementado ningún servicio de controlador Ingress. Si inicialmente se ha creado un servicio de controlador de Ingress duplicado en una zona diferente, no suprima ese servicio de controlador de Ingress.
-
Crea un archivo YAML para un servicio de controlador de Ingress en la zona en la que no se ha implementado dicho servicio. Llame al servicio del controlador de Ingress
router-<zone>.apiVersion: v1 kind: Service metadata: annotations: service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public finalizers: - service.kubernetes.io/load-balancer-cleanup labels: app: router ingresscontroller.operator.openshift.io/owning-ingresscontroller: default router: router-default name: router-<zone> namespace: openshift-ingress spec: externalTrafficPolicy: Cluster selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default sessionAffinity: None type: LoadBalancer -
Cree el servicio de controlador de Ingress en el clúster.
oc create -f router-<zone>.yaml -
Verifique que el servicio del controlador de Ingress se haya creado en la zona correcta. En la salida, obtenga la dirección EXTERNAL IP.
oc get svc router-<zone> -n openshift-ingressSalida de ejemplo
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-dal12 LoadBalancer 172.21.57.132 169.XX.XX.XX 80/TCP,443/TCP,1940/TCP 3m -
Obtenga el subdominio para el controlador de Ingress predeterminado. En la salida, busque el subdominio formateado como
<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.ibmcloud ks nlb-dns ls -c CLUSTER_NAME_OR_ID -
Registre la dirección IP del servicio del controlador de Ingress con el subdominio del controlador de Ingress.
ibmcloud ks nlb-dns add -c CLUSTER_NAME_OR_ID --ip ROUTER_SVC_IP --nlb-host ROUTER_SUBDOMAIN