En este artículo se responde a las preguntas más frecuentes (P+F) sobre Red Hat OpenShift en Microsoft Azure.
Instalación y actualización
¿Dónde puedo encontrar información sobre los precios y los acuerdos de nivel de servicio?
Para obtener información sobre los precios, consulte Precios de Red Hat OpenShift en Azure.
Para obtener información sobre el Acuerdo de Nivel de Servicio (SLA), consulte Acuerdos de Nivel de Servicio para servicios en línea.
¿Qué regiones de Azure se admiten?
A fin de obtener una lista de las regiones admitidas para Red Hat OpenShift en Azure 4.x, vea Regiones disponibles.
¿Qué tamaños de máquina virtual puedo usar?
A fin de obtener una lista de los tamaños de máquina virtual admitidos para Red Hat OpenShift en Azure 4, vea Recursos compatibles con Red Hat OpenShift en Azure 4.
¿Cuál es el número máximo de pods en un clúster de Red Hat OpenShift en Azure? ¿Cuál es el número máximo de pods por nodo de Red Hat OpenShift en Azure?
El número real de pods admitidos depende de los requisitos de memoria, CPU y almacenamiento de una aplicación.
Red Hat OpenShift en Azure 4.x tiene un límite de 250 pods por nodo y otro de 60 nodos de ejecución. Estos límites restringen el número máximo de pods admitidos en un clúster a 250 × 60 = 15 000. Para un clúster privado sin direcciones IP públicas (por ejemplo, creado mediante el enrutamiento definido por el usuario [UDR] y con la versión 4.11 o superior), los límites son 120 nodos de proceso y 30 000 pods.
¿Un clúster puede tener nodos de proceso en varias regiones de Azure?
No. Todos los nodos de un clúster de Red Hat OpenShift en Azure se deben originar en la misma región de Azure.
¿Se puede implementar un clúster en varias zonas de disponibilidad?
Sí. Un clúster se puede implementar automáticamente en varias zonas de disponibilidad si el clúster se implementa en una región de Azure que admite zonas de disponibilidad. Para más información, consulte Zonas de disponibilidad.
¿Los nodos de plano de control se abstraen como lo hacen con Azure Kubernetes Service (AKS)?
No. Todos los recursos, incluidos los nodos de plano de control del clúster, se ejecutan en su suscripción de cliente. Estos tipos de recursos se colocan en un grupo de recursos de solo lectura.
¿El clúster se encuentra en una suscripción de cliente?
La aplicación administrada de Azure reside en un grupo de recursos bloqueado con la suscripción del cliente. Los clientes pueden ver los objetos de ese grupo de recursos, pero no modificarlos.
¿Hay algún elemento en Red Hat OpenShift en Azure compartido con otros clientes? ¿O todo es independiente?
Cada clúster de Red Hat OpenShift en Azure está dedicado a un cliente determinado y vive en la suscripción del cliente.
¿Están disponibles los nodos de infraestructura?
Sí, ARO permite usar conjuntos de máquinas de infraestructura para crear máquinas que solo hospedan componentes de infraestructura, como el enrutador predeterminado, el registro de contenedor integrado y los componentes para las métricas y la supervisión del clúster. Consulte Implementación de nodos de infraestructura en un clúster de ARO para obtener más información.
¿Cómo administrar las actualizaciones del clúster?
Para información sobre las actualizaciones, el mantenimiento y las versiones admitidas, consulte la guía del ciclo de vida de soporte técnico.
¿Cómo se actualizará el sistema operativo host y el software OpenShift?
Los sistemas operativos host y el software OpenShift se actualizan a medida que Red Hat OpenShift en Azure consume versiones secundarias y revisiones de OpenShift Container Platform ascendente.
¿Cuál es el proceso de reinicio del nodo actualizado?
Los nodos se reinician como parte de una actualización.
Operaciones del clúster
¿Se puede usar Prometheus para supervisar las aplicaciones?
Prometheus viene preinstalado y configurado para los clústeres de Red Hat OpenShift en Azure 4.x. Obtenga más información sobre la supervisión de clústeres.
¿Puedo usar Prometheus para supervisar las métricas relacionadas con la capacidad y el mantenimiento del clúster?
En Red Hat OpenShift en Azure 4.x: Sí.
¿Se pueden transmitir los registros de máquinas virtuales subyacentes a un sistema de análisis de registros de cliente?
Los registros de las máquinas virtuales subyacentes se controlan mediante el servicio administrado y no se exponen a los clientes.
¿Cómo puede un cliente obtener acceso a métricas como CPU y memoria en el nivel de nodo para tomar medidas a fin de escalar, depurar incidencias, etc.? No parece que se pueda ejecutar kubectl en un clúster de Red Hat OpenShift en Azure.
En el caso de los clústeres de Red Hat OpenShift en Azure 4.x, la consola web de OpenShift contiene todas las métricas en el nivel de nodo. Para obtener más información, vea la documentación de Red Hat sobre vista de la información del clúster.
Si escalamos verticalmente la implementación, ¿cómo se asignan los dominios de error de Azure en la colocación de los pods para garantizar que ningún pod de un servicio se ve afectado por un error en un único dominio de error?
De manera predeterminada, hay cinco dominios de error cuando se usa Virtual Machine Scale Sets en Azure. Cada instancia de máquina virtual de un conjunto de escalado se colocará en uno de estos dominios de error. Esto garantiza que las aplicaciones implementadas en los nodos de proceso de un clúster se colocarán en distintos dominios de error.
Para obtener más información, consulte Elección del número correcto de dominios de error para Virtual Machine Scale Set.
¿Hay alguna manera de administrar la colocación de los pods?
Los clientes tienen la posibilidad de obtener nodos y ver etiquetas con el rol customer-admin. De esta forma, podrán dirigirse a cualquier máquina virtual del conjunto de escalado.
Es necesario tener cuidado al usar etiquetas específicas:
- No se debe usar el nombre de host. El nombre de host se rota con frecuencia con las actualizaciones y es seguro que cambiará.
- Si el cliente tiene una solicitud de etiquetas específicas o una estrategia de implementación, se podría hacer. Sin embargo, harían falta labores de ingeniería y no se admite actualmente.
Para obtener más información, vea Control de la selección de ubicación del pod.
¿Está disponible externamente el registro de imágenes para poder usar herramientas como Jenkins?
En el caso de los clústeres 4.x, debe exponer un registro seguro y configurar la autenticación. Para obtener más información, vea la documentación de Red Hat siguiente:
¿Puedo mover o migrar mi clúster entre inquilinos de Azure?
Actualmente, no se admite el traslado de los clústeres de ARO entre inquilinos.
¿Puedo trasladar los clústeres de ARO de la suscripción actual de Azure a otra suscripción?
No se admite el traslado de los clústeres de ARO y de los recursos asociados entre suscripciones.
¿Puedo mover los clústeres de ARO o los recursos de infraestructura de ARO a otros grupos de recursos o cambiarles el nombre?
No se admite mover el clúster de ARO y sus recursos asociados ni cambiarles el nombre.
Redes
¿Puedo implementar un clúster en una red virtual existente?
En los clústeres 4.x, se puede implementar un clúster en una red virtual existente.
¿Se admiten las redes entre espacios de nombres?
Los administradores de proyectos de cliente e individuales pueden personalizar las redes entre espacios de nombres (incluido denegarlas) por proyecto con objetos NetworkPolicy.
Estoy intentando mirar una red virtual de otra suscripción, pero recibo el error Failed to get VNet CIDR (Error al obtener el CIDR de red virtual).
En la suscripción que tiene la red virtual, asegúrese de registrar el proveedor Microsoft.ContainerService con el comando siguiente: az provider register -n Microsoft.ContainerService --wait.
¿Se pueden especificar intervalos IP para la implementación en la red virtual privada y evitar los conflictos con otras redes virtuales corporativas una vez emparejadas?
En los clústeres 4.x, puede especificar sus propios intervalos IP.
¿Se puede configurar el módulo Red definida por el software?
La red definida por el software es openshift-ovs-networkpolicy y no se puede configurar.
¿Qué Equilibrador de carga de Azure usa Red Hat OpenShift en Azure? ¿Es Estándar o Básico y es configurable?
Red Hat OpenShift en Azure usa Standard Azure Load Balancer y no es configurable.
Permisos
¿Puede un administrador administrar usuarios y cuotas?
Sí. Un administrador de Red Hat OpenShift en Azure puede administrar usuarios y cuotas, además de acceder a todos los proyectos creados por los usuarios.
¿Puedo restringir un clúster solo a determinados usuarios de Microsoft Entra?
Sí. Puede restringir qué usuarios de Microsoft Entra pueden iniciar sesión en un clúster configurando la aplicación Microsoft Entra. Para obtener más información, consulte Procedimiento para restringir la aplicación a un conjunto de usuarios.
¿Puedo impedir que los usuarios creen proyectos?
Sí. Inicie sesión en el clúster como administrador y ejecute este comando:
oc adm policy \
remove-cluster-role-from-group self-provisioner \
system:authenticated:oauth
Para obtener más información, vea la documentación de OpenShift sobre la deshabilitación del aprovisionamiento automático para la versión del clúster:
¿Qué derechos de UNIX (en IaaS) están disponibles para los nodos maestros, infraestructura o aplicaciones?
El acceso al nodo está disponible a través del rol de administrador de clústeres. Para más información, consulte la información general sobre RBAC de Kubernetes.
¿Qué derechos de OCP tenemos? ¿Administrador del clúster? ¿Administrador de proyectos?
El rol de administrador de clústeres está disponible. Para más información, consulte la información general sobre RBAC de Kubernetes.
¿Qué proveedores de identidades están disponibles?
Configure su propio proveedor de identidades. Para obtener más información, consulte la documentación de Red Hat sobre configuración de los proveedores de identidades.
Storage
¿Están cifrados los datos de mi clúster?
De forma predeterminada, los datos se cifran en reposo. La plataforma de Azure Storage cifra automáticamente los datos antes de almacenarlos y los descifra antes de recuperarlos. Para más información, consulte Cifrado del servicio Azure Storage para datos en reposo.
¿Cómo se protegen mis cuentas de almacenamiento?
Las cuentas de almacenamiento se establecen solo en acceso privado.
Las cuentas de almacenamiento están cifradas (solo clústeres nuevos). Es necesario volver a crear los clústeres existentes.
Las cuentas de almacenamiento se crean con la versión 2 de uso general para nuevos clústeres.
Las cuentas de almacenamiento de uso general v2 son compatibles con las características más recientes de Azure Storage e incorporan todas las funcionalidades de las cuentas de almacenamiento de uso general v1 y de blobs.
El acceso a las cuentas de almacenamiento está limitado con reglas de firewall mediante grupos de seguridad de red (NSG) de Azure, que filtran el tráfico de red hacia las cuentas de almacenamiento y desde ellas. Para más información, consulte Introducción a los grupos de seguridad de red de Azure.
La versión 1.2 del protocolo Seguridad de la capa de transporte (TLS) proporciona comunicaciones seguras, privacidad de los datos e integridad de los datos.
¿Los datos almacenados en etcd están cifrados en Red Hat OpenShift en Azure?
Los datos no se cifran de manera predeterminada, pero tiene la opción de habilitar el cifrado. Para obtener más información, vea la guía sobre cifrado de etcd.
¿Podemos elegir cualquier solución de almacenamiento persistente, como OCS?
Azure Disk (Premium_LRS) se configura como la clase de almacenamiento predeterminada. Para obtener más información sobre los proveedores de almacenamiento y los detalles de configuración (incluido Azure File), vea la documentación de Red Hat sobre almacenamiento persistente.
¿ARO guarda datos de los clientes fuera de la región del clúster?
No. Todos los datos que se crean en un clúster de ARO se mantienen en la región del clúster.