Más información sobre la restauración de clusters de Kubernetes basada en instantáneas de etcd

Para garantizar la continuidad del negocio en caso de desastres, querrá implementar una estrategia de recuperación ante desastres para aplicaciones que se ejecutan en clusters de Kubernetes. Utilice estas recomendaciones de Oracle Maximum Availability Architecture (Oracle MAA) que proporcionan 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 de recuperación ante desastres (DR) similares a los de 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 en caso de que un desastre cause 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 forzar la redirección de cargas de trabajo a un sitio de réplica.

Aunque este manual de soluciones se centra en la restauración de 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 se activa 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 ETCD revertirá todos los artefactos al punto en el tiempo en el que se realizó la instantánea (copia de seguridad).

Este documento se centra en la replicación de los datos 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 de clave utilizado como almacén de copia de seguridad de Kubernetes para los datos del cluster. Este manual de soluciones proporciona 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 etcd restore. Los scripts y procedimientos de configuración proporcionados pueden requerir personalizaciones para otro tipo de clusters (no creados 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 etcd snapshots) para mostrar exactamente los mismos artefactos que existían en el principal.

Puede utilizar instantáneas de artefactos o herramientas de copia de seguridad de Kubernetes de terceros para replicar aplicaciones y espacios de nombres específicos en los sistemas de Kubernetes. Sin embargo, no protegen los clusters de las corrupciones de archivos y las configuraciones incorrectas en los metadatos del plano de control. Además de utilizarlos para la protección ante desastres, puede utilizar etcd snapshots para restauraciones locales y revertir clusters de Kubernetes a un punto de trabajo anterior en el tiempo. Si el sistema etcd store y etcd cluster no están en buen estado, es posible que las aplicaciones sigan 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 de 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 contra desastres de datos de tiempo de ejecución está fuera del ámbito de este documento y debe tratarse exactamente de la misma manera que en las aplicaciones tradicionales que se ejecutan en servidores de aplicaciones:

• Evitar la persistencia políglota (el uso de diferentes tipos de almacenes persistentes para datos en tiempo de ejecución es un problema "casi" imposible de resolver según el teorema de BAC)
• Utilice un único almacén para los diferentes tipos de datos, microservicios y aplicaciones con dependencias en la mayor medida 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 empezar

Existen 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 para recuperación ante desastres

Consulte Uso de instantáneas de artefactos para proteger los clusters de OCI Kubernetes Engine de un desastre para obtener más información sobre el uso de instantáneas de artefactos para la protección de configuración específica de la aplicació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 etcd o instantáneas de artefactos para la protección de configuración específica de la aplicació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).

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-etcd-multiregion-dr.png

kubernetes-etcd-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

  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 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.

• 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.
• 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.

• 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 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 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.
• Alias de nombre de host y virtualización: es importante planificar los nombres de host utilizados por los nodos en el sitio secundario. Los nombres de host o los 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 desde 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 (configuración) que describen el cluster en sí y en varios archivos y entradas de configuración. La ubicación secundaria debe identificar las direcciones kube-api de trabajador, plano de control y frontend con los mismos nombres de host utilizados en el cluster de Kubernetes principal (un nombre totalmente cualificado puede diferir 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 los kubelets, los programadores, los controladores y, en general, los servicios del plano de control no podrán alcanzar los puntos finales y los hosts adecuados que utiliza la configuración replicada. No utilice direcciones IP para identificar nodos en Kubernetes; en su lugar, utilice siempre nombres de host.
• Las imágenes presentan un paradigma similar al de los binarios: es posible que las imágenes no cambien con tanta frecuencia 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 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.
• Diferencias entre el cluster principal y el secundario: se espera (como en general para los sistemas de DR) que el cluster principal y el secundario sean una réplica entre sí en términos de versiones y configuración utilizadas. Los siguientes aspectos son especialmente relevantes:
  1. Versiones de Kubernetes
  2. Tiempo de ejecución de contenedor y versión de tiempo de ejecución de contenedor
  3. Versiones de plugin de red y plugin de red
  4. podSubnet y servicesubnet
  5. Directorio de ruta de host etcd y versión de imagen etcd
  6. Versión de imagen de dns y plugin de red
  7. Repositorio de imágenes para pods de plano de control

  Las configuraciones de protección ante desastres con pequeñas diferencias entre los sitios de la versión de Kubernetes pueden funcionar, pero pueden dejar el cluster en un estado inconsistente después de una restauración a partir de la instantánea etcd de una instancia principal. La información sobre los sockets de tiempo de ejecución de contenedor, la versión de Kubernetes, etc., se almacena en el propio Kubernetes. Por ejemplo, la información de cri-socket es específica de cada nodo según el tiempo de ejecución de contenedor que se utilice y se almacena en asignaciones de configuración internas. Una gran cantidad de información utilizada para las actualizaciones por kubeadm se basa en los mapas de configuración en el espacio de nombres kube-system. Por lo tanto, es importante que tanto el primario como el secundario utilicen la misma información en estos mapas de configuración. Puede utilizar este comando para almacenar toda la información relevante de los mapas de configuración importantes tanto en la base de datos primaria como en la base de datos en espera en los archivos yaml.

  [prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

  Del mismo modo, puede realizar una copia de la configuración del nodo en cada sitio con el siguiente comando:

  [prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
  

Este manual de soluciones presenta un ejemplo con 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 requerir 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 incoherencias y clusters etcd inestables.

Acerca de los productos y los roles necesarios

Esta solución requiere los siguientes productos y roles:

• Cluster de Kubernetes
• Bastion capaz de gestionar el sistema de Kubernetes accede a los puntos finales etcd del cluster y accede a los diferentes 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	ejecute 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	ejecute 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.