Preguntas más frecuentes de Red Hat OpenShift en Azure

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

¿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.

A fin de obtener una lista de las regiones admitidas para Red Hat OpenShift en Azure 3.11, vea Productos disponibles por región.

¿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.

A fin de obtener una lista de los tamaños de máquina virtual admitidos para Red Hat OpenShift en Azure 3.11, vea Recursos compatibles con Red Hat OpenShift en Azure 3.11.

¿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.

Red Hat OpenShift en Azure 3.11 tiene un límite de 50 pods por nodo y otro de 20 nodos de ejecución. Estos límites restringen el número máximo de pods admitidos en un clúster a 50 × 20 = 1000.

¿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?

En los clústeres de Red Hat OpenShift en Azure 4.x, los nodos de infraestructura no están disponibles actualmente.

En los clústeres de Red Hat OpenShift en Azure 3.11, los nodos de infraestructura están incluidos de forma predeterminada.

¿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.

En el caso de los clústeres de Red Hat OpenShift en Azure 3.11, se puede implementar Prometheus en su espacio de nombres y supervisar las aplicaciones en él. Para obtener más información, vea Implementación de una instancia de Prometheus en un clúster de Red Hat OpenShift en Azure.

¿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í.

En Red Hat OpenShift en Azure 3.11: No.

¿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.

En el caso de los clústeres de Red Hat OpenShift en Azure 3.11, los clientes pueden acceder a las métricas de CPU o memoria en el nivel de nodo mediante el comando oc adm top nodes o kubectl top nodes con el rol de clúster customer-admin. Los clientes también pueden acceder a las métricas de CPU o memoria de pods con el comando oc adm top pods o kubectl top pods.

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 forma predeterminada, hay cinco dominios de error cuando se usan conjuntos de escalado de máquinas virtuales 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.

A fin de obtener más información, vea Elección del número correcto de dominios de error para el conjunto de escalado de máquinas virtuales.

¿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:

En el caso de los clústeres 3.11, el registro de imágenes de Docker está disponible. El registro de Docker está disponible en https://docker-registry.apps.<clustername>.<region>.azmosa.io/. También se puede usar Azure Container Registry.

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.

En los clústeres 3.11, no se puede implementar un clúster en una red virtual existente. Pero se puede conectar un clúster de Red Hat OpenShift en Azure 3.11 en una red virtual existente mediante emparejamiento.

¿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.

En los clústeres 3.11, Red Hat OpenShift en Azure admite el emparejamiento de VNet. Red Hat OpenShift en Azure permite al cliente proporcionar una red virtual con la que emparejar y un CIDR de red virtual en el que funcionará la red OpenShift.

La red virtual que ha creado Red Hat OpenShift en Azure estará protegida y no aceptará cambios de configuración. La red virtual que está emparejada la controla el cliente y reside en su suscripción.

¿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 a solo determinados usuarios de Azure AD?

Sí. Puede restringir qué usuarios de Azure AD pueden iniciar sesión en un clúster configurando la aplicación de Azure AD. Para más información, consulte Procedimientos 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?

En el caso de los clústeres 4.x, 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.

En el caso de los clústeres 3.11, el acceso al nodo está prohibido.

¿Qué derechos de OCP tenemos? ¿Administrador del clúster? ¿Administrador de proyectos?

En el caso de los clústeres 4.x, el rol de administrador del clúster está disponible. Para más información, consulte la información general sobre RBAC de Kubernetes.

En el caso de los clústeres 3.11, vea la información general de administración del clúster para obtener más detalles.

¿Qué proveedores de identidades están disponibles?

En el caso de los clústeres 4.x, va a configurar 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.

En el caso de los clústeres 3.11, se puede usar la integración de Azure AD.

Almacenamiento

¿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?

En el caso de los clústeres de Red Hat OpenShift en Azure 4, los datos no se cifran de forma predeterminada, pero tiene la opción de habilitar el cifrado. Para obtener más información, vea la guía sobre cifrado de etcd.

En el caso de los clústeres 3.11, los datos no se cifran en el nivel de etcd. Actualmente no se admite la opción para activar el cifrado. OpenShift es compatible con esta característica, pero se requieren labores de ingeniería para crearla en la hoja de ruta. Los datos se cifran en el nivel de disco. Consulte Encrypting Data at Datastore Layer (Cifrado de datos en la capa de almacén de datos) para más información.

¿Podemos elegir cualquier solución de almacenamiento persistente, como OCS?

En el caso de los clústeres 4.x, 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.

En el caso de los clústeres 3.11, se proporcionan dos clases de almacenamiento de forma predeterminada: una para Azure Disk (Premium_LRS) y otra para Azure File.

¿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.