Consideraciones de implementación de OpenShift: arquitectura, automatización e integraciones

OpenShift vs. Kubernetes: Resumen de las conclusiones clave de la implementación

La siguiente tabla resume la experiencia de implementación de OpenShift y Kubernetes, destacando las diferencias clave en la configuración, los requisitos previos y la gestión posterior a la implementación. 

OKD: El proyecto upstream de OpenShift

OKD, anteriormente conocido como OpenShift Origin, es el proyecto upstream impulsado por la comunidad que impulsa Red Hat OpenShift. Incluye todos los componentes esenciales necesarios para ejecutar Kubernetes y los optimiza para el desarrollo e implementación continuos de aplicaciones.

A diferencia de OpenShift, un producto reforzado y listo para la empresa, OKD funciona como centro de innovación donde la comunidad presenta y prueba nuevas funciones antes de perfeccionarlas para su adopción empresarial. Red Hat OpenShift. Como resultado, OKD suele estar varias versiones por delante de OpenShift, lo que ofrece acceso anticipado a capacidades de vanguardia.

OKD es ideal para desarrolladores que desean experimentar con los últimos avances en orquestación de contenedores antes de que lleguen a las versiones estables de OpenShift. Sin embargo, dado que carece de... Red HatGracias a sus certificaciones de seguridad y soporte comercial, OKD es el más adecuado para pruebas, desarrollo y entornos donde el apoyo de la comunidad es suficiente.

OKD es donde evoluciona el ecosistema OpenShift, mientras que OpenShift en sí mismo ofrece una plataforma pulida y de nivel de producción para las empresas.

Motor de virtualización OpenShift

Red Hat También ofrece otra variante de OpenShift, la Motor de virtualización OpenShift, una edición especializada para ejecutar máquinas virtuales. Optimiza la gestión de máquinas virtuales al eliminar funciones no relacionadas, lo que ofrece a los equipos una solución específica para las cargas de trabajo de virtualización. 

Virtualización OpenShift aprovecha el KVM hipervisor, un módulo de virtualización en el kernel de Linux que permite que el kernel funcione como un hipervisor de tipo 1. Es una tecnología madura que principales proveedores de nube utilizarlo como backend de virtualización para sus ofertas de infraestructura como servicio (IaaS). 

La virtualización de OpenShift utiliza el hipervisor KVM para permitir que Kubernetes y KubeVirt Para administrar las máquinas virtuales, estas utilizan la infraestructura de programación, red y almacenamiento de OpenShift.

Opciones de instalación de OpenShift: servicios autogestionados vs. servicios gestionados

OpenShift ofrece múltiples modelos de implementación para adaptarse a diferentes necesidades operativas, desde control total hasta gestión directa. A continuación, comparamos OpenShift autogestionado (instalado localmente o en la nube) con los servicios OpenShift gestionados.

Implementación autogestionada de OpenShift

La plataforma de contenedores OpenShift ofrece diversas opciones para implementar un clúster en cualquier infraestructura. Existen cuatro métodos de implementación principales, cada uno de los cuales proporciona una infraestructura de alta disponibilidad; la elección correcta depende de los escenarios de uso específicos:

• Instalador asistido: Esta es la forma más sencilla de implementar un clúster, ya que ofrece una interfaz web intuitiva y es ideal para redes con acceso a Internet público. También ofrece valores predeterminados inteligentes, comprobaciones previas al vuelo y una API REST para automatización. El instalador asistido genera una imagen de descubrimiento que se utiliza para arrancar las máquinas del clúster. 
• Instalación basada en agente: Este enfoque requiere configurar un agente local y la configuración a través de la línea de comandos; es más adecuado para redes desconectadas o restringidas.
• Instalación automatizada: Este método implementa una infraestructura proporcionada por el instalador mediante el controlador de administración de la placa base en cada host del clúster. Funciona tanto en entornos conectados como desconectados.
• Instalación de control total: Este enfoque es ideal si desea un control total de la infraestructura subyacente que aloja los nodos del clúster. Admite entornos conectados y desconectados y ofrece la máxima personalización mediante la implementación de una infraestructura preparada y mantenida por el usuario.

El enfoque del instalador automatizado generalmente se asocia con la infraestructura provista por el instalador (IPI), mientras que los otros métodos generalmente se asocian con la infraestructura provista por el usuario (UPI).

A continuación se muestra una descripción general de alto nivel de la instalación del clúster.

Implementaciones de OpenShift administradas

