¿Qué es Kubernetes?

Kubernetes es una plataforma de código abierto para gestionar cargas de trabajo y servicios contenerizados en múltiples hosts, y ofrece herramientas de gestión para desplegar, automatizar, supervisar y escalar apps contenerizadas con una intervención manual mínima o inexistente. Todos los contenedores que componen el microservicio se agrupan en pods, una unidad lógica para garantizar una gestión y un descubrimiento sencillos. Estos pods se ejecutan en hosts de cálculo que se gestionan en un clúster de Kubernetes portable, ampliable y con resolución automática de problemas en caso de que se produzcan errores.

Para obtener más información sobre Kubernetes, consulte la documentación deKubernetes.

¿Cómo puedo crear un clúster Red Hat OpenShift on IBM Cloud ?

Para crear un clúster Red Hat OpenShift on IBM Cloud, primero decida si desea seguir una guía de aprendizaje para una configuración de clúster básica o diseñar su propio entorno de clúster.

Quiero seguir una guía de aprendizaje

Empiece revisando el documento Cómo empezar y, a continuación, elija una de las guías de aprendizaje disponibles.

Quiero diseñar mi propio entorno de clúster

Empiece revisando la documentación de Cómo empezar y, a continuación, cree la estrategia de entorno de clúster.

¿Cómo funciona Red Hat OpenShift on IBM Cloud?

Con Red Hat OpenShift on IBM Cloud, puede crear su propio clúster de Red Hat OpenShift para desplegar y gestionar apps contenerizadas en IBM Cloud. Las apps contenerizadas se alojan en hosts de cálculo de la infraestructura de IBM Cloud que se denominan nodos trabajadores. Puede optar por aprovisionar sus hosts de computación como máquinas virtuales con recursos compartidos o dedicados, o como máquinas bare metal que pueden optimizarse para el uso de GPU y almacenamiento definido por software (SDS). Los nodos trabajadores se controlan mediante un nodo maestro de Red Hat OpenShift que configura, supervisa y gestiona IBM. Puede utilizar la CLI o la API de IBM Cloud Kubernetes Service para trabajar con los recursos de infraestructura del clúster y la CLI o la API de Kubernetes para gestionar los despliegues y servicios.

Para obtener más información sobre cómo se configuran los recursos del clúster, consulte la Arquitectura del servicio. Para ver una lista de prestaciones y beneficios, consulte Ventajas y ofertas de servicios.

¿Por qué debería utilizar Red Hat OpenShift on IBM Cloud?

Red Hat OpenShift on IBM Cloud es una oferta de Red Hat OpenShift gestionada que proporciona herramientas potentes, una experiencia de usuario intuitiva y seguridad incorporada para una entrega rápida de apps que puede enlazar con servicios en la nube que estén relacionados con IBM Watson®, AI, IoT, DevOps, seguridad y análisis de datos. Como proveedor certificado de Kubernetes, Red Hat OpenShift on IBM Cloud admite la programación inteligente, la autorreparación, el escalado horizontal, el descubrimiento de servicios y el equilibrio de carga, las implementaciones y reversiones automatizadas, así como la gestión de secretos y configuraciones. El servicio tiene también prestaciones avanzadas en torno a la gestión simplificada del clúster, políticas de aislamiento y seguridad de contenedores, la posibilidad de diseñar su propio clúster, y herramientas operativas integradas para mantener la coherencia en el despliegue.

Para obtener una visión general detallada de las prestaciones y beneficios, consulte Ventajas de utilizar el servicio.

¿Qué plataformas de contenedor hay disponibles para mi clúster?

Con IBM Cloud, puede crear clústeres para las cargas de trabajo contenerizadas desde dos plataformas de gestión de contenedores diferentes: la versión de IBM de Kubernetes de comunidad y Red Hat OpenShift on IBM Cloud. La plataforma de contenedor que seleccione se instala en los nodos maestro y trabajador del clúster. Más adelante puede actualizar la versión, pero no puede retrotraer a una versión anterior ni cambiar a otra plataforma de contenedor. Si desea utilizar varias plataformas de contenedor, cree un clúster independiente para cada una de ellas.

Para obtener más información, consulte Comparación entre Red Hat OpenShift y los clústeres de Kubernetes de comunidad.

Kubernetes

Kubernetes es una plataforma de orquestación de contenedores de código abierto y apta para entornos de producción que permite automatizar, escalar y gestionar las aplicaciones en contenedores que se ejecutan en un sistema operativo Ubuntu. Con la versión IBM Cloud Kubernetes Service, obtiene acceso a las funciones de API de Kubernetes de la comunidad que se consideran beta o superior por parte de la comunidad. Las características de Kubernetes alpha, que están sujetas a cambios, generalmente no están habilitadas de forma predeterminada. Con Kubernetes, puede combinar distintos recursos como secretos, despliegues y servicios para crear y gestionar de forma segura apps contenerizadas de alta disponibilidad.

Red Hat OpenShift

