Información sobre la restauración de clusters de Kubernetes basada en instantáneas etcd

Para garantizar la continuidad del negocio en caso de desastres, deberá implantar una estrategia de recuperación ante desastres para las aplicaciones que se ejecutan en clusters de Kubernetes. Utilice estas recomendaciones de Oracle Maximum Availability Architecture (Oracle MAA) que ofrecen protección de datos y le permiten 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 similares de recuperación ante desastres (DR) como una aplicación tradicional (como Oracle Java SE, Oracle Java EE o JavaScript). 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.

Este manual de soluciones proporciona recomendaciones y utilidades de Oracle MAA que crearán un sistema de Kubernetes secundario y le permitirán recuperarse en escenarios de desastre que afecten a una ubicación y obliguen a la redirección de cargas de trabajo a un sitio de réplica.

Aunque este manual de soluciones se centra en restaurar un cluster de Kubernetes en una región diferente, puede utilizar los mismos scripts y procedimientos para restaurar un cluster in situ a un punto en el tiempo anterior. Esta operación puede ser útil en escenarios distintos de la recuperación ante desastres, como los siguientes:

Cuando el plano de control está mal configurado.
Cuando la base de datos etcd se pierde, se corrompe o cuando etcd no aparece correctamente.
Cuando un error de usuario o despliegue incorrecto afecta a varias aplicaciones o microservicios y el cluster se debe revertir a una versión o encarnación anterior. Una restauración de instantánea de ETCD revertirá todos los artefactos al momento en que se tomó la instantánea (copia de seguridad).

Este documento se centra en la replicación de datos de etcd de Kubernetes en una ubicación secundaria. Toda la información de un cluster de Kubernetes se almacena en etcd, que es un almacén de valores clave utilizado como almacén de copia de seguridad de Kubernetes para los datos del cluster. En este manual de soluciones se proporcionan recomendaciones para replicar un cluster de Kubernetes creado con la herramienta kubeadm de Kubernetes (consulte https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) basado en la restauración etcd. Los scripts y procedimientos de configuración proporcionados pueden requerir personalizaciones para otro tipo de clusters (los que no se crean con kubeadm), pero, en general, son válidos siempre que haya acceso a los puntos finales etcd que utiliza el plano de control de Kubernetes. Esta solución de replicación requiere una configuración específica para el cluster secundario y utilizará una copia de etcd (también denominada instantáneas etcd) para mostrar exactamente los mismos artefactos que existían en la base de datos primaria.

Puede utilizar instantáneas de artefactos o herramientas de copia de seguridad de Kubernetes de terceros para replicar espacios de nombres y aplicaciones específicos en los sistemas de Kubernetes. Sin embargo, no protegen los clusters de los daños y configuraciones erróneas de archivos en los metadatos del plano de control. Además de utilizarlos para la protección ante desastres, puede utilizar instantáneas de etcd para restauraciones locales y para revertir los clusters de Kubernetes a un punto de trabajo anterior en el tiempo. Si el almacén de etcd y el sistema de cluster de etcd no están en buen estado, las aplicaciones pueden seguir ejecutándose, pero las reubicaciones de pod, los cambios de configuración, el acceso secreto y cualquier otra operación que requiera la disponibilidad del plano de control no funcionarán correctamente. Por este motivo, la conservación de etcd debe ser una parte fundamental de cualquier procedimiento de ciclo de vida del cluster de Kubernetes.

Además de los datos de configuración de Kubernetes, las aplicaciones y los microservicios que se ejecutan en Kubernetes pueden generar datos en tiempo de ejecución. La protección ante desastres de 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:

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 BAC)
Utilice un único almacén para los distintos tipos de datos, microservicios y aplicaciones con dependencias tanto como sea posible
Consulte Mejores prácticas de Oracle MAA para Oracle Database para obtener protección ante desastres para su tiempo de ejecución

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:

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 necesaria se replica mediante instantáneas etcd para la protección del plano de control. Puede utilizar copias de etcd o instantáneas de artefactos para la protección de la configuración específica de la aplicación. Consulte Uso de instantáneas de artefactos para proteger los clusters de Kubernetes frente a un desastre para obtener más información. Las imágenes utilizadas por los contenedores se alojan en registros locales de 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.

A continuación se muestra la descripción de kubernetes-etcd-multiregion-dr.png

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

kubernetes-etcd-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.
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.
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.
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 clusters de Kubernetes en las dos regiones 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.
Alias de nombre de host y virtualización: es importante planificar los nombres de host que utilizan los nodos en el sitio secundario. Los nombres de host o nombres de host de alias para el plano de control y los nodos de trabajador deben estar "activos" en la ubicación secundaria antes de restaurar una instantánea etcd de un cluster de Kubernetes principal. Los nombres de nodo se almacenan en diferentes artefactos de un cluster de Kubernetes para identificar nodos de trabajador, marcar asignaciones de pod, en asignaciones de configuración (config) que describen el propio cluster y en varios archivos de configuración y entradas. La ubicación secundaria debe identificar las direcciones de trabajador, plano de control y front-end kube-api con los mismos nombres de host utilizados en el cluster de Kubernetes principal (un nombre totalmente cualificado puede ser diferente en el nombre de dominio, pero el nombre de host debe ser el mismo. Sin alias de nombre de host, una restauración de instantánea etcd no funcionará correctamente, ya que kubelets, planificadores, controladores y, en general, los servicios de plano de control no podrán acceder a los puntos finales y hosts adecuados utilizados por la configuración replicada. No utilice IP para identificar nodos en kubernetes, utilice siempre nombres de host en su lugar.
Las imágenes de contenedor presentan un paradigma similar a los binarios: es posible que las imágenes no cambien tan frecuentemente como la configuración de Kubernetes y 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.

En este manual de soluciones se presenta un ejemplo con los clusters de Kubernetes creados con la herramienta kubeadm. Las recomendaciones son genéricas para los clusters de Kubernetes personalizados instalados en sistemas locales, pero la mayoría de los scripts pueden necesitar modificaciones para los clusters que no se crean con la herramienta kubeadm. Debe utilizar los pasos y scripts proporcionados entre los clusters de Kubernetes que ejecutan la misma versión de etcd y Kubernetes. La restauración de instantáneas etcd en diferentes versiones de kubernetes puede provocar inconsistencias y clusters etcd inestables.

Acerca de los productos y los roles necesarios

Esta solución requiere los siguientes productos y roles:

Cluster de Kubernetes
Bastión capaz de gestionar el sistema Kubernetes para acceder a los puntos finales etcd del cluster y acceder a los distintos nodos de plano de control con ssh
(Opcional) 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 se encuentran en ubicaciones locales.

Estos son los roles necesarios para cada servicio.

Nombre de servicio: rol	Necesario para...
Cluster de Kubernetes (principal): `administrator`	Ejecutar todos los scripts.
Nodos de Kubernetes (principales): usuario con derechos sudo a raíz	ejecutar los siguientes archivos de comandos: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`
Cluster de Kubernetes (secundario): `administrator`	Ejecutar todos los scripts.
Nodos de Kubernetes (secundarios): usuario con derechos sudo a raíz	ejecutar los siguientes archivos de comandos: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

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