Uso de instantáneas de artefactos para proteger los clusters de Kubernetes frente a desastres

Para garantizar la continuidad del negocio en caso de desastres, deberá implantar una estrategia de recuperación ante desastres (DR) para las aplicaciones que se ejecutan en el cluster de Kubernetes que proporciona protección de datos y le permite cambiar rápidamente a un sistema en espera con una pérdida mínima de datos y productividad. A pesar del tremendo cambio que implica la adopción de Kubernetes para la arquitectura del sistema de TI, un sistema de Kubernetes presenta paradigmas de DR similares a los de una aplicación tradicional (Oracle Java SE, Oracle Java EE, etc.). Debe mantener una copia coherente y lo más actualizada posible del sistema principal en una ubicación secundaria que pueda reanudar las cargas de trabajo si un desastre causa tiempo de inactividad en la región principal.

Oracle Maximum Availability Architecture (MAA) proporciona recomendaciones y utilidades que le permiten recuperarse en escenarios de desastre que afectan a una ubicación y obligan a redireccionar las cargas de trabajo a un sitio de réplica. El objetivo de este manual es la replicación de configuración de Kubernetes para aplicaciones. Las aplicaciones que se ejecutan en clusters de Kubernetes dependen de muchos componentes diferentes para operar, incluidos nodos de plano de control, nodos de trabajador, equilibradores de carga y almacenamiento. Al mismo tiempo, los datos de tiempo de ejecución generados por las aplicaciones que se ejecutan en Kubernetes presentan los mismos desafíos que las aplicaciones tradicionales, mientras que las aplicaciones de tiempo de ejecución pueden generar, leer y actualizar datos persistentes. En este manual de soluciones se proporcionan recomendaciones para replicar la configuración de una aplicación que se ejecuta en Kubernetes. La protección ante desastres de los datos en tiempo de ejecución está fuera del ámbito de este documento y se debe tratar exactamente de la misma manera que en las aplicaciones tradicionales que se ejecutan en servidores de aplicaciones, incluidas las siguientes:

• Evite la persistencia políglota. El uso de diferentes tipos de almacenes persistentes para datos de tiempo de ejecución es casi imposible de resolver el problema, según el teorema de coherencia de disponibilidad de copia de seguridad (BAC).
• Utilice un único almacén para todos los diferentes tipos de datos, microservicios y aplicaciones con dependencias, en la medida de lo posible.
• Consulte Mejores prácticas de Oracle MAA para Oracle Database para obtener protección ante desastres para sus datos de tiempo de ejecución.

Además, debe proteger el plano de control de cluster de Kubernetes. Utilice las instantáneas etcd adecuadas para evitar corrupciones, fallos y para proporcionar un flashback a los clusters en funcionamiento. Aunque Oracle Maximum Availability proporciona mejores prácticas para la protección de plano de control frente a desastres, está fuera del ámbito de este documento describir las técnicas necesarias en esa área.

Antes de comenzar

Hay varios resúmenes técnicos de Oracle Maximum Availability Architecture (MAA) que describen cómo configurar un sistema de recuperación ante desastres (DR) para sistemas de middleware tradicionales. En estos documentos se detallan los requisitos de protección ante desastres para los componentes de infraestructura externa (como almacenamiento, equilibradores de carga y base de datos) que utilizan las aplicaciones de Kubernetes.

Consulte lo siguiente para obtener más información:

• Recuperación ante desastres de Oracle WebLogic Server for Oracle Cloud Infrastructure
• SOA Suite en Oracle Cloud Infrastructure Marketplace: recuperación ante desastres

Arquitectura

Esta arquitectura muestra la topología del sistema de recuperación ante desastres (DR) para el cluster de Kubernetes.

Toda la información de tiempo de ejecución, configuración y metadatos que reside en la base de datos primaria se replica de la región 1 a la región 2 con Oracle Autonomous Data Guard. La configuración de cluster de Kubernetes (K8s) necesaria se replica mediante instantáneas ETCD para la protección del plano de control y con instantáneas YAML para la protección de la configuración de la aplicación. Puede utilizar instantáneas de artefactos o puede utilizar copias de etcd o instantáneas de artefactos para la protección de la configuración específica de la aplicación para la protección de la configuración específica de la aplicación. Consulte Restauración de clusters de Kubernetes basados en instantáneas etcd para obtener más información. Las imágenes que utiliza el contenedor se alojan en registros, ya sea locales para cada cluster o en repositorios externos (las imágenes no se consideran una configuración de cluster de Kubernetes por sí mismas).

Nota:

La configuración de Oracle Autonomous Data Guard para la base de datos en tiempo de ejecución está fuera del ámbito de este documento.

Descripción de la ilustración kubernetes-multiregion-dr.png

kubernetes-multiregion-dr-oracle.zip

Esta arquitectura soporta los siguientes componentes:

• Región

  Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y las grandes distancias pueden separarlas (entre países e incluso continentes).

• Equilibrador de carga

  El servicio Oracle Cloud Infrastructure Load Balancing proporciona una distribución automatizada del tráfico desde un único punto de entrada a varios servidores en el backend.

• Gateway de enrutamiento dinámico (DRG)

  El DRG es un enrutador virtual que proporciona una ruta para el tráfico de red privada entre las redes virtuales de la misma región, entre una VCN y una red fuera de la región, como una VCN de otra región de Oracle Cloud Infrastructure, una red local o una red de otro proveedor en la nube.

• Data Guard

  Oracle Data Guard proporciona un completo juego de servicios que permiten crear, mantener, gestionar y supervisar una o más bases de datos en espera para permitir que las bases de datos Oracle de producción permanezcan disponibles sin interrupción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción. A continuación, si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, Oracle Data Guard puede cambiar cualquier base de datos en espera al rol de producción, minimizando el tiempo de inactividad asociado a la interrupción.

• Oracle Real Application Clusters (Oracle RAC)

  Oracle RAC permite ejecutar una única Oracle Database en varios servidores para maximizar la disponibilidad y activar la escalabilidad horizontal, mientras accede al almacenamiento compartido. Las sesiones de usuario que se conectan a instancias de Oracle RAC pueden realizar un failover y reproducir de forma segura los cambios durante las interrupciones, sin ningún cambio en las aplicaciones de usuario final.

• Registro de contenedor

  Oracle Cloud Infrastructure Registry es un registro gestionado por Oracle que permite simplificar el flujo de trabajo de desarrollo-producción. El registro facilita el almacenamiento, el uso compartido y la gestión de imágenes y artefactos de desarrollo. La arquitectura altamente disponible y ampliable de Oracle Cloud Infrastructure garantiza que pueda desplegar y gestionar sus aplicaciones de forma fiable.

• Container Engine para Kubernetes

  Oracle Cloud Infrastructure Container Engine for Kubernetes es un servicio totalmente gestionado, ampliable y disponible que puede utilizar para desplegar las aplicaciones en contenedor en la nube. Especifique los recursos informáticos que necesitan sus aplicaciones y Container Engine for Kubernetes los proporciona en Oracle Cloud Infrastructure en un arrendamiento existente. Container Engine for Kubernetes utiliza Kubernetes para automatizar el despliegue, el ajuste y la gestión de aplicaciones en contenedores en clusters de hosts.

• Cluster de Kubernetes

  Un cluster de Kubernetes es un juego de máquinas que ejecutan aplicaciones en contenedores. Kubernetes proporciona una plataforma de código abierto portátil y ampliable para gestionar cargas de trabajo y servicios en contenedores en esos nodos. Un cluster de kubernetes está formado por nodos de trabajador y nodos de plano de control.

• Nodo de trabajador de Kubernetes

  Un nodo de trabajador de Kubernetes es una máquina backend privada que ejecuta aplicaciones en contenedores en un cluster de Kubernetes. Cada cluster tiene al menos un nodo de trabajador.

• Plano de control de Kubernetes
  Un plano de control de Kubernetes gestiona los recursos para los nodos de trabajador y los pods dentro de un cluster de Kubernetes. Los componentes del plano de control detectan y responden a eventos, programan y mueven los recursos del cluster. A continuación se muestran los componentes del plano de control:

  • kube-apiserver: ejecuta el servidor de API de Kubernetes.
  • etcd: almacén de clave-valor distribuido para todos los datos de cluster.
  • kube-scheduler: determina en qué nodo se ejecutarán los nuevos pods sin asignar.
  • kube-controller-manager: Ejecuta procesos de controlador.
  • cloud-controller-manager: enlaza el cluster con la API específica de la nube.
• Controlador de entrada

  Un controlador de entrada es un componente que se ejecuta en un cluster de Kubernetes y gestiona los recursos de entrada. Recibe tráfico de la red externa, lo enruta al servicio correcto y realiza el equilibrio de carga y la terminación SSL. El controlador de entrada se suele ejecutar como un pod independiente en el cluster y se puede ampliar de forma independiente a los servicios que gestiona.

• API KUBE-Endpoint

  La API de punto final de KUBE es el componente KUBE-apiserver del plano de control de Kubernetes. Ejecuta el servidor de API de Kubernetes.

• Copia de seguridad ETCD

  ETCD Backup es una copia de seguridad del componente etcd del plano de control de Kubernetes. etcd contiene el almacén de clave-valor distribuido para todos los datos del cluster. Es importante crear una copia de seguridad de ETCD para recuperar clusters de Kubernetes para la recuperación ante desastres.