Red Hat OpenShift on IBM Cloud es una plataforma basada en Kubernetes diseñada especialmente para acelerar los procesos de entrega de aplicaciones en contenedores que se ejecutan en un sistema operativo Red Hat Enterprise Linux. Puede orquestar y escalar sus cargas de trabajo de Red Hat OpenShift existentes en las nubes locales y externas para lograr una solución híbrida portátil que funcione igual en situaciones en las que haya varias nubes. Para empezar, pruebe la Guía de aprendizaje de Red Hat OpenShift on IBM Cloud.

¿Se proporciona el servicio con nodos trabajadores y un maestro de Red Hat OpenShift gestionado?

Cada clúster de Red Hat OpenShift on IBM Cloud está controlado por un maestro dedicado de Red Hat OpenShift gestionado por IBM en una cuenta de infraestructura de IBM Cloud propiedad de IBM. El nodo maestro de Red Hat OpenShift, incluidos todos los componentes del nodo maestro y los recursos de cálculo, de red y de almacenamiento, están supervisados continuamente por los ingenieros de fiabilidad (SRE) de IBM. Los SRE aplican los estándares de seguridad más recientes, detectan y solucionan actividades maliciosas y trabajan para garantizar la fiabilidad y la disponibilidad de Red Hat OpenShift on IBM Cloud.

Periódicamente, Red Hat OpenShift publica actualizaciones de parche, mayores o menores. Estas actualizaciones pueden afectar a la versión del servidor de API de Red Hat OpenShift o a otros componentes del nodo maestro de Red Hat OpenShift. IBM actualiza automáticamente la versión del parche, pero usted debe actualizar las versiones principales y secundarias del nodo maestro. Para obtener más información, consulte Actualización del nodo maestro.

Los nodos trabajadores de los clústeres estándares se suministran en su cuenta de infraestructura de IBM Cloud. Los nodos trabajadores están dedicados a su cuenta y usted es el responsable de solicitar actualizaciones puntuales para los nodos trabajadores para asegurarse de que el sistema operativo del nodo trabajador y los componentes de Red Hat OpenShift on IBM Cloud aplican las últimas actualizaciones y parches de seguridad. Los ingenieros de fiabilidad del sitio (SRE) de IBM, que supervisan de forma continua la imagen de Linux instalada en los nodos trabajadores para detectar vulnerabilidades y problemas de conformidad de seguridad, ponen a su disposición actualizaciones y parches. Para obtener más información, consulte Actualización de nodos trabajadores.

¿Qué tipos de cargas de trabajo puedo mover a Red Hat OpenShift on IBM Cloud?

Para ver ejemplos de los tipos de cargas de trabajo que los usuarios suelen trasladar a los distintos tipos de nube, consulta « Trasladar tus cargas de trabajo a IBM Cloud ». También podría elegir un enfoque híbrido en el que tenga clústeres en ejecución en ambos entornos.

¿Puedo automatizar los despliegues de mi infraestructura?

Si desea ejecutar la app en varios clústeres, en entornos públicos y privados, o incluso en varios proveedores de nube, quizás se pregunte cómo puede hacer que su estrategia de despliegue funcione en estos entornos.

Puede utilizar la herramienta de código abierto Terraform para automatizar el suministro de la infraestructura de IBM Cloud, incluyendo los clústeres de Kubernetes. Siga esta guía de aprendizaje para crear clústeres de Kubernetes y OpenShift únicos y multizona. Una vez creado un clúster, también se puede configurar el escalador automático de clústeres de Red Hat OpenShift on IBM Cloud para que la agrupación de trabajadores suba o baje los nodos trabajadores en respuesta a las peticiones de recursos de la carga de trabajo.

¿Qué tipo de apps puedo ejecutar? ¿Puedo trasladar apps existentes o tengo que desarrollar nuevas apps?

La app contenerizada debe poder ejecutarse en uno de los sistemas operativos soportados para la versión de clúster. También debe la situación de estado de su app. Para obtener más información acerca de los tipos de apps que se pueden ejecutar en Red Hat OpenShift on IBM Cloud, consulte Planificación de despliegues de apps.

Si ya tiene una app, puede migrarla a Red Hat OpenShift on IBM Cloud. Si desea desarrollar una aplicación nueva, consulte las directrices para desarrollar aplicaciones nativas en la nube sin estado.

¿Qué ocurre con las aplicaciones sin servidor?

Puede ejecutar aplicaciones y trabajos sin servidor a través del servicio IBM Cloud Code Engine. Code Engine también puede crear sus imágenes automáticamente.

¿Qué habilidades debo tener antes de mover mis apps a un clúster?

Red Hat OpenShift se ha diseñado para proporcionar funciones a dos personas principales, el administrador del clúster y el desarrollador de la app. Cada persona utiliza diferentes conocimientos técnicos para ejecutar y desplegar las apps de forma satisfactoria en un clúster.

¿Cuáles son las principales tareas y los conocimientos técnicos que debe tener un administrador de clústeres?

