Limitaciones del servicio
Red Hat® OpenShift® on IBM Cloud® y el proyecto de código abierto de Red Hat OpenShift se proporcionan con valores predeterminados de servicio y limitaciones para garantizar la seguridad, la comodidad y la funcionalidad básica. Algunas limitaciones se pueden cambiar donde se indica.
Si cree que va a alcanzar alguna de las siguientes limitaciones de Red Hat OpenShift on IBM Cloud, póngase en contacto con el equipo de soporte de IBM y especifique el ID de clúster, el nuevo límite de cuota y la región en la incidencia de soporte.
Limitaciones de servicio y cuota
Red Hat OpenShift on IBM Cloud se proporciona con las siguientes cuotas y limitaciones de servicio que se aplican a todos los clústeres, independientemente del proveedor de infraestructura que tenga previsto utilizar. Tenga en cuenta que también se aplican las limitaciones de los clústeres clásicos y de VPC.
Para ver los límites de cuota de los recursos relacionados con el clúster en la cuenta de IBM Cloud, utilice el mandato ibmcloud oc quota ls
.
Categoría | Descripción |
---|---|
Límites de velocidad de API | 200 solicitudes por 10 segundos a la API de Red Hat OpenShift on IBM Cloud por cada dirección IP de origen exclusiva. |
Despliegue de aplicaciones | Las apps que despliega y los servicios que integra con el clúster deben poderse ejecuta en el sistema operativo de los nodos trabajadores. |
El plugin de red de Calico | No se da soporte al cambio del plugin de Calico, los componentes o los valores predeterminados de Calico. Por ejemplo, no despliegue una nueva versión de plugin de Calico ni modifique los conjuntos de daemon o los despliegues de los componentes
de Calico, los recursos de IPPool predeterminados o los nodos de Calico. En su lugar, puede seguir la documentación para crear una NetworkPolicy o GlobalNetworkPolicy de Calico, para cambiar la MTU de Calico, o para inhabilitar el plugin de correlación de puertos para el CNI de Calico. |
Cuota de clústeres | No puede superar los 100 clústeres por región y por proveedor de infraestructura. Sin embargo, a partir del 01 de enero de 2024, las cuotas se incrementan
de manera incremental antes de llegar a 100. Si necesita más cantidad de un recurso, póngase en contacto con el servicio de soporte de IBM. En el caso de soporte, incluya el nuevo
límite de cuota para la región y el proveedor de infraestructura que desee.. Para listar cuotas, ejecute ibmcloud quota ls . |
Kubernetes | Asegúrese de revisar las limitaciones del proyecto Kubernetes. |
Proveedor de KMS | No se da soporte a la personalización de las direcciones IP permitidas para conectarse a la instancia de IBM® Key Protect for IBM Cloud®. |
Red Hat OpenShift | Asegúrese de revisar las limitaciones de OpenShift Container Platform para su versión. |
Registros de pod de Kubernetes | Para consultar los registros de pods de aplicación individuales, puede utilizar la línea de mandatos para ejecutar oc logs <pod name> . No utilice el panel de control de Kubernetes para hacer continuos registros de sus
pods, pues podría provocar una interrupción en el acceso al panel de control de Kubernetes. |
Supervisión |
|
Sistema operativo | Los nodos trabajadores deben ejecutar uno de los sistemas operativos soportados. No puede crear un clúster con nodos trabajadores que ejecuten distintos tipos de sistemas operativos. Para obtener más información, consulte la información de versión deRed Hat OpenShift on IBM Cloud. |
Catálogo de OperatorHub | Para utilizar el catálogo OperatorHub en clústeres privados, consulte Inhabilitación de OperatorHub y duplicación de imágenes de origen de catálogo en icr.io . |
Instancias de pod | Puede ejecutar 110 pods por nodo trabajador. Si tiene nodos trabajadores con 11 núcleos de CPU o más, puede dar soporte a 10 pods por núcleo, hasta un límite de 250 pods por nodo trabajador. El número de pods incluye los pods kube-system e ibm-system que se ejecutan en el nodo trabajador. Para mejorar el rendimiento, considere la posibilidad de limitar el número de pods que ejecuta por núcleo de cálculo para no sobreutilizar el nodo de trabajador. Por ejemplo,
en un nodo trabajador de tipo b3c.4x16 , puede ejecutar 10 pods por núcleo que no utilicen más del 75 % de la capacidad total del nodo trabajador. |
En desuso Código de acceso único basado en tiempo (TOTP) | Para utilizar TOTP, asegúrese de que habilita la autenticación multifactor (MFA) para toda la cuenta de IBM Cloud. Si la MFA solo está habilitada para algunos usuarios pero no a nivel de cuenta, se pueden producir errores de autenticación. |
Cuota de nodos trabajadores | Un máximo de 500 nodos de trabajador para cualquier cuenta creada antes del 1 de enero de 2024. Para las cuentas creadas a partir de esa fecha, la cuota máxima es de 200 tras un periodo de cuotas inferiores. Las cuotas se aplican por
proveedor de infraestructura de clúster. Si necesita más cantidad de un recurso, póngase en contacto con el servicio de soporte de IBM. En el caso de soporte, incluya el nuevo
límite de cuota para la región y el proveedor de infraestructura que desee.. Para listar las cuotas ejecutadas, ibmcloud ks quota ls . |
Tamaño de la agrupación de nodos trabajadores | Siempre debe tener un mínimo de 2 nodos en su clúster. Debido a la cuota de nodos trabajadores, tiene un límite en el número de agrupaciones de nodos trabajadores por clúster y en el número de nodos trabajadores por agrupación de nodos trabajadores. Por ejemplo, con la cuota de nodos trabajadores predeterminada de 500 por región, puede tener un máximo de 500 agrupaciones de nodos trabajadores de 1 nodo trabajador cada una en una región con solo 1 clúster. O bien, puede tener 1 agrupación de nodos trabajadores con un máximo de 500 nodos trabajadores en una región con solo 1 clúster. |
Red Hat Enterprise Linux CoreOS | La cantidad máxima de zonas añadidas a un clúster es 15. Por ejemplo, 4 agrupaciones de nodos trabajadores RHCOS con 3 zonas cada una representarán 12/15 de la cuota para ese clúster. |
Número de nodos de trabajador | Los clusters pueden tener un máximo de 500 nodos trabajadores. |
Red Hat Enterprise Linux CoreOS | La cantidad máxima de zonas añadidas a un clúster es 15. Por ejemplo, 4 agrupaciones de nodos trabajadores RHCOS con 3 zonas cada una representarán 12/15 de la cuota para ese clúster. |
Denominación de clústeres | Para asegurarse de que el subdominio y el certificado de Ingress se han registrado correctamente, los primeros 24 caracteres de los nombres de los clústeres deben ser distintos. Si crea y suprime clústeres con el mismo nombre, o nombres que tienen los mismos primeros 24 caracteres, 5 veces o más en un plazo de 7 días, por ejemplo, por motivos de automatización o pruebas, es posible que alcance el límite de velocidad de duplicación de certificados de Let's Encrypt. |
Grupos de recursos | Un clúster solo se puede crear en un grupo de recursos que no se puede cambiar después. Si crea un clúster en el grupo de recursos incorrecto, debe suprimir el clúster y volver a crearlo en el grupo de recursos correcto. Además, si necesita
utilizar el mandato ibmcloud oc cluster service bind para integrar con un servicio de IBM Cloud, este servicio debe estar en el mismo grupo de recursos
que el clúster. Los servicios que no utilizan grupos de recursos, como IBM Cloud Container Registry, o que no necesitan vinculación de servicios, como IBM Cloud Logs, funcionan aunque el clúster esté en un grupo de recursos diferente. |
Limitaciones de clúster de Red Hat OpenShift on IBM Cloud
Revise las limitaciones específicas de las agrupaciones Red Hat OpenShift. Tenga en cuenta que también se aplican las limitaciones de servicio y de clúster clásico o de clúster de VPC.
Categoría | Descripción |
---|---|
Escalado automático de clústeres | El autoescalador de clúster Red Hat OpenShift desde la consola Red Hat OpenShift Administration > Cluster Settings u objeto ClusterAutoscaler desde la API autoscaling.openshift.io/v1 no es
compatible. En su lugar utilice el plugin de Helm ibm-iks-cluster-autoscaler . |
Actualizaciones de clúster | Debe actualizar el clúster utilizando las herramientas de la API, CLI o consola de Red Hat OpenShift on IBM Cloud. No puede actualizar la versión de clúster de las herramientas de OpenShift Container Platform como, por ejemplo, la consola web de Red Hat OpenShift. |
Registros de contenedor | Si utiliza un operador de registro de contenedor, como por ejemplo Fluentd, para enviar registros a una pila ElasticSearch, debe actualizar el despliegue de registro de clúster para utilizar la clase de almacenamiento de ibmc-block-gold . |
Clústeres privados |
En función del proveedor de infraestructura, las opciones para los clústeres privados son limitadas.
|
Registro | Para configurar una pila de OpenShift Container Platform Elasticsearch, Fluentd, y Kibana(EFK ), consulte la instalación del operador de registro en clúster. |
Catálogo de servicios | El catálogo de servicios no recibe soporte. En su lugar utilice Operadores. No utilice OperatorHub para instalar el catálogo de servicios. |
Red de servicios | El complemento gestionado de Istio no recibe soporte. En su lugar, utilice el operador de malla de servicio Red Hat. Nota: la configuración de IBM Cloud predeterminada de los direccionadores habilita la gestión de redes de host, que no es compatible con la política de gestión de redes de servicios. Para que funcione la entrada de malla de servicios, aplique una política de red. |
Limitaciones de los clústeres clásicos
Los clústeres de infraestructura clásica en Red Hat OpenShift on IBM Cloud se ofrecen con las siguientes limitaciones.
Cálculo
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Instancias reservadas | La capacidad reservada e instancias reservadas no están soportadas. |
Tipos de nodos trabajadores | Los nodos de trabajo están disponibles en determinados tipos de recursos informáticos. |
Acceso a host de nodo de trabajador | Por seguridad, no puede ejecutar SSH en el host de cálculo del nodo de trabajador. |
Redes
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
ALB de Ingress |
|
Equilibradores de carga de red (NLB) |
|
Consola web de Red Hat OpenShift | La consola web no se puede exponer en la red privada en clústeres que tengan puntos finales tanto públicos como privados. Si desea exponer la consola web en la red privada, su clúster no puede tener un punto final público habilitado. |
Solo VLAN privadas | Los equilibradores de carga de red (NLB) privados no se pueden registrar con el servidor de nombres de dominio (DNS), por lo que el clúster no se puede crear con solo una interfaz de red privada. Los nodos trabajadores deben estar conectados a las VLAN públicas y privadas. Puede crear un servicio privado para exponer las apps solo en la red privada. |
Puntos finales de servicio | Cuando crea un clúster, puede habilitar el punto final de servicio de nube pública y privada o solo el punto final de servicio de nube pública, pero no puede habilitar solo el punto final de servicio de nube privada. Después de la creación del clúster, no puede cambiar más adelante los puntos finales de servicio. |
Servicio VPN strongSwan | Consulte Consideraciones sobre el servicio de VPN strongSwan. |
Direcciones IP de servicio | Puede tener 65.000 direcciones IP por clúster en el rango 172.21.0.0/16 que puede asignar a los servicios de Kubernetes dentro del clúster. |
Subredes por VLAN | Cada VLAN tiene un límite de 40 subredes. |
Almacenamiento
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Instancias de volumen | Puede tener un total de 250 archivos de infraestructura de IBM Cloud y volúmenes de almacenamiento en bloque por cuenta. Si monta más de esta cantidad, podría ver un mensaje out of capacity cuando aprovisione volúmenes persistentes.
Para más preguntas frecuentes, consulte los documentos de almacenamiento de archivos y bloques.
Si desea montar más volúmenes, póngase en contacto con IBM Support. En la incidencia de soporte, incluya el ID de cuenta y la nueva cuota de volumen de almacenamiento de archivos
o en bloque que desee. |
Portworx | Revise las limitaciones de Portworx. |
Almacenamiento de archivos | Debido al modo en que el almacenamiento de archivos NFS de IBM Cloud configura los permisos de usuarios de Linux, es posible que reciba errores si utiliza el almacenamiento de archivos. Si es así, es posible que tenga que configurar Red Hat OpenShift Security Context Constraints o utilizar un tipo de almacenamiento diferente. |
Acceso de usuario
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Acceso a direcciones IP | Red Hat OpenShift on IBM Cloud no admite la restricción de acceso para usuarios específicos mediante la habilitación del acceso por dirección IP. Si desea restringir el acceso de los usuarios o restringir a qué servicios y VPC puede acceder un usuario, considere la restricción basada en el contexto. |
Limitaciones de clúster de VPC
Los clústeres de VPC en Red Hat OpenShift on IBM Cloud se publican con las siguientes limitaciones. Además, se aplican todas las cuotas de VPC, límites de VPC subyacentes, las limitaciones de servicio de VPC y las limitaciones de servicio regulares.
Cálculo
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Cifrado | El proveedor de infraestructura de VPC subyacente cifra de forma predeterminada los discos secundarios de los nodos trabajadores en reposo. Sin embargo, no puede llevar su propio cifrado a las instancias de servidor virtual subyacentes. |
Ubicación | Los clusters VPC sólo están disponibles en determinadas regiones multizona. |
Nube privada virtual | Consulte Limitaciones y Cuotas. |
Tipos de nodos trabajadores | Solo están disponibles determinados tipos para máquinas virtuales de nodo trabajador. Las máquinas nativas no reciben soporte. |
Acceso a host de nodo de trabajador | Por seguridad, no puede ejecutar SSH en el host de cálculo del nodo de trabajador. |
Actualizaciones de nodos trabajadores | No se pueden actualizar o recargar los nodos trabajadores de la VPC. En su lugar, puede suprimir el nodo trabajador y volver a equilibrar la agrupación de nodos trabajadores con el mandato ibmcloud oc worker replace . Si
sustituye varios nodos trabajadores al mismo tiempo, se suprimen y se sustituyen simultáneamente, no uno por uno. Asegúrese de que tiene suficiente capacidad en el clúster para volver a planificar las cargas de trabajo antes de sustituir
los nodos trabajadores. |
Redes
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Longitud de URL de app | La resolución DNS está gestionada por el punto final privado virtual (VPE) del clúster, que puede resolver los URL de hasta 130 caracteres. Si expone apps en el clúster con los URL, como por ejemplo el subdominio de Ingress o rutas de Red Hat OpenShift, asegúrese de que los URL sean de 130 caracteres o menos. |
Velocidades de red | Por velocidades de red de perfil de VPC se entiende las velocidades de las interfaces de nodo trabajador. El ancho de banda disponible para las instancias de la VPC se comparte entre el almacenamiento y el tráfico de red. Por defecto, la asignación de almacenamiento es del 25% del ancho de banda máximo. La velocidad de red, como se muestra en las tablas siguientes, es el ancho de banda de red disponible para un trabajador con una única interfaz de red tras deducir la asignación predeterminada del 25% de ancho de banda de almacenamiento. |
NodePort | Solo puede acceder a una app a través de un puerto de nodo si está conectado a la red privada de VPC, por ejemplo a través de una conexión VPN. Para acceder a una app desde Internet, debe utilizar un equilibrador de carga de VPC o un servicio Ingress en su lugar. |
Red de pods | Las listas de control de acceso (ACL) de VPC filtran el tráfico de entrada y de salida del clúster a nivel de subred, y los grupos de seguridad filtran el gráfico de entrada y de salida para el clúster a nivel de nodos trabajadores. Para controlar el tráfico dentro del clúster por pod individual, no puede utilizar ACL ni grupos de seguridad de VPC. En su lugar, utilice Calico y políticas de red de Kubernetes, que pueden controlar el tráfico de red de nivel de pod que utiliza IP en encapsulación IP. |
Pasarela pública | Si el punto final de servicio público está habilitado, debe conectar una pasarela pública a cada subred de VPC para que los nodos trabajadores puedan comunicarse en la red pública. Los componentes predeterminados de Red Hat OpenShift, como la consola web y OperatorHub, tienen que acceder a la red pública. |
Puntos finales de servicio | Cuando crea el clúster de VPC en la consola de IBM Cloud, el clúster tiene un punto final de servicio en la nube público y privado. Si sólo desea un punto final de servicio de nube privada, debe crear el clúster en la CLI e incluir la opción --disable-public-service-endpoint . Si incluyes esta opción, tu cluster se crea con routers y controladores Ingress que exponen tus aplicaciones en la red privada sólo por defecto. Si más adelante desea
exponer apps en una red pública, debe crear manualmente direccionadores públicos y controladores de Ingress. |
Servicio VPN strongSwan | El servicio strongSwan no recibe soporte. Para conectar el clúster a los recursos de una red local o a otra VPC, consulte Utilización de VPN con la VPC. |
Subredes |
|
Equilibrador de carga de VPC | Consulte Limitaciones de equilibrador de carga de VPC. |
Almacenamiento
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Clase de almacenamiento para tamaños de perfil | Para obtener más información, consulte perfiles de volumen disponibles. |
Tipos admitidos | Solo puede configurar IBM Cloud Object Storage y Cloud Databases. |
Archivos adjuntos de volumen | Consulte Límites de conexión de volúmenes. |
Portworx | Revise las limitaciones de Portworx. |
Block Storage for VPC | La clase de almacenamiento por defecto en los clusters VPC no se puede cambiar. Sin embargo, puede crear su propia clase de almacenamiento. |
Acceso de usuario
Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Acceso a direcciones IP | Red Hat OpenShift on IBM Cloud no admite la restricción de acceso para usuarios específicos mediante la habilitación del acceso por dirección IP. Si desea restringir el acceso de los usuarios o restringir a qué servicios y VPC puede acceder un usuario, considere la restricción basada en el contexto. |
Limitaciones de clúster de Satellite
Revise las siguientes limitaciones para clústeres de Red Hat OpenShift on IBM Cloud que cree en una ubicación de Satellite. Tenga en cuenta que también se aplican las limitaciones de servicio.
Categoría | Descripción |
---|---|
Complementos de clúster | Revise los complementos gestionados no soportados para clústeres de Red Hat OpenShift en una ubicación de Satellite. Por ejemplo, el programa de escalado automático de clústeres y el puerto de Istio no reciben soporte. |
Red | -De forma predeterminada, no hay ningún controlador de equilibrador de carga desplegado con clústeres de Satellite y, por lo tanto, los servicios deKubernetes LoadBalancer no se suministran de forma predeterminada. Puede integrar su propia solución de equilibrador de carga en clústeres, como por ejemplo MetalLB. -Los hosts que ejecutan los nodos trabajadores para el clúster deben cumplir los requisitos de red de host y específicos del proveedor, como por ejemplo para AWS, Azure, GCP y IBM Cloud (solo con fines de prueba y demostración). -Puesto que la encapsulación VXLAN es necesaria para el tráfico entre pods que están en distintos nodos trabajadores, las velocidades de transferencia de datos entre pods en distintos nodos trabajadores pueden ser más lentas que la capacidad de red de los hosts. |
Almacenamiento para hosts de nodo trabajador | Consulte Dispositivos conectados y almacenamiento de host. |
Almacenamiento de aplicaciones | De forma predeterminada, no hay ningún proveedor de almacenamiento instalado en los clústeres de Satellite. Por lo tanto, no se configuran clases de almacenamiento de Kubernetes preconfiguradas de forma predeterminada en los clústeres para almacenar los datos de aplicación en un volumen persistente de Kubernetes respaldado por el dispositivo de almacenamiento. Para ver las opciones para configurar un proveedor de almacenamiento, consulte Visión general de plantillas de almacenamiento de Satellite. |
Nodos de trabajador | Los nodos trabajadores se ejecutan en hosts en sus propios entornos de infraestructura. Los hosts deben cumplir los requisitos específicos del proveedor y del host, como por ejemplo
para AWS, Azure, GCP y IBM Cloud (solo fines de pruebas y demostración). Usted es responsable de gestionar el ciclo de vida de la infraestructura de sus hosts, incluyendo la adición y actualización de los nodos trabajadores.
Como tales, operaciones de nodo trabajador como los comandos ibmcloud oc worker add, update, replace, reload no están soportadas. |
Agrupaciones de trabajadores | Para utilizar operaciones como resize , la agrupación de nodos trabajadores utiliza etiquetas de host que deben coincidir con los hosts disponibles (no asignados)
en la ubicación de Satellite. |
Clústeres de un solo nodo | Cualquier clúster con menos de tres nodos trabajadores carece de alta disponibilidad. Al suministrar un clúster de un solo nodo, acepta que es más probable que experimente tiempo de inactividad e interrupciones en la carga de trabajo, y que las actualizaciones regulares de los nodos trabajadores hacen que la carga de trabajo pase a estar fuera de línea. Además, si un clúster se suministra como un clúster de un solo nodo, no se puede convertir posteriormente en un clúster estándar de alta disponibilidad. Puede añadir más nodos, pero los despliegues estándar no aumentan en tamaño de réplica y el clúster no pasa a ser de alta disponibilidad. Los clústeres de nodo único deben ejecutarse en una ubicación Satellite con Red Hat CoreOS(RHCOS)habilitado. Los hosts de plano de control en la ubicación y el host que asigne al clúster de un solo nodo deben ejecutar los sistemas operativos RHEL 8 o RHCOS. Solo está soportado para clústeres de Satellite que ejecutan la versión 4.11 o posterior. OpenShift Data Foundation no está soportado en clústeres de un solo nodo. Portworx no está soportado en clústeres de un solo nodo. |
Operadores y características no soportados en Red Hat OpenShift on IBM Cloud
Los siguientes operadores y características no están soportados en Red Hat OpenShift on IBM Cloud.
En lugar de ajustar el rendimiento del nodo trabajador con los archivos MachineConfig
en Red Hat OpenShift, puede modificar el host con un archivo daemonset
. Para obtener más información, consulte Modificación de la MTU Calico o Ajuste del rendimiento para nodos trabajadores Red Hat CoreOS.
- AMQ Broker
- LTS de AMQ Broker
- AMQ Interconnect
- AMQ Online
- AMQ Streams
- Operador de recursos de plataforma de automatización de Ansible
- API Designer
- Operador de Business Automation
- Camel K
- Operador de gestión de costes
- Operador de cuadrícula de datos
- Gestor de dispositivos
- Operador de integridad de archivos
- Consola de Fuse
- Fuse Online
- Operador de Gatekeeper
- JBoss EAP
- Servidor web de JBoss
- Almacenamiento del gestor de volúmenes lógicos (LVM)
- MachineConfigs
- Servicio SaaS de medición y gestión de costes
- Servicio OpenShift Cloud Manager (OCM) SaaS
- Proxy de clústeres OpenShift
- OpenShift Data Foundation: soportado a través del complemento de clúster para clústeres clásicos y de VPC o a través de la plantilla Satellite para clústeres de Satellite.
- Operador de virtualización de OpenShift
- SDN de OVS y OVN
- Operador de complemento de rendimiento
- Operador de PTP
- Operador de Quay
- Red Hat OpenStack Plataforma
Kuryr
Integración - Red Hat Integration Operator
- Operador del registro de servicios
- Operador de Smart Gateway
- Operador de red SR-IOV: Soportado solo en clústeres Satellite.
- Telemeter and Insights Connected Experience
- Configuración de máquina Windows: los nodos trabajadores con sistemas operativos Windows no están soportados.
ImageContentSourcePolicy
,ImageDigestMirrorSet
, yImageTagMirrorSet
no son compatibles.