• Instantáneas de YAML

  Una instantánea YAML es una copia puntual de los archivos (yaml) que contienen la definición de los artefactos en un cluster de Kubernetes. La instantánea es un archivo tar que puede utilizar para restaurar esos artefactos en el mismo cluster de Kubernetes o en otro diferente.

Consideraciones para la protección ante desastres de Kubernetes

Al implementar la protección ante desastres para Kubernetes, tenga en cuenta lo siguiente:

• Recuperación ante desastres (DR) simétrica: Oracle recomienda utilizar exactamente la misma capacidad y configuración de recursos en el nivel primario y el secundario. Los espacios de nombres de Kubernetes deben tener recursos similares disponibles, como el número de nodos de trabajador (y su capacidad de hardware) y otra infraestructura (almacenamiento compartido, equilibradores de carga, bases de datos, etc.). Los recursos de los que depende el cluster de Kubernetes en la región secundaria deben poder seguir el ritmo de las mismas cargas de trabajo que la principal. Además, los dos sistemas deben ser coherentes funcionalmente con los mismos servicios de los que depende el sistema restaurado, los coches laterales, los mapas de configuración (CM) deben utilizarse en ambas ubicaciones.
• Las imágenes de contenedor presentan un paradigma similar a los binarios: las imágenes no cambian con tanta frecuencia como la configuración de Kubernetes y es posible que no necesite actualizar imágenes con cada replicación de cluster de Kubernetes. Las imágenes utilizadas por el sistema primario deben ser las mismas que las utilizadas en el sistema secundario o pueden producirse incoherencias y fallos. Sin embargo, la replicación de imágenes está fuera del alcance de este manual. Existen varias estrategias que puede utilizar para mantener un uso coherente de imágenes entre dos ubicaciones, incluidas las siguientes:
  • Guarde imágenes en el nodo principal y cárguelas en los nodos de trabajador secundarios. Este enfoque es muy fácil de implementar, pero conlleva gastos generales de gestión. El uso de registros de contenedor tiene considerables ventajas y guardar imágenes localmente dificulta la gestión de versiones y actualizaciones.
  • Las imágenes pueden residir en registros de contenedor totalmente externos en distintas regiones o centros de datos de los que utilizan la base de datos primaria y la base de datos en espera. Los productos y bibliotecas externos son mantenidos por terceros y su disponibilidad suele estar implícita en sus versiones.
  • Las imágenes pueden residir en registros de contenedor ubicados en ubicaciones principales y en espera. Cada región se actualiza en paralelo cuando se libera una nueva versión de una imagen. Esto proporciona un mejor control sobre el software utilizado, pero genera una mayor sobrecarga de gestión. Necesita duplicar imágenes y gestionar las credenciales para acceder a dos registros diferentes. Las herramientas de integración y despliegue continuos se utilizan normalmente para este enfoque.

Aunque este manual presenta un ejemplo con Oracle Cloud Infrastructure, las recomendaciones son genéricas para los clusters de Kubernetes personalizados instalados en sistemas locales. Puede utilizar los pasos y scripts proporcionados entre un cluster de Kubernetes principal que se ejecuta en Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) y un cluster secundario que se ejecuta en un cluster de Kubernetes local o personalizado. También puede utilizar los pasos y scripts entre un cluster de Kubernetes principal que se ejecute en OKE y un cluster secundario que se ejecute también en OKE, o entre dos clusters de Kubernetes locales o personalizados.

Acerca de los productos y los roles necesarios

Esta solución requiere los siguientes productos y roles:

• Cluster de Kubernetes
• Nodo bastión capaz de gestionar el sistema kubernetes
• Oracle Cloud Infrastructure (OCI)

  Este manual se basa en el uso de regiones y recursos de OCI para las regiones principal y secundaria. Sin embargo, esta solución también se aplica a los clusters de Kubernetes que no se encuentran en OCI.

Estos son los roles necesarios para cada servicio.

Nombre de servicio: rol	Necesario para...
Oracle Cloud Infrastructure: admin	aprovisione y configure recursos y servicios si utiliza una o más regiones de OCI.
Cluster de Kubernetes (principal): administrator	Ejecutar todos los scripts.
Nodos de Kubernetes (principal): usuario del sistema operativo con permisos de ejecución y permisos ssh a secundario	ejecutar los siguientes archivos de comandos: maak8-get-all-artifacts.sh maak8DR-apply.sh
Cluster de Kubernetes (secundario): administrator	Ejecutar todos los scripts.
Nodos de Kubernetes (secundarios): usuario del sistema operativo con permisos de ejecución	ejecutar los siguientes archivos de comandos: removeyamlblock.sh apply-artifacts.sh maak8-push-all-artifacts.sh

Consulte Productos, soluciones y servicios de Oracle para obtener lo que necesita.

Log de Cambios

Este log muestra cambios significativos:

12 de julio de 2023

Se ha revisado el diagrama de arquitectura. Mejoró el contenido.