El administrador del clúster es el responsable de configurar, poner en funcionamiento, proteger y gestionar la infraestructura de IBM Cloud para el clúster. Las tareas que suele realizar incluyen las siguientes:

• Dimensionar el clúster para proporcionar suficiente capacidad para las cargas de trabajo.
• Diseñar un clúster que se ajuste a los estándares de alta disponibilidad, recuperación tras desastre y conformidad de la empresa.
• Proteger el clúster mediante la configuración de permisos de usuario y la limitación de las acciones que se pueden realizar dentro del clúster a fin de proteger los recursos de cálculo, la red y los datos.
• Planificar y gestionar la comunicación a través de la red entre los componentes de la infraestructura para garantizar la seguridad de la red, la segmentación y la conformidad.
• Planificar opciones de almacenamiento persistente que satisfagan los requisitos de residencia de datos y de protección de datos.

El administrador del clúster debe tener un amplio conocimiento que incluya cálculo, red, almacenamiento, seguridad y conformidad. Generalmente estos conocimientos se distribuye entre varios especialistas, como ingenieros de sistemas, administradores de sistemas, ingenieros de red, arquitectos de red, gestores de TI o especialistas en seguridad y conformidad. Considere la posibilidad de asignar el rol de administración de clúster a varias personas de la empresa para conseguir los conocimientos necesarios para trabajar correctamente con el clúster.

¿Cuáles son las principales tareas y competencias técnicas de un desarrollador de aplicaciones?

El desarrollador diseña, crea, protege, despliega, prueba, ejecuta y supervisa apps contenerizadas nativas de la nube en un clúster de Red Hat OpenShift. Para crear y ejecutar estas aplicaciones, debes estar familiarizado con el concepto de microservicios, las directrices de las aplicaciones de los 12 factores, los principios de Docker y de contenedorización, así como con las opciones de implementación disponibles en Red Hat OpenShift.

Red Hat OpenShift y Red Hat OpenShift on IBM Cloud ofrecen varias opciones para exponer una app y mantenerla en el ámbito privado, añadir almacenamiento persistente, integrar otros servicios y proteger las cargas de trabajo y los datos confidenciales. Antes de trasladar su aplicación a un clúster de Red Hat OpenShift on IBM Cloud, compruebe que puede ejecutarla como aplicación en contenedor en el sistema operativo compatible y que Red Hat OpenShift y Red Hat OpenShift on IBM Cloud ofrecen las capacidades que necesita su carga de trabajo.

¿Interactúan entre sí los administradores de clústeres y los desarrolladores?

Sí. Los administradores y los desarrolladores del clúster deben interactuar con frecuencia para que los administradores del clúster comprendan los requisitos de la carga de trabajo para proporcionar la capacidad necesaria y para que los desarrolladores conozcan las limitaciones, las integraciones y los principios de seguridad que deben tener en cuenta en el proceso de desarrollo de apps.

¿Qué opciones tengo para proteger mi clúster?

Puede utilizar características de seguridad incorporadas en Red Hat OpenShift on IBM Cloud para proteger los componentes del clúster, los datos y los despliegues de apps para garantizar la conformidad de la seguridad y la integridad de los datos. Utilice estas características para proteger el servidor de API de Red Hat OpenShift, el almacén de datos etcd, el nodo trabajador, la red, el almacenamiento, las imágenes y los despliegues frente a ataques maliciosos. También puede hacer uso de las herramientas incorporadas de registro y supervisión para detectar ataques maliciosos y patrones de uso sospechosos.

Para obtener más información sobre los componentes del clúster y sobre cómo puede cumplir los estándares de seguridad para cada componente, consulte Seguridad para Red Hat OpenShift on IBM Cloud.

¿Qué políticas de acceso debo dar a los usuarios de mi clúster?

Red Hat OpenShift on IBM Cloud utiliza Cloud Identity and Access Management (IAM) para otorgar el acceso a recursos de clúster a través de roles de acceso a la plataforma IAM y políticas de control de acceso basado en roles de Kubernetes (RBAC) a través de roles de acceso al servicio IAM. Para obtener más información sobre los tipos de políticas de acceso, consulta Elige la política de acceso y el rol adecuados para tus usuarios.

¿Cómo puedo rotar la clave API del clúster si hay una fuga?

Para obtener instrucciones sobre cómo rotar su clave API, consulte ¿Cómo rotar la clave API del clúster si hay una fuga?

¿Dónde puedo encontrar una lista de boletines de seguridad que afectan a mi clúster?

Si se encuentran vulnerabilidades en Red Hat OpenShift, Red Hat OpenShift publica CVE en boletines de seguridad para informar a los usuarios y describir las acciones que deben realizar para remediar la vulnerabilidad. Los boletines de seguridad de Red Hat OpenShift que afectan a los usuarios de Red Hat OpenShift on IBM Cloud o a la plataforma IBM Cloud se publican en el boletín de seguridad de IBM Cloud.