Si prefiere no lidiar con dolores de cabeza de infraestructura, Red HatVale la pena considerar las opciones de OpenShift administrado. Servicios como OpenShift Dedicated (ROSA) en AWS o Azure. Red Hat OpenShift (ARO) se encarga del trabajo pesado.Red Hat Y el proveedor de la nube se encarga de la configuración, el mantenimiento y los parches de seguridad del clúster. Esto permite que los equipos se concentren por completo en el desarrollo y la implementación de aplicaciones. 

Por supuesto, existen algunas desventajas. Si bien los servicios administrados ofrecen comodidad y monitorización integrada, tendrá menos control que al gestionar sus clústeres de OpenShift. El precio depende de su proveedor de nube, pero la menor carga operativa justifica los costos de muchas empresas. 

Estas soluciones son ideales para empresas que necesitan Kubernetes listo para producción sin tener que crear un equipo interno de plataforma. Las principales plataformas en la nube que ofrecen este servicio se muestran en la tabla a continuación.

Comparación de implementaciones de OpenShift autogestionadas y gestionadas

La siguiente tabla describe las diferencias entre las implementaciones de OpenShift administradas y autoadministradas.

Paso a paso: Azure Red Hat Implementación de OpenShift

El siguiente tutorial cubre las etapas esenciales para configurar una instancia de Azure Red Hat Implementación de OpenShift (ARO).

Requisitos previos

El clúster ARO se puede crear mediante la CLI de Azure o el portal de Azure. El uso de la consola de Azure ofrece una ventaja significativa para la recuperación ante desastres, ya que permite a los clientes obtener un archivo de configuración de instalación que puede servir como modelo para recrear un clúster ARO con la misma configuración de forma precisa. Esta capacidad resulta extremadamente útil en escenarios donde los clientes, conscientes del costo, optan por no mantener un clúster de recuperación ante desastres en funcionamiento continuo. Por ejemplo, en caso de una recuperación ante desastres, un cliente puede usar este archivo guardado para aprovisionar un nuevo clúster ARO rápidamente e implementarlo inmediatamente después. trilioEste proceso se puede acelerar aún más mediante la automatización, dirigiéndolo al destino de respaldo de la aplicación, y luego se puede comenzar la tarea crítica de restaurar las cargas de trabajo en una secuencia priorizada.

La siguiente guía se centra en la creación de un clúster mediante la CLI de Azure, que se puede instalar siguiendo las instrucciones aqui. 

La implementación de ARO requiere un mínimo de 44 núcleos de CPU para poner en marcha un nuevo clúster. Esto suele superar las cuotas predeterminadas de Azure para nuevas suscripciones. Si los límites actuales de su cuenta de Azure son demasiado bajos, deberá enviar una solicitud. solicitud de aumento de cuota específicamente para vCPU de VM antes de continuar.

Así es como se asignan esos núcleos durante la instalación:

• Nodos de arranque: 8 núcleos alimentan la máquina de arranque temporal.
• Plano de control: 24 núcleos están dedicados a los nodos del plano de control.
• Nodos de trabajo: 12 núcleos son para cargas de trabajo computacionales.

Una vez finalizada la instalación, la máquina de arranque desaparece, lo que reduce el uso del núcleo a 36.

De forma predeterminada, la instalación del clúster crea tres nodos del plano de control y tres nodos de trabajo. Este es el número mínimo de nodos necesario para que el clúster sea compatible con Microsoft y Red HatReducir el tamaño del clúster a una configuración inferior a esta infringiría el acuerdo de soporte. Se admite un máximo de 250 nodos de trabajo.

Para acceder al clúster después de la instalación, asegúrese de descargar la versión de OpenShift CLI (oc) deseada desde aqui.

De forma predeterminada, la instalación de ARO utiliza el tamaño de máquina virtual estándar D8s_v5 para los nodos de control y el estándar D4s_v5 para los nodos de trabajo. Puede usar el siguiente comando para comprobar los núcleos disponibles para la familia de máquinas virtuales estándar DSv5 en la región Este de EE. UU.:

UBICACIÓN=eastus az vm list-usage -l $UBICACIÓN --consulta "[?contiene(nombre.valor, 'standardDSv5Family')]" --tabla de salida

Antes de crear la implementación de ARO, debe configurar la infraestructura de red y verificar sus permisos de acceso. La implementación requiere lo siguiente:

• Configuración del grupo de recursos:Creará un grupo de recursos dedicado que contenga la red virtual del clúster.
• Permisos requeridosNecesitará los permisos que se muestran en la tabla a continuación para implementar el clúster.

Registro de proveedores de recursos

Antes de continuar con la implementación del clúster, debe registrar los siguientes proveedores de recursos esenciales en su suscripción de Azure:

• Microsoft.RedHatOpenShift
• Microsoft.Compute
• Microsoft.Almacenamiento
• Microsoft.Autorización

Si su cuenta tiene varias suscripciones de Azure, especifique el identificador de suscripción correspondiente:

conjunto de cuentas az --suscripción

Puede comprobar si un proveedor de recursos en particular está actualmente registrado en su cuenta.

Lista de proveedores az --consulta "[?namespace==''].registrationState" --tabla de salida

Si los proveedores de recursos no están registrados, puede registrarlos de la siguiente manera:

az proveedor registro --namespace Microsoft.RedHatOpenShift --wait az proveedor registro --namespace Microsoft.Compute --wait az proveedor registro --namespace Microsoft.Storage --wait az proveedor registro --namespace Microsoft.Authorization --wait

Luego puede verificar que los proveedores de recursos se hayan registrado utilizando los siguientes comandos:

az provider list --query "[?namespace=='Microsoft.RedHatOpenShift'].registrationState" --tabla de salida az provider list --query "[?namespace=='Microsoft.Compute'].registrationState" --tabla de salida az provider list --query "[?namespace=='Microsoft.Storage'].registrationState" --tabla de salida az provider list --query "[?namespace=='Microsoft.Authorization'].registrationState" --tabla de salida

Descargar un secreto de extracción

El secreto de extracción permite que su clúster acceda Red Hat registros de contenedores y extraer imágenes de ellos. Puede descargar el secreto de extracción de su clúster navegando a portal del administrador de clústeres. Seleccione Descargar el secreto de extracción y descargue un secreto de extracción para utilizarlo con su implementación de ARO. 

Aunque configurar el secreto de extracción durante la creación del clúster es opcional, se recomienda incluir este paso.

Creación de grupos de recursos

Si ya existen redes virtuales en su cuenta, puede usarlas en su implementación de ARO. También puede crear una nueva red virtual para su implementación de ARO. En este caso, crearemos una nueva red virtual para nuestra implementación de ARO. Las siguientes variables deben configurarse en el entorno del shell.

LOCATION=eastus # la ubicación de su clúster RESOURCEGROUP=aro-rg # el nombre del grupo de recursos #donde desea crear su clúster CLUSTER=cluster # el nombre de su clúster VIRTUALNETWORK=aro-vnet # el nombre de la red virtual

Los grupos de recursos actúan como contenedores lógicos para organizar y administrar sus servicios de Azure. Al crear uno, deberá seleccionar una ubicación geográfica con dos propósitos:

• Almacena metadatos sobre el grupo
• Se convierte en la región de implementación predeterminada para los recursos contenidos (a menos que se anule)

Se puede crear un grupo de recursos utilizando el siguiente comando:

az group create --name $RESOURCEGROUP --location $LOCATION

El proceso de implementación de ARO creará automáticamente un segundo grupo de recursos administrados para albergar los recursos de infraestructura del clúster, como máquinas virtuales, almacenamiento y componentes de red. No se permite modificar ni eliminar recursos dentro de este grupo, ya que esto puede desestabilizar el clúster.

Es importante señalar que no todas las regiones de Azure admiten Red Hat Implementaciones de OpenShift. Asegúrate de elegir entre las regiones disponibles antes de crear el grupo de recursos.

Creación de redes virtuales y subredes

Cree una nueva red virtual en el grupo de recursos creado en el paso anterior:

az network vnet create --resource-group $RESOURCEGROUP --name VIRTUALNETWORK --address-prefixes 10.10.0.0/21

A continuación, cree dos subredes vacías para el plano de control y los nodos de trabajo.

az network vnet subnet create --resource-group $RESOURCEGROUP --vnet-name $VIRTUALNETWORK --name master-subnet --address-prefixes 10.10.0.0/21 az network vnet subnet create --resource-group $RESOURCEGROUP --vnet-name $VIRTUALNETWORK --name worker-subnet --address-prefixes 10.0.2.0/21

Para obtener más información sobre las opciones de red en ARO, consulte esta guía.

Modificar las opciones predeterminadas 

Puede modificar el comando de creación de clúster según las siguientes opciones:

• Red Hat acceso al registro: Pase el secreto de extracción para acceder a las imágenes de los registros de RedHat (–pull-secret @pull-secret.txt).
• Configuración de dominio personalizado: Puede crear un dominio personalizado para su clúster siguiendo las instrucciones aquiUtilice el indicador “–domain” para especificar su dominio.
• Ajustes de tamaño de VM: Los tamaños predeterminados de máquina virtual para el plano de control y los nodos de trabajo son Standard D8s_v5 y Standard D4s_v5, respectivamente. Si necesita crear una máquina virtual de un tamaño diferente, puede usar las siguientes opciones:
  • –master-vm-size Estándar_D8s_v3
  • –worker-vm-size Estándar_D4s_v3
• Especificación de la versión: Puede seleccionar una versión específica de ARO al implementar su clúster. Primero puede comprobar las versiones disponibles:

az aro get-versions --ubicación

Creando el cluster

Una vez finalizados todos estos detalles, puedes proceder a crear tu cluster de la siguiente manera:

az aro create --resource-group $RESOURCEGROUP --name $CLUSTER --vnet $VIRTUALNETWORK --master-subnet subred-maestra --worker-subnet subred-trabajador --pull-secret @pull-secret.txt

Accediendo al cluster

Una vez completada la implementación del clúster, podrá conectarse a él con el usuario predeterminado "kubeadmin". Puede recuperar la URL de la consola del clúster y las credenciales de la siguiente manera:

az aro list-credentials --name $CLUSTER --resource-group $RESOURCEGROUP az aro show --name $CLUSTER --resource-group $RESOURCEGROUP --query "consoleProfile.url" --output tsv

Para acceder al clúster mediante el comando “oc”, recupere el punto final de la API mediante el siguiente comando:

apiServer=$(az aro show --resource-group $RESOURCEGROUP --name $CLUSTER --query apiserverProfile.url --output tsv)

Luego puede iniciar sesión en la API del clúster de la siguiente manera:

oc login $apiServer --nombre de usuario kubeadmin --contraseña

Para obtener una lista completa de las configuraciones admitidas y las restricciones, consulte la página oficial Azure Red Hat Política de soporte de OpenShift.

Comprobación del estado del clúster

El oc El comando CLI permite verificar que el clúster esté funcionando correctamente. Los siguientes comandos proporcionan una comprobación básica del estado de los componentes principales del clúster.

Primero, asegúrese de que el plano de control (maestro) y los nodos de trabajo estén todos en ejecución y en estado Listo.

oc obtener nodos

El siguiente comando permite comprobar el estado de los operadores principales del clúster. Estos operadores gestionan los componentes fundamentales de la plataforma OpenShift. Un clúster en buen estado mostrará todos los operadores con "AVAILABLE" como "Verdadero" y "PROGRESSING" como "Falso", sin operadores degradados.

oc obtiene operadores de clúster

Verifique el estado de los pods del clúster central; todos deben estar en buen estado.

oc obtener pods --todos los espacios de nombres

Escalado de nodos de trabajo

Podemos agregar nodos de trabajo al clúster según nuestras necesidades mediante conjuntos de máquinas. Para determinar la configuración actual, examine los conjuntos de máquinas existentes en el clúster. El siguiente comando muestra el número de nodos del plano de control y nodos de trabajo, los tipos de nodo asociados y la región/zona donde están implementados.

oc obtener máquina -n openshift-machine-api

Esta operación de escalado se puede realizar mediante la interfaz de línea de comandos (CLI) o directamente desde la consola web de OpenShift. Desde la terminal, un administrador puede ejecutar un comando para escalar de forma imperativa un conjunto de máquinas específico a dos réplicas, aumentando así el número total de nodos de trabajo en uno. Dado que cada conjunto de máquinas suele estar vinculado a una zona de disponibilidad específica, y el estado inicial es de tres conjuntos de máquinas con una máquina cada uno, escalar un conjunto de máquinas a dos máquinas da como resultado un total de cuatro nodos de trabajo en el clúster. Ejecute el siguiente comando para escalar el conjunto de máquinas deseado y aumentar el número de nodos de trabajo a cuatro.

escala oc --replicas=2 conjunto de máquinas -n openshift-machine-api

Apagando el cluster

El clúster se puede apagar para ahorrar costos. Para apagarlo correctamente, ejecute el siguiente comando.

para el nodo en $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); hacer oc debug node/${node} -- chroot /host shutdown -h 1; hecho

