Una de las arquitecturas que se utiliza en múltiples clientes con infraestructura híbrida es Google Anthos, una hermosa tecnologia que permite desplegar clusters de Kubernetes en distintos entornos utilizando la configuración de Google Kubernetes Engine, GKE, como tambien, agregar a Google Anthos otras distribuciones de Kubernetes de distintos proveedores o nubes públicas. En este post, revisaremos como es la arquitectura de Anthos y donde instalar Kasten K10 para proteger las aplicaciones.
Documentación Google Anthos
Como siempre revisaremos la documentación oficial de las plataformas o soluciones que estaremos revisando en este post, en este caso, Google Anthos, Google Kubernetes Engine y por supuesto Kasten K10 para proteger las aplicaciones.
- Google Anthos: https://cloud.google.com/anthos/docs/concepts/overview
- Kasten K10: https://docs.kasten.io/latest/index.html
Por tanto, al leer la documentación podemos observar que Google Anthos nos permite administrar múltiples clusters de Kubernetes, ya sea, EKS, AKS, Bare Metal, VMware, entre otros. Además, de otras características que permiten realizar la validación de seguridad, aplicación de políticas de configuración para múltiples clusters, service mesh, entre otros.
Para este post, revisaremos donde instalar Kasten K10 y como gestionar la protección de múltiples aplicaciones en clusters de kubernetes gesstionados por Google Anthos.
Respaldo Google Cloud Anthos
Antes de instalar Kasten K10 para proteger nuestras aplicaciones en distintas distribuciones de kubernetes administradas por Google Anthos, debemos poner atención en la documentción sobre la protección de nodos que nos ofrece Google Anthos, particularmente en los siguientes links:
- https://cloud.google.com/anthos/clusters/docs/on-prem/latest/how-to/back-up-admin-cluster
- https://cloud.google.com/anthos/clusters/docs/on-prem/latest/how-to/back-up-user-cluster
Como la documentación oficial lo indica, no existe protección para las aplicaciones, volúmenes persistentes, entre otros, que se ejecutan en los clusters de kubernetes administrados por Google Anthos. Por tanto, lo único que puede proteger desde Anthos, son las configuraciones de ETCD a través de snapshots para los clusters de administración y clusters de usuarios, inclusive en las nuevas características que estan en BETA y se menciona en la documentación para respaldar clusters de administración via gkectl, tiene limitantes adicionales, como por ejemplo, no es posible generar más de 6 respaldos de ETCD.
Entonces, al observar estas limitantes y no centrarse en las aplicaciones que se ejecutan en los distintos clusters de Kubernetes manejados por Anthos, es que se hace necesario la utilización de Kasten K10, para proteger las aplicaciones ejecutándose en disntitas distribuciones de Kubernetes, permitiendo la protección, recuperación, migración y recuperación ante desastres de las aplicaciones en Kubernetes.
Arquitectura Kasten K10 con Google Anthos.
De hecho, una de las grandes virtudes de Kasten K10 es que puede proteger las aplicaciones de cualquier cluster Kubernetes soportado, ya sea desde el respaldo, recuperación, migración y recuperación ante desastres de las aplicaciones entre distintas distribuciones de Kubernetes. Permitiendo ofrecer una gestión centralizada de la protección y aportando esta gestión de datos a la arquitectura de Google Anthos.
Como se puede observar en la imagen anterior, la arquitectura es muy sencilla con Kasten K10, ya que, solo hay que instalar K10 en cada uno de los clusters de Kubernetes gestionados por Google Anthos para luego designar o utilizar un cluster de administración para la gestión centralizada a través de Kasten K10 Multi-Cluster Manager.
Recursos utilizados por Google Anthos en VMware
Para este post, se realizó la configuración de Google Anthos y el despliegue de clusters en VMware para validar las configuraciones y versiones de Kubernetes, en este caso, se desplegaron:
- 1 VM: Admin Workstation (gloud cli y gestion de los recursos)
- 3 VM: 1 Control Plane y 2 Worker Node para el Cluster de Administracion
- 6 VM: 3 Control Plane y 3 Worker Nodes para el Cluster de Usuario (k10anthos)
Recordemos que cuando se despliega un cluster de Kubernetes desde Google Anthos, la configuracion aplicada por ejemplo en VMware, es de acuerdo con las buenas practicas, es decir, utilizará el driver CSI de vSphere. Por supuesto siempre es posible configurar el cluster para la utilización de drivers que sean necesarios.
Recursos desde Google Cloud Console
Esta configuración de Anthos puede ser realizada desde linea de comandos como tambien desde la consola grafica de Google Cloud, como se observa en la imagen anterior, Google Cloud, se autentica en los clusters de Kubernetes desplegados en el cluster de VMware para monitorear y aplicar las configuraciones de seguridad, políticas de administración, service mesh o lo que el administrador desee activar para la ejecución correcta de sus aplicaciones.
De hecho, es posible revisar todos los recursos utilizados y realizar cambios directamente desde la consola de Google Cloud, ya sea en la revisiones de las cargas de trabajo como tambien la edición de la cantidad de uso de CPU o RAM de los nodos administrados por Google Anthos.
Clusters de Kubernetes
Si revisamos los clusters creados usando kubectl, podemos ver la creación de los dos cluster, Admin y User, con sus respectivos nodos.
Como se instala Kasten K10 en estos cluster?, es muy sencillo, se instala como si fuese un cluster de Kubernetes más, de hecho estos clusters estan basados en GKE, para la instalación, puede revisar los siguientes links de este blog:
Kasten K10 Multi-Cluster Dashboard
Por supuesto, Google Anthos, al gestionar múltiples distribuciones de Kubernetes centralizadamente, necesita que la protección de las aplicaciones también sean gestionadas de forma centralizada, es por ello, que es necesario habilitar K10 Multi-Cluster Manager, para la gestión de los recursos, politicas y flujos de recuperación ante desastres entre distintas distribuciones de Kubernetes
Finalizando, siempre es necesaria la utilización de Kasten K10 en todas las implementaciones de Kubernetes independientemente de la distribución de kubernetes, ya que en multiples casos se observan limitantes en relación a la protección de las apliaciones del negocio incluyendo la recuperación ante desastres.