Algunos CVE requieren la actualización de parche más reciente de una versión que puede instalar como parte del proceso de actualización de clúster en Red Hat OpenShift on IBM Cloud. Asegúrese de aplicar los parches de seguridad a tiempo para proteger el clúster frente a ataques maliciosos. Para obtener más información sobre lo que incluye un parche de seguridad, consulta el registro de cambios de la versión.

¿Ofrece el servicio soporte para recursos nativos y GPU?

Determinados tipos de nodo trabajador de VPC ofrecen soporte de GPU. Para obtener más información, consulte Tipos de VPC.

Sí, puede suministrar el nodo trabajador como un servidor nativo físico de un solo arrendatario. Los servidores nativos ofrecen grandes beneficios en cuanto a alto rendimiento para cargas de trabajo como datos, GPU e IA. Además, todos los recursos de hardware están dedicados a sus cargas de trabajo, así que no tiene que preocuparse por "vecinos molestos".

Para obtener más información sobre las opciones de bare metal disponibles y en qué se diferencia el bare metal de las máquinas virtuales, consulta la guía de planificación.

¿Cuál es el tamaño mínimo de clúster que puedo crear?

Tenga en cuenta que la ejecución de un clúster mínimo no cumple el acuerdo de nivel de servicio (SLA) para recibir asistencia. Además, tenga en cuenta que algunos servicios, como Ingress, requieren configuraciones de nodo trabajador de alta disponibilidad. Es posible que no pueda ejecutar estos servicios o sus apps en clústeres con sólo dos nodos en una agrupación de nodos trabajadores. Para obtener más información, consulte Planificación del clúster para alta disponibilidad.

Clústeres clásicos o de VPC

Los clústeres siempre deben tener al menos 2 nodos trabajadores. Ten en cuenta que no puedes tener un clúster con 0 nodos de trabajo, y que no puedes desactivar ni suspender la facturación de tus nodos de trabajo.

Clústeres de Satellite

Los clústeres se pueden crear utilizando la topología de réplica única, lo que significa sólo 1 nodo trabajador. Tenga en cuenta que si crea un clúster Satellite utilizando la topología de réplica única, no puede añadir nodos trabajadores más tarde.

¿Qué versiones admite el servicio?

Red Hat OpenShift on IBM Cloud soporta simultáneamente varias versiones de Red Hat OpenShift. Cuando se lanza una nueva versión (n), se admiten las versiones hasta dos anteriores ( n-2 ). Las versiones anteriores a 2 versiones anteriores a la versión más reciente (n-3) son las primeras que quedan en desuso y a las que se deja de dar soporte.

Para obtener más información sobre las versiones compatibles y los pasos que debe seguir para pasar de una versión a otra, consulte la información sobre versiones de Red Hat OpenShift on IBM Cloud.

¿Qué sistemas operativos de nodo trabajador admite el servicio?

Para obtener una lista de los sistemas operados por nodos trabajadores soportados por versión de clúster, consulte la información de versión deRed Hat OpenShift on IBM Cloud.

¿Dónde está disponible el servicio?

Red Hat OpenShift on IBM Cloud está disponible en todo el mundo. Puedes crear clústeres en todas las regiones compatibles con Red Hat OpenShift on IBM Cloud.

Para obtener más información sobre las regiones soportadas, consulte Ubicaciones.

¿Está altamente disponible el servicio?

Sí. De forma predeterminada, Red Hat OpenShift on IBM Cloud configura muchos componentes como, por ejemplo, el maestro de clúster con réplicas, antiafinidad y otras opciones para aumentar la alta disponibilidad (HA) del servicio. Puede aumentar la redundancia y la tolerancia de errores de los nodos trabajadores de clúster, el almacenamiento, la red y las cargas de trabajo configurándolas en una arquitectura de alta disponibilidad. Para obtener una descripción general de la configuración predeterminada y sus opciones para aumentar la HA, consulte Creación de una estrategia de clúster de alta disponibilidad.

Para ver los términos del acuerdo de nivel de servicio de HA más reciente, consulte las condiciones de servicio de IBM Cloud. Por lo general, los términos de disponibilidad de SLA requieren que al configurar los recursos de la infraestructura en una arquitectura de alta disponibilidad, se deben distribuir uniformemente entre tres zonas de disponibilidad diferentes. Por ejemplo, para recibir una cobertura completa de alta disponibilidad según los términos del SLA, debe configurar un clúster multizona con un total de 6 nodos de trabajador como mínimo, dos nodos de trabajador por zona que se distribuyen uniformemente en tres zonas.

¿Cómo funcionan las agrupaciones multizona?

¿Qué ocurre si quiero configurar varios clústeres en distintas regiones?

Puede configurar varios clústeres en distintas regiones de una geolocalización (como EE. UU. sur y EE. UU. este) o entre geolocalizaciones (como, por ejemplo, EE. UU. sur y UE central). Ambas configuraciones ofrecen el mismo nivel de disponibilidad para la app, pero también añaden complejidad cuando se trata de compartición de datos y réplica de datos. En la mayoría de los casos, resulta suficiente permanecer dentro de la misma geolocalización. No obstante, si tiene usuarios en todo el mundo, quizá sea mejor configurar un clúster donde se encuentren los usuarios, de modo que no experimenten tiempos prolongados de espera cuando envíen una solicitud a la aplicación.