Eliminar el clúster

Al eliminar un clúster, se eliminan todos los objetos administrados. Sin embargo, recursos como el grupo de recursos, la red virtual y las subredes deben eliminarse manualmente.

inicio de sesión az

Seleccione el ID de suscripción que desea utilizar.

conjunto de cuentas az --subscription {ID de suscripción}

Reemplace lo siguiente con los valores utilizados para crear el clúster, luego ejecute el comando para eliminar el clúster.

GRUPO DE RECURSOS= CLÚSTER= az aro delete --grupo-de-recursos $GRUPODERECURSO --nombre $CLÚSTER

Ejecute el siguiente comando para eliminar el grupo de recursos.

eliminar grupo az --nombre $RESOURCEGROUP

El proceso de implementación de ARO también se puede automatizar mediante la colección de Azure en Ansible. El siguiente manual de estrategias puede usarse como ejemplo para la implementación de ARO. Puede encontrar más información sobre el uso de Ansible para la implementación de ARO. aqui.

- nombre: Crear clúster de OpenShift azure_rm_openshiftmanagedcluster: grupo de recursos: "myResourceGroup" nombre: "myCluster" ubicación: "eastus" perfil de clúster: id de grupo de recursos de clúster: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/clusterResourceGroup" dominio: "mydomain" perfil principal de servicio: id de cliente: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" secreto de cliente: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" perfil de red: pod_cidr: "10.128.0.0/14" cidr de servicio: "172.30.0.0/16" perfiles de trabajador: - nombre: trabajador tamaño de máquina virtual: "Standard_D4s_v3" id de subred: "/subscriptions/xx-xx-xx-xx-xx/resourceGroups/myResourceGroup/Microsoft.Network/virtualNetworks/myVnet/subnets/worker" tamaño de disco: 128 recuento: 3 perfil maestro: tamaño de máquina virtual: "Standard_D8s_v3" id de subred: "/subscriptions/xx-xx-xx-xx-xx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/master" - nombre: Crear un clúster de OpenShift con varios parámetros azure_rm_openshiftmanagedcluster: grupo de recursos: "myResourceGroup" nombre: "myCluster" ubicación: "eastus" perfil de clúster: id de grupo de recursos de clúster: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/clusterResourceGroup" dominio: "mydomain" fips_validated_modules: Habilitado service_principal_profile: client_id: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" client_secret: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" network_profile: pod_cidr: "10.128.0.0/14" service_cidr: "172.30.0.0/16" outbound_type: Loadbalancer preconfigured_nsg: Deshabilitado worker_profiles: - name: worker vm_size: "Standard_D4s_v3" subnet_id: "/subscriptions/xx-xx-xx-xx-xx/resourceGroups/myResourceGroup/Microsoft.Network/virtualNetworks/myVnet/subnets/worker" disk_size: 128 count: 3 encrypted_at_host: Deshabilitado master_profile: vm_size: "Standard_D8s_v3" subnet_id: "/subscriptions/xx-xx-xx-xx-xx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/master" encryption_at_host: Deshabilitado

Realizar copias de seguridad de OpenShift con Trilio

OpenShift aloja aplicaciones, configuraciones y datos persistentes esenciales. La pérdida de cualquiera de estos datos puede provocar tiempos de inactividad graves, corrupción de datos o infracciones de cumplimiento normativo. Las copias de seguridad garantizan la recuperación ante desastres, la flexibilidad de migración y la protección contra borrados accidentales, ciberataques o fallos del clúster.

Se utilizan comúnmente varias herramientas para realizar copias de seguridad de OpenShift, cada una con sus limitaciones. Una de las soluciones de código abierto más populares es veleros, que ofrece funciones básicas de copia de seguridad, pero carece de instantáneas consistentes con la aplicación. Soluciones comerciales como Kasten K10 ofrecen copias de seguridad basadas en políticas, pero tienen optimizaciones limitadas específicas de OpenShift y pueden ser complejas de implementar en entornos de múltiples inquilinos. Copia de seguridad de Azure Kubernetes Service (AKS) También ofrece una herramienta de copia de seguridad nativa centrada en Azure. Sin embargo, suele estar limitada por estar vinculada únicamente a los servicios de Azure y carecer del alcance granular necesario para cargas de trabajo complejas de OpenShift. También existe la opción de usar instantáneas de almacenamiento nativas de proveedores de la nube, pero estas solo capturan estados de disco sin consistencia de objetos de Kubernetes, lo que requiere pasos de recuperación manual adicionales.

