Uso de instantáneas de artefactos para proteger los clusters de OCI Kubernetes Engine de los desastres

Para garantizar la continuidad del negocio en caso de desastres, querrá implementar una estrategia de recuperación ante desastres (DR) para aplicaciones que se ejecutan en clúster 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 en caso de que un desastre cause tiempo de inactividad en la región principal.

Oracle Maximum Availability Architecture (Oracle MAA) proporciona recomendaciones y utilidades que le permiten recuperarse en escenarios de desastre que afectan a una ubicación y forzan la redirección de cargas de trabajo a un sitio de réplica. El enfoque de este contenido es la replicación de la configuración de Kubernetes para las aplicaciones. Las aplicaciones que se ejecutan en clusters de Kubernetes dependen de muchos componentes diferentes para funcionar, incluidos los nodos de plano de control, los nodos de trabajador, los equilibradores de carga y el 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: durante las aplicaciones de tiempo de ejecución, pueden generar, leer y actualizar datos persistentes. Este manual de soluciones proporciona recomendaciones para replicar la configuración de una aplicación que se ejecuta en Kubernetes. La protección contra desastres de los datos de tiempo de ejecución está fuera del alcance de este documento y debe tratarse exactamente de la misma manera que en las aplicaciones tradicionales que se ejecutan en servidores de aplicaciones, lo que incluye lo siguiente:

• Evite la persistencia políglota. El uso de diferentes tipos de almacenes persistentes para datos de tiempo de ejecución es un problema casi imposible de resolver, 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 los datos de tiempo de ejecución.

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

Antes de empezar

Hay varios resúmenes técnicos de Oracle 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 para 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 de ETCD para la protección del plano de control y con instantáneas de YAML para la protección de la configuración de aplicaciones. Puede utilizar instantáneas de artefactos o puede utilizar copias etcd o instantáneas de artefactos para la protección de configuración específica de la aplicación para la protección de configuración específica de la aplicación. Consulte Restauración de clusters de Kubernetes basados en instantáneas de etcd para obtener más información. Las imágenes que utiliza el contenedor se alojan en registros, ya sean locales para cada cluster o en repositorios externos (las imágenes no se consideran una configuración de cluster de Kubernetes por sí mismas).

Note:

La configuración de Oracle Autonomous Data Guard para la base de datos de 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 admite 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 entre sí y puede haber grandes distancias que las separen (entre países e incluso continentes).

• Equilibrador de carga

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

• 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 en la misma región, entre una VCN y una red fuera de la región, como una VCN en otra región de Oracle Cloud Infrastructure, una red local o una red en otro proveedor en la nube.

• Data Guard

  Oracle Data Guard y Oracle Active Data Guard proporcionan un completo juego de servicios que permiten crear, mantener, gestionar y controlar una o más bases de datos en espera y que permiten 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 mediante la replicación en memoria. 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 Active Data Guard proporciona la capacidad adicional de descargar cargas de trabajo de lectura principalmente en bases de datos en espera y también proporciona funciones avanzadas de protección de datos.

• Oracle Real Application Clusters (Oracle RAC)

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

• Registro

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

• Kubernetes Engine

  Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine u OKE) es un servicio totalmente gestionado, escalable y disponible que puede utilizar para desplegar las aplicaciones en contenedores en la nube. Especifique los recursos informáticos que necesitan sus aplicaciones y Kubernetes Engine los provisionará en Oracle Cloud Infrastructure en un arrendamiento existente. OKE utiliza Kubernetes para automatizar el despliegue, la ampliación 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, 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 de trabajo que ejecuta aplicaciones en contenedores dentro de 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, realizan la programación y mueven recursos de cluster.

  Los siguientes son 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 del cluster.
  • kube-scheduler: determina en qué nodos se ejecutarán los nuevos pods sin asignar.
  • kube-controller-manager: ejecuta procesos de controlador.
  • cloud-controller-manager: vincula el cluster con la API específica de la nube.
• Ingress Controller

  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 normalmente se ejecuta como un pod independiente en el cluster y se puede escalar independientemente de los servicios que gestiona.

• API de punto final de KUBE

  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 de 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 contra desastres de Kubernetes

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

• Recuperación ante desastres simétrica (DR): Oracle recomienda utilizar exactamente la misma capacidad y configuración de recursos en principal y secundario. Los espacios de nombres de Kubernetes implicados 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 mantenerse al día con las mismas cargas de trabajo que las principales. Además, los dos sistemas deben ser coherentes funcionalmente con los mismos servicios de los que depende el sistema restaurado, los vehículos laterales y los mapas de configuración (CM) deben usarse en ambas ubicaciones.
• Las imágenes presentan un paradigma similar al de 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 principal deben ser las mismas que las utilizadas en el sistema secundario o pueden producirse inconsistencias y fallos. Sin embargo, la replicación de imágenes está fuera del alcance de este manual. Hay 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 del secundario. Este enfoque es muy fácil de implementar, pero incurre en gastos generales de gestión. El uso de registros de contenedor tiene considerables beneficios 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 diferentes regiones o centros de datos de los utilizados por la base de datos principal y 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 la base de datos principal 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. Requiere duplicar imágenes y gestionar las credenciales para acceder a dos registros diferentes. Para este enfoque se suelen utilizar herramientas de integración y despliegue continuos.

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 OCI Kubernetes Engine (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 ejecuta en OKE y un cluster secundario que se ejecuta 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 Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine o OKE)
• Nodo bastión capaz de gestionar el sistema de 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 Engine (principal): administrator	ejecute todos los scripts.
Nodos de Kubernetes Engine (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 del motor de Kubernetes (secundario): administrator	ejecute todos los scripts.
Nodos de Kubernetes Engine (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.