¿Qué opciones tengo para equilibrar la carga de trabajo entre varios clústeres?

Para equilibrar la carga de las cargas de trabajo entre varios clústeres, debe poner sus apps a disponibilidad de la red pública mediante Ingress, direccionadores o equilibradores de carga de red (NLB). A los servicios de equilibrador y a los NLB se les asigna una dirección IP pública que puede utilizar para acceder a las apps.

Para equilibrar la carga de trabajo entre las apps, añada las direcciones IP públicas de sus servicios de equilibrador y NLB a un equilibrador de carga global de CIS o a su propio equilibrador de carga global.

¿Qué ocurre si quiero equilibrar la carga de trabajo en la red privada?

IBM Cloud no ofrece un servicio de equilibrador de carga global en la red privada. Sin embargo, puede conectar el clúster a un equilibrador de carga privado situado en la red local utilizando una de las opciones de VPN soportadas. Asegúrese de exponer las apps en la red privada mediante Ingress, direccionadores o equilibradores de carga de red (NLB) y utilice la dirección IP privada en los valores de VPN para conectar la app a la red local.

¿Están los nodos trabajadores y maestro altamente disponibles?

La arquitectura y la infraestructura de Red Hat OpenShift on IBM Cloud están diseñadas para garantizar la fiabilidad, la baja latencia de proceso y un tiempo de actividad máximo del servicio. De forma predeterminada, cada clúster de Red Hat OpenShift on IBM Cloud está configurado con varias instancias del nodo maestro de Red Hat OpenShift para garantizar la disponibilidad y la accesibilidad de los recursos del clúster, incluso si una o varias instancias del nodo maestro de Red Hat OpenShift no están disponibles.

Puede hacer que el clúster esté una disponibilidad incluso mayor y proteger la app del tiempo de inactividad mediante la dispersión de las cargas de trabajo en varios nodos trabajadores de varias zonas de una región. Esta configuración se denomina clúster multizona y garantiza que se pueda acceder a tu aplicación, incluso si un nodo de trabajo o una zona completa no están disponibles.

Para protegerse contra un fallo que afecte a toda una región, cree varios clústeres y distribúyalos entre las regiones de IBM Cloud. Mediante la configuración de un equilibrador de carga de red (NLB) para los clústeres, puede lograr un equilibrio de carga entre regiones y redes entre regiones para los clústeres.

Si tiene datos que deban estar disponibles, incluso si se produce una interrupción, asegúrese de almacenar los datos en almacenamiento persistente.

Para obtener más información sobre cómo conseguir una alta disponibilidad para el clúster, consulte Alta disponibilidad para Red Hat OpenShift on IBM Cloud.

¿Mis aplicaciones se distribuyen automáticamente entre zonas?

Depende de cómo configure la app. Consulte Planificación de despliegues de alta disponibilidad y Planificación de almacenamiento persistente de alta disponibilidad.

¿Están cifrados los nodos de trabajo?

El disco secundario del nodo trabajador está cifrado. Para obtener más información, consulte Visión general del cifrado de clúster. Después de crear una agrupación de nodos trabajadores, puede que observe que el tipo de nodo trabajador contiene .encrypted en el nombre, como por ejemplo b3c.4x16.encrypted.

¿A qué estándares de conformidad cumple el servicio?

IBM Cloud se ha creado siguiendo muchos estándares de datos, finanzas, salud, seguros, privacidad, seguridad, tecnología y otros estándares de conformidad internacional. Para obtener más información, consulte Conformidad de IBM Cloud.

Para consultar los requisitos del sistema detallados, puede generar un informe de compatibilidad de productos de software para Red Hat OpenShift on IBM Cloud. Tenga en cuenta que la conformidad depende el proveedor de infraestructura subyacente para los nodos trabajadores del clúster, la red y los recursos de almacenamiento.

Infraestructura clásica: Red Hat OpenShift on IBM Cloud implementa controles acordes con las siguientes normas de seguridad:

• Certificación EU-US Privacy Shield y Certificación Swiss-US Privacy Shield
• Ley de Responsabilidad y Portabilidad de Seguro Médico (HIPAA)
• Estándares de Service Organization Control (SOC 1 Tipo 2, SOC 2 Tipo 2)
• International Standard on Assurance Engagements 3402 (ISAE 3402), Informes de verificación sobre controles en organizaciones de servicios
• Organización Internacional de Estandarización (ISO 27001, ISO 27017, ISO 27018)
• Estándar de Seguridad de Datos para la Industria de Tarjetas de Pago (PCI DSS)

Infraestructura de VPC: Red Hat OpenShift on IBM Cloud implementa controles acordes con las siguientes normas de seguridad:

• Certificación EU-US Privacy Shield y Certificación Swiss-US Privacy Shield
• Ley de Responsabilidad y Portabilidad de Seguro Médico (HIPAA)
• International Standard on Assurance Engagements 3402 (ISAE 3402), Informes de verificación sobre controles en organizaciones de servicios

Satellite: Consulte la documentación deIBM Cloud Satellite.

¿Puedo utilizar otros servicios de IBM Cloud con mi clúster?

Puede añadir servicios de infraestructura y de plataforma de IBM Cloud, así como servicios de proveedores de terceros al clúster de Red Hat OpenShift on IBM Cloud para habilitar la automatización, mejorar la seguridad o mejorar las funciones de supervisión y registro en el clúster.

Para obtener una lista de servicios admitidos, consulte Integración de servicios.

¿Cómo instalo un Cloud Pak en mi clúster?

Los Cloud Paks están integrados con el catálogo de IBM Cloud para que pueda configurar e instalar rápidamente todos los componentes de Cloud Pak en un clúster de Red Hat OpenShift nuevo o existente. Al instalar el Cloud Pak, se configura el Cloud Pak con Schematics y se crea un espacio de trabajo Schematics para ti. Luego puede utilizar el espacio de trabajo para acceder a la información sobre la instalación del Cloud Pak. Se accede a los servicios del Cloud Pak desde el URL del Cloud Pak. Para más información, consulte la documentaciónCloud Pak.

¿Puedo utilizar la titularidad de Red Hat OpenShift que viene con mi Cloud Pak para mi clúster?

Sí, si el Cloud Pak incluye una titularidad para ejecutar determinados tipos de nodo trabajador que se instalan con OpenShift Container Platform. Para consultar tus derechos de acceso, visita IBM Passport Advantage. Tenga en cuenta que el ID de IBM Cloud debe coincidir con el ID de IBM Passport Advantage.

Puede crear el clúster o el grupo de trabajadores dentro de un clúster existente con el derecho Cloud Pak en la consola o utilizando la opción --entitlement ocp_entitled en los comandos de la CLI ibmcloud oc worker-pool create classic ibmcloud oc cluster create classic o. Asegúrese de especificar el número y el tipo correctos de nodos trabajadores que tiene derecho a utilizar.

No supere la titularidad. Tenga en cuenta que las titularidades de plataforma de contenedor de OpenShift se pueden utilizar con otros proveedores de nube o en otros entornos. Para evitar problemas de facturación posteriores, asegúrese de utilizar solo lo que tiene derecho a utilizar. Por ejemplo, supongamos que tiene una titularidad para las licencias de OCP para dos nodos trabajadores de 4 CPU y 16 GB de memoria y crea esta agrupación de nodos trabajadores con dos nodos trabajadores de 4 CPU y 16 GB de memoria. Ha utilizado la titularidad completa, y no puede utilizar la misma titularidad para otras agrupaciones de trabajadores, proveedores de nube o entornos.

¿Puedo instalar varios Cloud Paks en el mismo clúster de Red Hat OpenShift on IBM Cloud ?

Sí, pero es posible que tenga que añadir más nodos trabajadores para que cada Cloud Pak tenga suficientes recursos de cálculo para ejecutarse. Además, puede instalar sólo una instancia del mismo Cloud Pak por clúster, como por ejemplo Cloud Pak for Data; o varias instancias en distintos proyectos en el mismo clúster, como por ejemplo Cloud Pak for Automation. Para obtener información sobre el dimensionamiento, consulte la documentación deCloud Pak.

¿Qué se incluye en un Cloud Pak?

Los Cloud Paks constituyen software empaquetado, con licencia y contenerizado que está optimizado para que funcionen juntos en distintas áreas de una empresa, lo que incluye un despliegue coherente, control de accesos y facturación. Puede utilizar de forma flexible partes de los Cloud Paks cuando lo necesite, eligiendo la combinación adecuada de núcleos de procesador virtuales del software que mejor se adapte a sus cargas de trabajo. También puede modificar la combinación de núcleos de procesador virtual a medida que evolucionen sus cargas de trabajo.

En función del Cloud Pak, recibe software de código abierto con licencia de IBM empaquetado para poderlo gestionar de forma unificada en lo referente a registro, supervisión, seguridad y funciones de acceso.

• IBM Productos: Los Cloud Paks amplían el software y el middleware con licencia de IBM disponibles en IBM Marketplace, e integran estos productos con su clúster para modernizar, optimizar y ejecutar cargas de trabajo en la nube híbrida.
• Software de código abierto: los Cloud Paks también pueden incluir componentes de código abierto para soluciones nativas de la nube y portátiles de nube híbrida. Normalmente, el software de código abierto no está gestionado y usted es el responsable de mantener los componentes actualizados y protegidos. No obstante, los Cloud Paks le ayudan a gestionar el ciclo de vida completo de los componentes del Cloud Pak y las cargas de trabajo que se ejecutan en los mismos. Dado que el software de código abierto se incluye junto con la plataforma Cloud Pak, se benefician del soporte técnico de IBM y de la integración con determinadas funciones de IBM Cloud, como el control de acceso y la facturación.