Aquí es donde entran en juego soluciones como trilio Trilio está diseñado como una plataforma de nivel empresarial para abordar las complejas necesidades de protección de datos y recuperación ante desastres de las organizaciones modernas. A diferencia de las herramientas de backup genéricas, Trilio garantiza copias de seguridad adecuadas y consistentes con las aplicaciones, fundamentales para bases de datos y cargas de trabajo con estado. Es compatible de forma nativa con operadores OpenShift y recursos personalizados, lo que permite la copia de seguridad y la recuperación fluidas de versiones de Helm y CRD. Con opciones de recuperación granular, los administradores pueden restaurar espacios de nombres individuales o clústeres completos, evitando la dependencia de un proveedor.

Cuando se utiliza con una solución como ARO, Trilio puede ofrecer las siguientes capacidades:

• Copias de seguridad automatizadas: Trilio permite programar copias de seguridad en un momento determinado y ofrece opciones de recuperación flexibles.
• Restauración continua: Las capacidades de restauración continua de Trilio permiten desarrollar estrategias eficaces de recuperación ante desastres. Independientemente de su proveedor de nube, garantizan la rápida restauración de las aplicaciones tras un desastre. La innovadora arquitectura de Trilio permite convertir continuamente múltiples clústeres de aplicaciones principales en un único clúster dedicado a la recuperación ante desastres (DR). Este enfoque reduce los costes de infraestructura en comparación con un modelo tradicional de clústeres uno a uno, desde el principal hasta el de recuperación ante desastres.
• Migración y portabilidad de la plataforma: Trilio permite a las organizaciones migrar sin problemas aplicaciones entre diversos entornos, como Azure Red Hat OpenShift y Red Hat Servicio OpenShift en AWS (ROSA), o incluso clústeres locales. Por ejemplo, los clientes pueden migrar fácilmente sus aplicaciones a la infraestructura local si los costos de la nube se vuelven prohibitivos.
• Gestión de múltiples clústeres: La integración de Trilio con Red Hat Advanced Cluster Management for Kubernetes (RHACM) facilita la definición y orquestación de la protección de datos basada en políticas en una amplia gama de implementaciones de Kubernetes, incluidos entornos híbridos, multicloud y de borde.

La siguiente tabla compara Trilio con algunas de las otras soluciones de respaldo.

Mejores prácticas para implementar OpenShift

Estas son algunas de las prácticas recomendadas para implementar OpenShift:

• Realizar una planificación adecuada de la capacidad: Evalúe y asigne recursos exhaustivamente antes de implementar el clúster. Se deben asignar suficientes recursos de computación y memoria a los nodos del clúster para que las cargas de trabajo no se vean afectadas negativamente. La capacidad de los nodos de trabajo debe contemplar las necesidades actuales de la aplicación y el crecimiento proyectado, generalmente con un margen del 20-30 %. Se recomienda encarecidamente el uso de almacenamiento de alto rendimiento como NVMe para los backends de etcd a fin de mantener la capacidad de respuesta del clúster.
• Implementar una seguridad de red sólida: Incorpore una segmentación de red estricta desde el primer día. Aísle el tráfico del plano de control de los nodos de trabajo y las conexiones externas mediante VLAN dedicadas o políticas de red. Restrinja el tráfico entre espacios de nombres y aplicaciones mediante políticas de red detalladas. Coloque los controladores de entrada en una zona perimetral segura con cifrado TLS obligatorio para todo el tráfico externo.
• Optimizar para el rendimiento: Al implementar OpenShift en redes locales, configure cuidadosamente las direcciones IP virtuales (VIP) de API e ingreso en redes de baja latencia (tiempo de respuesta <2 ms). Realice pruebas de carga para validar las configuraciones de VIP en condiciones de tráfico pico. Distribuya los puntos finales de ingreso entre las zonas de disponibilidad para lograr redundancia y equilibrar la carga del servidor API entre los nodos del plano de control.
• Proteger datos: Implemente una estrategia integral de copias de seguridad antes de pasar a producción. Esta debe incluir copias de seguridad de etcd cada hora e instantáneas diarias de datos de la aplicación almacenadas en ubicaciones geográficamente separadas.
• Garantizar la preparación operativa: Mantener libros de ejecución detallados para operaciones críticas, incluidas rotaciones de certificados, reemplazos de nodos y procedimientos de recuperación de emergencia.