Kubernetes y plataformas de contenedores para cargas reguladas en Nigeria

En la mayoría de los casos, sí. Los manifiestos de Kubernetes, los charts de Helm y las imágenes de contenedor son portables; lo que requiere trabajo son las integraciones específicas de la nube, como bases de datos gestionadas, colas, roles de IAM y balanceadores. Mapeamos esas dependencias en la evaluación y las sustituimos por equivalentes en la plataforma privada y en la capa de datos de NuxFamily.

OpenShift es la elección más habitual cuando el banco quiere una plataforma totalmente integrada, con soporte del fabricante y un ecosistema de operadores sólido. Rancher encaja en entidades que operan varios clústeres y quieren una gestión más ligera. Tanzu tiene sentido sobre un entorno vSphere existente, y Canonical o Kubernetes upstream cuando dominan el coste y la neutralidad respecto al fabricante. Soportamos todas ellas y elegimos con usted a partir de evidencias.

La directiva exige que el entorno de procesamiento, los backups, el IAM, las claves de cifrado y los logs de auditoría de los datos de pago estén en Nigeria. Un clúster autoalojado sobre una nube privada nigeriana mantiene el plano de control, los volúmenes persistentes, el registro, los secretos y los logs de auditoría dentro del perímetro. El aislamiento por namespace y las políticas de admisión también ofrecen una separación demostrable del perímetro de pagos para la inspección. Esto es información de contexto, no asesoramiento legal.

Sí. OpenShift, Rancher y Kubernetes upstream soportan la instalación desconectada desde un registro replicado. Las actualizaciones de plataforma y las imágenes de aplicación llegan como paquetes firmados a través de su proceso de transferencia, y las políticas de admisión rechazan todo lo que no esté firmado con su clave.

NuxFamily da soporte al plano de control del clúster, los nodos, el ingress, la integración de almacenamiento, el registro, las herramientas GitOps y los operadores de plataforma que desplegamos, con los tiempos de respuesta de su nivel. Cuando existe una suscripción del fabricante, por ejemplo Red Hat o SUSE, la operamos por usted y escalamos upstream cuando es necesario. El alcance preciso de la responsabilidad L1-L3 se establece en el acuerdo de soporte.

Los clústeres se mantienen dentro de la ventana N-2 mediante upgrades menores programados, probados primero en un clúster no productivo construido a partir de la misma definición GitOps. Los upgrades utilizan sustitución progresiva de nodos, de modo que las aplicaciones con presupuestos de disrupción correctos no sufren caída. Los saltos de versión mayor se planifican como proyecto dentro del nivel Mission Critical.

Cada cambio en un clúster es un commit con autor, revisor y marca de tiempo, y Argo CD registra cuándo se aplicó. Exportamos ese histórico, junto con los informes de escaneo de imágenes y las firmas, como un registro de cambios que el regulador puede leer sin acceso al clúster. Los cambios manuales se detectan como deriva y se revierten, por lo que el registro es completo.