Para ver los componentes de cada Cloud Pak, consulta la documentación de Cloud Pak.

¿Qué más debo saber para utilizar Cloud Paks?

Cuando configure Cloud Pak, es posible que tenga que trabajar con recursos específicos de Red Hat OpenShift, como restricciones de contexto de seguridad. Asegúrese de utilizar la CLI de oc o la CLI de kubectl versión 1.12 para interactuar con estos recursos, como por ejemplo oc get scc. La CLI de kubectl versión 1.11 tiene un problema que genera un error cuando se ejecutan mandatos sobre recursos específicos de Red Hat OpenShift, como kubectl get scc.

¿IBM admite las herramientas de terceros y de código abierto que utilizo con mi clúster?

Consulta la política de código abierto y de terceros de IBM.

¿Qué se me facturará? ¿Puedo estimar y controlar los costes de mi clúster?

Consulte Gestión de costes para los clústeres.

¿Puedo degradar mi clúster a una versión anterior?

No, no puede degradar el clúster a una versión anterior.

¿Puedo mover mi clúster actual a una cuenta diferente?

No, no puede mover el clúster a una cuenta diferente de la que se ha creado.

¿Cómo puedo mantener mi clúster en estado soportado?

• Asegúrese de que el clúster siempre ejecute una versión de Red Hat OpenShift soportada.
• Cuando se libera una nueva versión menor de Red Hat OpenShift, una versión anterior está en desuso poco después y a continuación pasa a ser no soportada.

Para obtener más información, consulte Actualización del nodo maestro y nodos trabajadores.

¿Qué operaciones están bloqueadas si mi clúster está ejecutando un sistema operativo no soportado?

Las operaciones siguientes se bloquean cuando un sistema operativo no está soportado:

• recarga de trabajador
• sustitución de trabajador sin actualización
• sustitución de trabajador por actualización
• actualización de trabajador
• creación de agrupación de nodos trabajadores (con un sistema operativo no soportado)
• reequilibrio de agrupación de trabajadores
• redimensionamiento de la agrupación de trabajadores (escalado hacia arriba)
• añadir zona de agrupación de nodos trabajadores
• cambio de tamaño del grupo de instancias (parche)
• autoscaler eliminar trabajador ( v2/autoscalerRemoveWorker )

¿Cuánto cuestan los contenedores confidenciales?

IBM no cobra suplementos por los contenedores confidenciales. El coste sigue siendo el mismo para el servicio y las tarifas VSI estándar por cada vaina confidencial que se inicie como VSI con las tarifas estándar de IBM Cloud.

¿Puedo construir mi propio CVM (podvm) para contenedores confidenciales?

Sí. La dirección ConfigMap puede configurarse para que apunte a una Máquina Virtual Confidencial (MVC) que usted haya configurado. IBM no proporciona soporte para construir el suyo propio. Crear una imagen por ti mismo puede introducir problemas en los que el soporte de IBM no puede ayudarte.

¿Qué debo utilizar como fideicomisario en los contenedores confidenciales?

Para el desarrollo, basta con ejecutar un administrador simple en Docker / Podman en VM. Estos contenedores también pueden configurarse directamente en OpenShift. Sin embargo, dado que el administrador es el garante de la seguridad del entorno, no utilices un administrador dentro del clúster OpenShift, que se supone que no es de confianza.

Para producción, utilice Intel Trust Authority y configure INITDATA para que utilice Intel Trust Authority. Debe permitir que su clúster se comunique con Intel, como grupos de seguridad, seguro por defecto OpenShift permisos, y así sucesivamente.

¿Dónde puedo obtener ayuda para los contenedores confidenciales?

OpenShift Sandboxed Containers Operator en Red Hat OpenShift on IBM Cloud es compatible tanto con Red Hat como con IBM. Utilice los canales de asistencia estándar para ambos servicios. Si su OpenShift tiene licencia a través de IBM Cloud, póngase en contacto con IBM. Si trae sus propias licencias de OpenShift de Red Hat, puede ponerse en contacto con Red Hat.

¿Cuántos pods pares puedo ejecutar por nodo trabajador?

El número de pods pares que puede ejecutar por nodo trabajador está controlado por múltiples límites:

1. PEERPODS_LIMIT_PER_NODE configuración: Este límite configurable en peer-pods-cm ConfigMap controla el número máximo de VSI de pod de pares que se pueden programar por nodo trabajador. El valor predeterminado es 10. Puede aumentar este valor, pero también debe tener en cuenta las demás restricciones que se indican a continuación.

2. Kubernetes límite de pods: Kubernetes limita el número total de pods por nodo en función del número de vCPUs (10 pods por vCPU ). Por ejemplo, un nodo trabajador de 16x64 puede soportar hasta 110 pods. Dado que cada pod de pares está respaldado por una construcción de pod Kubernetes en el nodo trabajador, este límite se aplica aunque la carga de trabajo real se ejecute en una VSI independiente.

3. CPU y memoria del nodo trabajador: Cada pod peer consume aproximadamente 250m CPU y 120Mi memoria en el nodo trabajador para la construcción del pod Kubernetes. Debe asegurarse de que sus nodos trabajadores tienen suficiente CPU y memoria para soportar el número deseado de pods pares.

Para aumentar el valor de PEERPODS_LIMIT_PER_NODE:

1. Actualizar el peer-pods-cm ConfigMap en el espacio de nombres openshift-sandboxed-containers-operator. Para más información, consulte Creación de contenedores confidenciales.

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'
   

2. Reinicie el conjunto de demonios del adaptador de API de nube.

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. Compruebe que se aplica el nuevo límite.

   oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'
   

Al calcular el valor óptimo de PEERPODS_LIMIT_PER_NODE, tenga en cuenta el perfil de su nodo trabajador. Por ejemplo, con un nodo trabajador 16x64 (16 vCPUs ), el máximo teórico basado sólo en la CPU sería de aproximadamente 24 peer pods por nodo (suponiendo 250m CPU por peer pod y teniendo en cuenta otros procesos del sistema). Sin embargo, también está restringido por el límite de pods de Kubernetes de 110 pods por nodo.

¿Qué significa el error Insufficient kata.peerpods.io/vm?

Si aparece un error como el siguiente al programar pods de pares:

Warning FailedScheduling 0/30 nodes are available: 9 Insufficient kata.peerpods.io/vm. preemption: 0/30 nodes are available: 9 No preemption victims found for incoming pod.

Este error indica que has alcanzado el límite de PEERPODS_LIMIT_PER_NODE en tus nodos trabajadores. El recurso kata.peerpods.io/vm representa el número de ranuras de pods de pares disponibles en cada nodo trabajador.

Para resolver este problema:

1. Comprueba el límite de corriente y la asignación.

   oc get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable["kata.peerpods.io/vm"], capacity: .status.capacity["kata.peerpods.io/vm"]}'
   

2. Compruebe cuántos pods de pares se están ejecutando actualmente.

   oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l
   

3. Aumente el valor de PEERPODS_LIMIT_PER_NODE como se describe en ¿Cuántos pods pares puedo ejecutar por nodo trabajador?

4. Como alternativa, añada más nodos trabajadores a su clúster para aumentar la capacidad total.

¿Pueden los contenedores confidenciales cumplir normas de seguridad específicas, como la NIST 800-53 R5?

¿Por qué me aparece un error de autenticación de IAM tras actualizar a OpenShift Sandboxed Containers Operator 1.12.1?

Tras actualizar a la versión 1.12.1 del operador de contenedores en entorno aislado de OpenShift, es posible que aparezca un error similar al siguiente en los registros del adaptador de API en la nube (CAA):

cloud-api-adaptor: cluster error with:
 Unauthorized
further details:
 {
    "StatusCode": 401,
    "Result": {
        "code": "A0007",
        "description": "You do not have the correct permissions to perform this action..."
    }
}

Este error se produce porque la versión 1.12.1 introdujo un nuevo requisito para obtener automáticamente el grupo de seguridad del clúster a través de la API del servicio de clústeres IKS de IBM Cloud. Al utilizar « IBMCLOUD_IAM_PROFILE_ID » para la autenticación (identidad del recurso de computación), es posible que el perfil de IAM no disponga de los permisos necesarios para consultar la API del servicio del clúster.

Para resolver este problema, elija una de las siguientes opciones:

1. Conceder permisos adicionales de IAM (recomendado): Actualiza el perfil de IAM para incluir permisos para la API del servicio del clúster IKS, concretamente la capacidad de llamar a GetClusterTypeSecurityGroups(). Ponte en contacto con el administrador de IBM Cloud para que te conceda los permisos necesarios.

2. Establecer explícitamente el ID del grupo de seguridad: Configurar la variable de entorno « IBMCLOUD_VPC_SG_ID » en el archivo « peer-pods-cm » ( ConfigMap ) para omitir la búsqueda automática del grupo de seguridad del clúster:

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"IBMCLOUD_VPC_SG_ID":"<your-security-group-id>"}}'
   

   A continuación, reinicia el daemonset del adaptador de la API en la nube:

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. Utiliza la autenticación mediante clave API: cambia de la autenticación IBMCLOUD_IAM_PROFILE_ID a la IBMCLOUD_API_KEY, que suele ofrecer permisos más amplios. Actualiza el secreto « peer-pods-secret » con tu clave de API en lugar de utilizar el perfil de IAM.

Para obtener más información sobre los cambios de la versión 1.12.1, consulta la confirmación del proyecto original cloud-api-adaptor en dde66055.

Póngase en contacto con su equipo de IBM para hablar de intereses de seguridad específicos.

¿Cuál es la zona horaria por defecto de mis nodos trabajadores de la VPC?

A partir de la versión de parche 4.16.56_1602, publicada el 27 de enero de 2026, todos los parches futuros para clusters VPC establecen la hora local del nodo trabajador en UTC.