Qué son los VPC endpoints

Los VPC endpoints son una característica de red de AWS que permite conexiones privadas entre los recursos dentro de una VPC y los servicios compatibles de AWS, usando la red troncal de AWS y las API privadas de cada servicio.

Esta configuración garantiza que los recursos de una VPC no necesiten conexión a internet ni VPN para comunicarse con otros servicios de AWS, favoreciendo la implementación de redes seguras y aisladas que no dependen de infraestructuras públicas potencialmente inseguras.

Ejemplo de política predeterminada de VPC Endpoint

Bloque de código de la política de endpoint VPC predeterminada

{
  «Statement»: [
    {
      «Action»: «*»,
      «Effect»: «Allow»,
      «Principal»: «*»,
      «Resource»: «*»
    }
  ]
}

Como ejemplo, un servicio en una instancia EC2 puede usar un VPC endpoint para solicitar datos a la API privada de un bucket S3. Si no existe un endpoint configurado para el servicio S3, el tráfico necesitará pasar por un Internet Gateway u otro dispositivo similar hacia la API pública de S3, exponiéndolo a posibles ataques.

Varios tipos de endpoints permiten definir políticas que restringen las comunicaciones entre los recursos y los servicios asociados de AWS. Sin embargo, si no se define una política al crear el endpoint, AWS aplica una política predeterminada que otorga acceso completo e irrestricto al servicio, incluso a principales de otras cuentas AWS.

Este comportamiento implica que, si un actor malintencionado obtiene acceso a una subred privada dentro de la VPC, podría aprovechar la configuración para extraer datos del entorno AWS o escribirlos en otro servicio bajo su control.

Ejemplos de exfiltración de datos mediante endpoints mal configurados

S3

Un endpoint de S3 con la política predeterminada de acceso total permite el uso de las API privadas de S3 sin restricciones. Un atacante podría aprovecharlo para extraer información sensible hacia un bucket S3 en una cuenta bajo su control.

Esto se consigue de varias formas. Una de las más comunes es cuando un usuario malicioso con acceso a una instancia EC2 en la VPC sube las claves de acceso de un usuario IAM con permisos de escritura a un bucket S3 de su cuenta, utilizando luego esos permisos para exfiltrar datos a través del endpoint.

Además, herramientas como S3Backdoor pueden utilizarse para establecer canales de comando y control encubiertos que permiten mantener el acceso y extraer información confidencial.

SSM

Otro ejemplo más elaborado implica el uso del servicio Systems Manager (SSM). Un endpoint de SSM excesivamente permisivo puede permitir a un atacante acceder a instancias EC2 en una cuenta bajo su control mediante los comandos send-command y start-session.

En este caso, el atacante que ya tiene acceso a una instancia EC2 comprometida en una subred privada crea otra instancia EC2 en su propia cuenta, con la política AmazonSSMManagedInstanceCore asociada a su perfil de instancia y el agente de SSM instalado. Luego, sube las claves IAM de un usuario con la política AmazonSSMFullAccess y las utiliza en la instancia comprometida para ejecutar los comandos start-session y send-command a través del endpoint de SSM, copiando así datos hacia su propia instancia.

Recomendaciones 

Para asegurar los endpoints de VPC, te recomendamos:

– Crear endpoints de VPC para cada servicio compatible dentro de cada VPC, reduciendo la necesidad de conectividad a Internet y proporcionando acceso seguro a los servicios de AWS.
– Definir una política personalizada basada en el principio de menor privilegio para todos los endpoints configurados en el entorno AWS.
– Asegurar que las conexiones de red hacia los servicios de AWS solo sean accesibles desde los recursos internos de la cuenta u organización.
– Restringir el acceso a recursos individuales mediante su nombre o Amazon Resource Name (ARN) y minimizar el uso de comodines (wildcards), que podrían otorgar acceso no intencionado.

Tipos de endpoints

Interface endpoints
Son un tipo de interfaz de red que ofrece acceso a la red PrivateLink para conectarse con servicios. Estos endpoints admiten el uso de security groups para restringir el tráfico, aunque se recomienda combinarlos con políticas de endpoint para aplicar un enfoque de defensa en profundidad y un control de acceso más granular.

Gateway endpoints
Actúan como tablas de enrutamiento y no admiten security groups. Por ello, es esencial implementar una política restrictiva de endpoint que limite el tráfico hacia recursos externos.

Ejemplo de política segura de endpoint:

{
  «Statement»: [
    {
      «Action»: «S3:*»,
      «Effect»: «Allow»,
      «Resource»: [«*:*:*:*:xxxxxxxxxxxx:*», «*:*:*:*:yyyyyyyyyyyy:*»],
      «Principal»: «*»,
      «Condition»: {
        «StringEquals»: {
          «aws:PrincipalOrgID»: «o-zzzzzzzzzz»
        }
      }
    }
  ]
}

Esta política garantiza que los recursos de la red aislada solo puedan usar el endpoint de S3 para interactuar con buckets S3 controlados por cuentas específicas (xxxxxxxxxxxx y yyyyyyyyyyyy) y únicamente si el principal pertenece a tu organización (o-zzzzzzzzzz). En este caso, un atacante no podría acceder a buckets bajo su control.


Si quieres saber más sobre cómo proteger tu infraestructura en la nube, contacta con uno de nuestros expertos.

La entrada Cómo evitar la exfiltración de datos desde subredes privadas en AWS se publicó primero en Geko Cloud.

1) Elige tu asistente de IA (y cuándo usar cada uno)

Antes de instalar nada, ten claro tu stack y tus prioridades: IaC, Python, monorepos, cumplimiento o privacidad. Elegir bien el assistant te evitará pruebas largas y resultados pobres.

• GitHub Copilot: estándar de facto en VS Code. Muy fuerte en Python, Terraform, YAML de Kubernetes. Ideal si usas GitHub/Actions.
• Amazon Q Developer: excelente en IaC (Terraform/CDK) y stack AWS; añade escaneo de seguridad y remediaciones.
• Sourcegraph Cody: brilla en monorepos y búsqueda semántica; buen “agente” para cambios multi-archivo.
• Codeium / Tabnine: autocompletado+chat con opciones self-hosted (privacidad estricta).
• Continue.dev + Ollama/LM Studio: opción open source/local para usar modelos en tu equipo.
• Cursor (editor VS Code-like): si quieres un agente que edite varios archivos y proponga PRs.
  Recomendación: usa Copilot como base y añade Amazon Q si eres AWS/IaC-first; suma Cody para monorepos grandes.

2) Instalación y configuración en VS Code

Una buena configuración multiplica la calidad de las sugerencias y protege tu código. Tómate 15 minutos para dejar linters y seguridad funcionando desde el día uno.
Extensiones: Copilot (+ Chat), Amazon Q, opcionales (Cody/Codeium/Continue).

settings.json mínimo:

{

  «editor.formatOnSave»: true,

  ««: { «editor.defaultFormatter»: «ms-python.black-formatter» },

  «python.linting.enabled»: true,

  «python.testing.pytestEnabled»: true,

  «editor.inlineSuggest.enabled»: true,

  «terraform.formatOnSave»: true,

  «files.exclude»: { «**/.venv»: true, «**/.terraform»: true }

}

Pre-commit, linters y secretos:

pip install ruff black pytest

brew install tflint tfsec gitleaks

pre-commit install

.pre-commit-config.yaml (resumen):

– repo: https://github.com/astral-sh/ruff-pre-commit

  hooks: [{id: ruff}, {id: ruff-format}]

– repo: https://github.com/antonbabenko/pre-commit-terraform

  hooks: [terraform_fmt, terraform_validate, tflint, tfsec]

– repo: https://github.com/gitleaks/gitleaks

  hooks: [{id: gitleaks}]

Por qué importa: la IA acelera, pero tus guardrails evitan que código incorrecto o inseguro llegue a main.

3) Configura el contexto de la IA (y lo que NO debe ver)

La calidad del assistant depende de lo que ve. Dale contexto útil y oculta lo sensible: así aumentas precisión y cumples con privacidad.

• Crea .promptignore (o equivalente) para excluir .env, secrets.*, *.pem, *.tfstate, dumps y PII.
• Limita el contexto a archivos relevantes; evita compartir el repo entero sin necesidad.
• En organizaciones, activa controles de tenant y políticas de datos (Copilot Enterprise, AWS org).

4) Prompts que funcionan (con guardrails)

Un buen prompt guía al assistant y reduce alucinaciones. Piensa en ciclos: genera → valida → documenta → prueba.

4.1 Terraform — módulo VPC

Prompt:

“Genera un módulo Terraform networking/vpc (eu-west-1) con 2 subredes públicas y 2 privadas, NAT gestionado y etiquetas env,owner,cost_center. Variables tipadas, outputs útiles, snake_case. Incluye ejemplo en /examples.”
Valida:

terraform fmt && terraform validate && tflint && tfsec

Acepta si: sin críticos en tflint/tfsec, PR con README.

4.2 Python — utilidades + tests

Prompt:

“Crea utils/billing.py con apply_discount(amount, percent) y handle_vat(amount, country). Añade docstrings y tests/test_billing.py (pytest) con casos de borde.”
Valida: ruff . && black –check . && pytest -q

Acepta si: cobertura ≥ 90%, tests verdes.

4.3 Kubernetes — despliegue robusto

Prompt:

“Escribe k8s/orders-api.yaml con Deployment (3 réplicas) y Service ClusterIP. Imagen ghcr.io/acme/orders:1.8.2, probes /healthz, requests/limits conservadores, PodSecurityContext sin privilegios.”

Valida: esquema (kubeconform), OPA/PSP, prueba en entorno efímero.
Mejora: pide Helm chart con values.yaml.

4.4 CI/CD — pipeline con gates

Prompt:

“GitHub Actions: ruff/black/pytest; terraform fmt/validate, tflint, tfsec; terraform plan comentado en PR; apply sólo en main con aprobación manual. Añade cache y matrices de Python.”
Valida: branch protection, reviewers requeridos, secretos en vault y environments.

5) Flujo de trabajo recomendado (dentro de VS Code)

El valor aparece cuando integras IA en tu forma de trabajar, no al revés. Esta secuencia minimiza fricción y errores.

1. Crea rama y genera esqueleto con el chat del assistant.
2. Refina: pide validaciones y README/docstrings.
3. Ejecuta linters/tests desde la terminal integrada.
4. Abre PR con checklist (IaC validada, tests, seguridad).
5. Revisión humana y merge solo si pasa todo.

6) Gobierno, privacidad y seguridad (RGPD-ready)

Adoptar IA sin reglas es arriesgar el compliance. Define límites claros de datos, auditoría y políticas de uso.

• No incluyas secretos ni PII en prompts.
• DPA/SCC con proveedores; si hay transferencias internacionales, documenta DPIA.
• Activa controles de tenant/organización y telemetría mínima.
• Policy-as-Code (OPA/Conftest) para bloquear PRs que no cumplan:

package iac.naming

deny[msg] {

  input.resource.type == «aws_s3_bucket»

  not startswith(input.resource.name, «prod-«)

  msg := sprintf(«Bucket sin prefijo ‘prod-‘: %s», [input.resource.name])

}

7) Métricas y ROI: qué medir

Sin métricas no hay mejora. Define KPIs desde el inicio para justificar licencias y ampliar uso.

• Lead time (idea → PR → prod), % sugerencias aceptadas, defectos post-merge, MTTR, hallazgos tfsec/Checkov por PR, horas/mes ahorradas.
  Fórmula:

ROI ≈ (Horas ahorradas × coste/h) + (defectos evitados × coste) − coste de licencias

8) Plan 30/60 días para VS Code + IA

La adopción gradual reduce resistencia y riesgo. Este plan te da resultados visibles sin parar el equipo.
0–30 días (piloto): Copilot (+ Amazon Q si AWS/IaC), linters/pre-commit, .promptignore y /.prompts/, baseline KPIs.
31–60 días (escala): añade K8s + CI/CD, OPA/Conftest, dashboards de métricas.
61–90 días (avanzado): prueba Cody/Cursor para cambios multi-archivo, entornos efímeros y PRs sugeridos por agente.

9) Troubleshooting rápido

Cuando la IA no rinde, suele ser por contexto o guardrails. Ajusta, no abandones.

• Sugerencias pobres: abre archivos relevantes, reduce ruido, añade comentarios de intención.
• Alucinaciones: exige comandos de validación y explicación de supuestos; siempre PR + tests.
• Lentitud: limita contexto y carpetas; usa búsqueda semántica (Cody).
• Privacidad: revisa políticas del tenant y excluye carpetas sensibles.

VS Code con IA acelera DevOps si combinas el assistant adecuado, un setup sólido y guardrails de seguridad. Con prompts iterativos y métricas claras, convertirás velocidad en calidad y ROI.

¿Tienes dudas o quieres profundizar más? Contacta con nuestro equipo de expertos.

La entrada IA en VS Code aplicada a Terraform, Python y K8s se publicó primero en Geko Cloud.

Migrar a Infrastructure as Code (IaC) supone una transformación clave para mejorar la automatización, la seguridad y la escalabilidad. Sin embargo, convertir una infraestructura en la nube gestionada de forma tradicional a IaC exige planificación y un enfoque gradual para garantizar una transición segura, fluida y sostenible. Si se hace bien, facilitará los despliegues, reducirá los errores humanos y optimizará los costes; una mala ejecución puede generar caídas, configuraciones erróneas y problemas de cumplimiento.

Paso 1: Evalúa y documenta tu infraestructura actual

Antes de implementar IaC, es esencial contar con un inventario completo y actualizado de tus recursos en la nube. Esto incluye:

• Utilizar herramientas nativas como AWS Config, Azure Resource Graph o Google Cloud Asset Inventory para mapear recursos existentes.
• Identificar dependencias entre servicios cloud.
• Registrar componentes, configuraciones de seguridad y políticas vigentes.

Este inventario es vital para mantener coherencia durante la migración, evitando errores como configuraciones duplicadas, desconexiones entre servicios o brechas de seguridad no detectadas.

Paso 2: Define tu estrategia de migración a IaC

La estrategia dependerá de tus prioridades, la complejidad de tu entorno y tus objetivos. Existen tres enfoques habituales:

• Adopt as‑is: Convertir la infraestructura existente a IaC sin cambios profundos; es la opción más rápida, aunque puede mantener ineficiencias.
• Refactor: Optimizar la infraestructura durante la migración (mejorar seguridad, rendimiento y costes), por ejemplo, habilitando escalado automático.
• Rebuild: Rediseñar la infraestructura desde cero bajo las mejores prácticas IaC, ideal para entornos obsoletos.

Se recomienda un enfoque por fases si se parte de una configuración basada en provisión manual.

Paso 3: Selecciona las herramientas IaC adecuadas

La elección depende de tu proveedor cloud, el entorno y las competencias internas:

• Terraform: Ideal en entornos multi‑cloud o híbridos.
• AWS CloudFormation / Azure Bicep: Recomendables si tu infraestructura está centrada en AWS o Azure.
• Pulumi: Aporta flexibilidad a desarrolladores que prefieren usar lenguajes tradicionales (Python, JavaScript, etc.).

Mantener la consistencia entre equipos usando la misma herramienta puede reducir complejidad, aunque exige gestionar el estado IaC correctamente.

Paso 4: Implementa control de versiones y gestión del estado

Una vez en IaC, es clave controlar cambios e impedir conflictos entre versiones de código de infraestructura. También es necesario garantizar que lo que está desplegado refleja el estado deseado, evitando inconsistencias que generen errores o vulnerabilidades.

Buenas prácticas:

• Almacenar el código IaC en repositorios como GitHub, GitLab o Bitbucket.
• Usar almacenamiento remoto de estado (Terraform Cloud, AWS S3+DynamoDB, Azure Storage).
• Adoptar flujos basados en ramas para desplegar solo versiones validadas.

Paso 5: Prueba y valida IaC antes del despliegue

Desplegar IaC sin pruebas puede generar interrupciones por configuraciones erróneas o vulnerabilidades. Integra validaciones dentro del flujo de trabajo:

• Análisis estático con herramientas como Checkov o tfsec.
• Validación previa al despliegue mediante Terraform Plan o CloudFormation Change Sets.
• Pruebas automatizadas con frameworks como Terratest.

Esto permite detectar fallos o brechas de seguridad antes de afectar producción.

Paso 6: Migra por fases y monitoriza continuamente

Evita cambios masivos repentinos: opta por una migración paulatina:

• Empieza por entornos no productivos (desarrollo, staging).
• Supervisa con herramientas como Datadog, AWS CloudWatch o Azure Monitor.
• Detecta desviaciones (IaC drift) y habilita mecanismos de reversión y failover para restaurar configuraciones anteriores si algo falla.

Cómo ayuda Geko Cloud a migrar a IaC de forma segura

Muchas organizaciones carecen de experiencia interna para implementar IaC eficazmente. Geko Cloud brinda acompañamiento experto en:

• Auditoría y mapeo de la infraestructura actual.
• Definición de una estrategia de migración con riesgo minimizado.
• Implementación de despliegues automatizados y seguros a escala.
• Soporte continuo para mantener consistencia y gobernanza del IaC.

Migrar tu infraestructura actual a Infrastructure as Code de manera segura exige una estrategia bien definida, herramientas adecuadas, controles robustos y transición progresiva. Siguiendo prácticas sólidas, puedes modernizar tu infraestructura de forma eficiente, segura y sostenible.

¿Quieres saber más? Contacta con nuestro equipo de expertos.

La entrada Cómo migrar tu infraestructura en la nube existente a IaC se publicó primero en Geko Cloud.

Infrastructure as Code (IaC) revoluciona la automatización en la nube, pero desplegarla con éxito requiere planificación cuidadosa. Muchas empresas adoptan IaC sin considerar aspectos fundamentales como seguridad, gobernanza o pruebas, lo que puede provocar fallos, interrupciones y problemas de cumplimiento. Un despliegue sin sobresaltos requiere canalizaciones CI/CD estructuradas, validación automatizada y buenas prácticas de seguridad.

Las herramientas de validación automatizada escanean vulnerabilidades y configuraciones incorrectas antes del despliegue. No obstante, estas herramientas pueden pasar por alto vulnerabilidades nuevas o de bajo nivel que pueden convertirse en puntos de explotación dentro de un ataque más complejo.

Por ello, después del despliegue, las pruebas de penetración son vitales: simulan ataques del mundo real y revelan debilidades que los escáneres automatizados no detectan. La combinación entre escaneo automático y pruebas humanas fortalece significativamente la seguridad de tus desplegables IaC. 

Construye una canalización robusta para el despliegue de IaC

Una canalización bien estructurada garantiza seguridad, escalabilidad y consistencia. Sin ella, los cambios en infraestructura pueden provocar errores por desalineación, fallos de integración o interrupciones. 

1. Integra IaC en CI/CD

Aplica flujos de trabajo GitOps y CI/CD para que los cambios en infraestructura pasen por pruebas antes de llegar a producción.

• Almacena plantillas IaC en repositorios Git (GitHub, GitLab, Bitbucket) para control de versiones.
• Automatiza pruebas con herramientas como Terraform Plan, AWS Config o Azure Blueprints.
• Despliega mediante CI/CD con GitHub Actions, Azure DevOps o GitLab.
• Utiliza flujos de trabajo basados en ramas para evitar que cambios no aprobados lleguen a producción.

2. Implementa pruebas y validación automatizada

Previene interrupciones costosas y riesgos de seguridad:

• Usa herramientas de análisis estático como Checkov, tfsec o InSpec.
• Prueba tu infraestructura en entornos staging antes de desplegar en producción.
• Define mecanismos automáticos de reversión en caso de fallos.
• Considera añadir pruebas de penetración manuales como capa de seguridad adicional.

3. Asegura tus despliegues de IaC

Para proteger los recursos en la nube:

• Implementa control de acceso basado en roles (RBAC).
• Protege credenciales con HashiCorp Vault, AWS Secrets Manager o Azure Key Vault.
• Supervisa la configuración y aplica gobernanza con Policy as Code (PaC).

4. Monitoriza, mantiene y previene la deriva (drift)

Tras el despliegue, es crucial detectar cualquier desviación respecto al estado deseado:

• Habilita bloqueo de estado en Terraform o detección de drift en AWS CloudFormation.
• Usa herramientas de monitorización como Datadog, Prometheus o Azure Monitor.
• Automatiza actualizaciones para adaptarte a cambios en proveedores de nube.

Elige el MSP adecuado para tus necesidades de IaC

Al seleccionar un Proveedor de Servicios Gestionados (MSP), busca capacidades clave:

• Diseñar canalizaciones CI/CD alineadas con flujos GitOps.
• Implementar buenas prácticas de seguridad IaC.
• Automatizar pruebas para lograr un despliegue confiable.
• Monitorizar la deriva y aplicar políticas de gobernanza.
  Los MSP eficientes entienden que desplegar IaC va más allá de la automatización: ofrecen soluciones integrales que optimizan el proceso, reducen riesgos y facilitan un crecimiento seguro.

Desplegar IaC con éxito requiere una estrategia integral: flujos CI/CD bien diseñados, pruebas robustas, seguridad avanzada y monitorización constante. 

¿Quieres que te ayudemos a diseñar un plan personalizado? Contacta con nuestro equipo de expertos.

La entrada Cómo desplegar IaC con éxito se publicó primero en Geko Cloud.

Al igual que las VMs, los contenedores actúan como un espacio para aplicaciones en las que estas pueden ejecutarse. Sin embargo, mientras que las VMs replican todo un entorno informático, los contenedores solo incluyen los datos esenciales necesarios para ejecutar la aplicación, como bibliotecas y binarios del sistema operativo. Esto permite una forma de virtualización más ligera. La tecnología de contenedores más conocida es Docker, razón por la cual el término «contenedor Docker» es muy utilizado.

¿Qué son los contenedores Docker?

Los contenedores Docker son unidades encapsuladas que pueden ejecutarse de forma independiente, sin importar dónde se encuentren. Se pueden comparar con contenedores de carga en los que se encuentran aplicaciones como PHP, MySQL y Apache. Para estas aplicaciones, no importa si el contenedor está en Múnich, Nueva York o Sídney, ya que el entorno interno siempre es el mismo, proporcionando condiciones consistentes.

¿Cuál es la diferencia entre máquinas virtuales y contenedores Docker?

Los contenedores se consideran una forma de virtualización más ligera porque, dentro de una instalación del sistema operativo, pueden ejecutarse varios contenedores con aplicaciones aisladas entre sí. Si quisiéramos lograr esta separación mediante virtualización de hardware, tendríamos que iniciar dos VMs completas, incluyendo el sistema operativo, lo que requiere más recursos.

A diferencia de las VMs, los contenedores no emulan el hardware, sino el sistema operativo. Las VMs se ejecutan directamente en un servidor físico virtualizado mediante un hipervisor como VMware ESXi. La virtualización en contenedores ocurre a un nivel superior, sin un hipervisor, utilizando el sistema operativo instalado junto con el motor de contenedores para la virtualización.

¿Cuáles son las ventajas de los contenedores Docker?

Especialmente entre los desarrolladores, esta nueva tecnología es muy popular, ya que los contenedores Docker son más eficientes y consumen menos recursos que las VMs: requieren menos CPU y memoria.

Otra ventaja es su portabilidad. Como paquetes de aplicaciones cerrados, pueden ejecutarse en diversos sistemas. Esto permite su uso no solo para el desarrollo offline, sino también en servidores de producción, independientemente de la infraestructura o plataforma en la nube elegida. Esto resulta en una mayor velocidad y consistencia en el desarrollo, la depuración y las pruebas.

Los contenedores son altamente escalables. Si se necesitan instancias adicionales de una aplicación, por ejemplo, debido a un aumento en el tráfico web, se pueden iniciar y detener fácilmente nuevos contenedores. En cuestión de segundos, se pueden escalar cientos de contenedores hacia arriba o hacia abajo. La gestión de esta gran cantidad puede facilitarse mediante soluciones de orquestación.

¿Qué es la gestión de contenedores?

Para gestionar eficientemente una gran cantidad de contenedores, se requiere una solución de orquestación. Las más conocidas son Kubernetes, Docker Swarm y Amazon Elastic Container Service. Estas soluciones se encargan de iniciar y detener contenedores, colocarlos óptimamente en los nodos de cómputo disponibles y ajustar automáticamente los nodos necesarios según los cambios en la carga.

¿Qué son las imágenes de contenedor?

Las imágenes son la base de los contenedores. Una imagen es un archivo simple que elimina la necesidad de instalar y actualizar software. Las imágenes contienen todos los componentes necesarios para ejecutar una aplicación de forma independiente de la plataforma. Una imagen puede transferirse a otro sistema mediante una simple copia y luego iniciarse como un contenedor.

Las imágenes se almacenan, gestionan y proporcionan a través de un registro. El registro público más conocido es Docker Hub.

¿Cuál es el ciclo de vida de un contenedor?

Una imagen no es inmutable y puede adaptarse según sea necesario. Este proceso de adaptación se conoce como el ciclo de vida del contenedor. Por ejemplo:

• Se descarga una imagen de un registro.

• Al iniciar la imagen en nuestro host Docker, se crea el contenedor real.

• Se pueden realizar ajustes, como agregar componentes adicionales.

• Para almacenar permanentemente los cambios, se crea una nueva imagen a partir del contenedor modificado.

• Finalmente, la nueva imagen se guarda en el registro y puede servir como base para otras extensiones.

¿Qué se debe tener en cuenta?

Algunos consejos y trucos:

• Idealmente, solo se debe implementar un servicio o proceso por contenedor. Las excepciones son válidas cuando las aplicaciones están estrechamente integradas o dependen entre sí.

• No se deben almacenar datos persistentes dentro del contenedor. Los contenedores deben considerarse como «infraestructura inmutable», lo que significa que solo existen mientras realizan una tarea. Al finalizar o desplegar,, todos los datos generados durante el tiempo de ejecución desaparecen. Por lo tanto, los datos persistentes deben almacenarse en volúmenes externos.

• Para una mayor calidad y reutilización, se deben utilizar herramientas de automatización como Terraform, Ansible y Jenkins. Con estas herramientas y siguiendo algunas buenas prácticas, se puede lograr un entorno moderno, dinámico y altamente escalable.

¿Y qué hay del Kubernetes Bundle?

Para sacar el máximo partido a los contenedores Docker en entornos de producción, muchas organizaciones adoptan Kubernetes como sistema de orquestación. Sin embargo, implementarlo y operarlo no es trivial. Aquí es donde entra en juego el concepto de Kubernetes Bundle: un enfoque paquetizado que combina todas las herramientas, configuraciones y buenas prácticas necesarias para desplegar y gestionar Kubernetes de forma segura, eficiente y escalable.

Un Kubernetes Bundle bien diseñado suele incluir:

• Clústeres preconfigurados según las necesidades del negocio (on-premise, cloud o híbrido).

• Integración con sistemas de CI/CD y observabilidad.

• Configuración de políticas de seguridad, acceso y backup.

• Soporte para el despliegue automático de contenedores a través de Helm Charts u operadores personalizados.

En definitiva, si Docker es la base, Kubernetes (y su bundle) es el andamio que lo sostiene en producción a gran escala.

Novedades en el ecosistema Docker y Kubernetes (2025)

El ecosistema de contenedores evoluciona contínuamente. Estas son algunas de las novedades más relevantes:

1. Docker Scout y enfoque en seguridad por defecto
   Docker ha lanzado Docker Scout, una herramienta integrada que permite escanear imágenes en busca de vulnerabilidades y verificar políticas de seguridad antes de hacer un push al registro. Este enfoque shift-left mejora la seguridad desde las fases más tempranas del desarrollo.
2. Kubernetes Gateway API
   Aunque Ingress sigue siendo ampliamente utilizado, la Gateway API ha ganado tracción como sucesor natural. Ofrece una configuración más flexible y moderna para gestionar el tráfico norte-sur, y está respaldada oficialmente por la CNCF.
3. Evolución de las herramientas de orquestación
   Aunque Kubernetes sigue siendo el estándar, herramientas como K3s (una distribución ligera de Kubernetes) y Talos OS (una distro de Linux pensada solo para Kubernetes) están ganando espacio en entornos edge y on-premise por su eficiencia y seguridad.
4. WebAssembly (Wasm) como complemento o alternativa ligera a contenedores
   Wasm ha comenzado a integrarse en entornos de nube nativos. Aunque no sustituye a Docker, puede convivir con contenedores para ejecutar funciones específicas con aún menos recursos, lo que mejora el rendimiento en el edge computing.
5. Automatización avanzada y GitOps
   El enfoque GitOps, con herramientas como ArgoCD o Flux, se ha consolidado como una de las mejores prácticas para la gestión declarativa de clústeres Kubernetes. Esto permite un control de versiones más estricto, despliegues reproducibles y una trazabilidad completa de cambios en producción.
6. Enfoque en plataformas internas de desarrollo (IDP)
   Muchas organizaciones están invirtiendo en Internal Developer Platforms que abstraen la complejidad de Kubernetes para los equipos de desarrollo, usando herramientas como Backstage o Port, lo que agiliza los flujos DevOps sin sacrificar control.

¿Quieres aprovechar al máximo las oportunidades de Docker y Kubernetes? Contacta con nuestro equipo de expertos.

La entrada ¿Cómo funcionan los contenedores Docker? se publicó primero en Geko Cloud.

En este artículo te explicamos paso a paso cómo realizar una migración a Azure con éxito, qué estrategias puedes seguir y qué beneficios aporta para el rendimiento y la eficiencia de tu infraestructura.

¿Por qué migrar tu infraestructura IT a Microsoft Azure?

Migrar a Azure no es una tendencia, sino una respuesta lógica a los retos que enfrentan las organizaciones con infraestructuras locales o entornos virtualizados tradicionales (como VMware). Las razones principales para iniciar una migración a la nube de Azure son:

• Optimización de costes: Azure permite pagar solo por lo que se usa, evitando gastos fijos de mantenimiento y hardware.
• Escalabilidad: la infraestructura IT se adapta automáticamente a la carga de trabajo.
• Alta disponibilidad: los servicios cloud garantizan continuidad operativa.
• Seguridad reforzada: con herramientas nativas de ciberseguridad y cumplimiento normativo.
• Mayor eficiencia operativa: automatización de tareas, actualizaciones y backups.

Fases clave en una migración a Azure

1. Evaluación del entorno IT actual

Antes de iniciar el proceso de migración a Microsoft Azure, es fundamental auditar tu infraestructura: servidores, bases de datos, aplicaciones y dependencias. Esta evaluación ayuda a definir qué cargas están listas para migrar y cuál es la mejor estrategia en cada caso.

2. Diseño de la arquitectura en la nube (landing zone)

La landing zone en Azure establece las bases de red, seguridad y gobernanza. Un diseño sólido garantiza un entorno escalable, seguro y preparado para el crecimiento del negocio.

3. Migración de cargas de trabajo

Existen diferentes enfoques según el nivel de complejidad:

• Rehost (Lift & Shift): traslado directo de servidores a máquinas virtuales en Azure.
• Replatform: ajustes mínimos para aprovechar servicios cloud (como Azure SQL).
• Refactor o rebuild: rediseño completo de aplicaciones para una arquitectura nativa en la nube.

Se pueden migrar entornos Windows, bases de datos SQL y también servidores Linux utilizando herramientas como Azure Migrate.

4. Validación, pruebas y despliegue

Antes de pasar a producción, es necesario validar el rendimiento, la seguridad y la integración con otros sistemas. Esta fase incluye pruebas en entornos de staging (preproducción) y ajustes según el feedback técnico.

5. Gestión y optimización post-migración

Una vez completada la migración a Azure, el entorno debe mantenerse optimizado. Esto implica monitorización, escalado automático, gestión de costes y actualizaciones continuas. Muchas organizaciones optan por apoyarse en servicios gestionados de Azure ofrecidos por partners especializados, como Geko.

Beneficios de una migración a Azure bien ejecutada

Las empresas que migran su infraestructura IT a Azure destacan los siguientes beneficios:

• Reducción de costes operativos.
• Mejora en el rendimiento de aplicaciones críticas.
• Mayor agilidad para lanzar nuevos servicios.
• Seguridad avanzada y cumplimiento normativo.
• Liberación de recursos internos para tareas de mayor valor.

Migrar a Azure es una decisión estratégica

Una migración a Azure bien planificada permite a las empresas transformar su modelo de IT, mejorar la eficiencia y prepararse para los retos digitales del futuro. Con una estrategia adecuada y el acompañamiento de un socio experto, esta transición se convierte en una ventaja competitiva.

Desde Geko te ayudamos a definir la mejor estrategia de migración, con un enfoque personalizado y servicios gestionados para garantizar el éxito del proyecto. 

Si quieres saber más, contacta con nuestros expertos.

La entrada Migración a Azure: cómo optimizar tu infraestructura IT en la nube se publicó primero en Geko Cloud.

¿Qué es el AWS Well-Architected Framework?

AWS Well-Architected Framework es una herramienta para evaluar y mejorar las arquitecturas de la nube. Se basa en seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia en el desempeño, optimización de costes y sostenibilidad. El marco proporciona las mejores prácticas y pautas para diseñar y operar entornos seguros, eficientes y rentables en la nube de AWS.

¿Cómo migrar a AWS?

Los desafíos de migrar a la nube de AWS varían desde detalles técnicos hasta requisitos regulatorios. El marco de buena arquitectura de AWS permite identificar obstáculos de forma temprana y abordarlos de manera eficaz. Más allá de una simple tarea técnica, el uso de la nube se considera no solo como una tarea técnica, sino también como parte de la estrategia corporativa. 

Por esta razón, las organizaciones que adoptan una visión holística de la implementación y operación de sus servicios en la nube están mejor posicionadas para afrontar con éxito tanto los desafíos inmediatos como los objetivos comerciales a largo plazo.

Los seis pilares de un marco de buena arquitectura AWS  

El AWS Well-Architected Framework se estructura en seis pilares centrales, cada uno de los cuales aborda aspectos específicos de la arquitectura en la nube. Gracias a esta división, las empresas pueden crear un entorno robusto y eficiente.

• Excelencia operativa: apoyar y optimizar las operaciones para lograr mejores procesos de negocio a través de la automatización y flujos de trabajo optimizados.
• Seguridad: garantizar la protección de los datos y sistemas, con especial atención a la evaluación de riesgos, la integridad de los datos, la confidencialidad y la disponibilidad.
• Fiabilidad: sistemas robustos que permanecen estables incluso ante eventos inesperados y pueden recuperarse rápidamente.
• Eficiencia en el rendimiento: seleccionar los recursos y tecnologías adecuados y adaptar el rendimiento del sistema a los requisitos cambiantes.
• Optimización de costes: controlar el consumo de recursos y los costes para garantizar que las inversiones creen valor.
• Sostenibilidad: minimizar el impacto ambiental de las cargas de trabajo en la nube, reduciendo el consumo de energía y las emisiones de carbono.

Al aplicar estos principios, AWS Well-Architected Framework ayuda a las organizaciones a crear un entorno de nube de última generación.

¿Cómo debe ser el marco de buena arquitectura de AWS? 

El marco de buena arquitectura de AWS y el modelo de responsabilidad compartida son dos caras de la misma moneda. Mientras que el primero proporciona los principios y mejores prácticas para diseñar y operar una arquitectura de nube eficiente, el segundo define claramente las responsabilidades de AWS y sus clientes. 

Responsabilidad de AWS:

• Seguridad física de los centros de datos.
• Integridad de los dispositivos de red.
• Fiabilidad del hardware del host.
• Seguridad de la infraestructura global que respalda la disponibilidad de los servicios de AWS.

Responsabilidad del cliente:

• Implementación de la gestión del control de acceso.
• Cifrado de datos.
• Funcionamiento seguro de las aplicaciones.
• Gestión eficaz de parches y configuraciones de sistemas operativos y aplicaciones.

Si se malinterpreta el modelo de responsabilidad compartida, pueden generarse brechas en el cumplimiento y la seguridad. Por el contrario, los clientes que implementan este enfoque reducen los riesgos y logran un alto nivel de seguridad. 

El marco Well-Architected complementa este modelo proporcionando pautas claramente definidas para diseñar las tareas del cliente.

El marco Well-Architected para optimizar el rendimiento, la seguridad y los costes

El AWS Well-Architected Framework ha demostrado su eficacia para muchas empresas. Es el punto de partida para conceptos de seguridad mejorados y permite un importante ahorro de costes. Los siguientes ejemplos muestran cómo las empresas optimizan su infraestructura en la nube utilizando el marco.

Ejemplos de excelencia operacional:

• Las empresas pueden implementar pruebas de carga automatizadas para verificar el rendimiento de su arquitectura de nube en diferentes escenarios. Esto ayuda a identificar cuellos de botella de forma temprana y optimizar toda la infraestructura para lograr un rendimiento óptimo bajo alta carga.
• Al establecer KPI detallados, las empresas pueden monitorear continuamente el rendimiento de su arquitectura en la nube. Analizar estos datos ayuda a identificar tendencias y realizar optimizaciones proactivas para mejorar continuamente la eficiencia.

Ejemplos de mejoras de seguridad:

• La automatización de pruebas garantiza el cumplimiento de las políticas de seguridad. Los scripts proporcionados por el marco comprueban automáticamente las configuraciones durante las actualizaciones. Las vulnerabilidades se identifican y resuelven rápidamente antes de que lleguen a producción.
• Las pruebas de penetración ayudan a las empresas a evaluar la seguridad de su nube. Las pruebas identifican riesgos de seguridad ocultos a través de ataques simulados. De esta forma se mejoran continuamente los mecanismos de protección para hacer frente a las ciberamenazas.

Ejemplos de ahorro de costes:

• Dirigir la asignación de recursos a áreas críticas para el negocio aumenta la eficiencia de los costos operativos y mejora el ROI (retorno de la inversión).
• Las directrices marco para la gestión de recursos permiten a las empresas hacer un uso óptimo de sus recursos. Al escalar hacia arriba o hacia abajo según la carga de trabajo, se pueden optimizar los costos y gestionar los picos de carga.

Los escenarios ilustran cómo el  Well-Architected Framework ayuda a desarrollar enfoques personalizados que se adaptan a las necesidades específicas de las empresas.

Los partners de AWS como clave del éxito

Al adoptar el AWS Well-Architected Framework, existen obstáculos que pueden obstaculizar el progreso. A pesar de los beneficios del AWS Well-Architected Framework, las empresas pueden enfrentar obstáculos que dificultan su implementación. Por ello, colaborar con un partner de AWS resulta clave para maximizar su aprovechamiento. Además, esto les permite acceder a conocimientos especializados y una serie de otras ventajas:

• Conocimiento experto profundo: los partners de AWS tienen un conocimiento integral de los servicios y arquitecturas de AWS. Están familiarizados con los últimos avances y le ayudarán a crear un entorno de nube preparado para el futuro.
• Estrategias de implementación a medida: la implementación no es una solución única para todos, sino que requiere un enfoque individual. Los partners de AWS comprenden los desafíos específicos de cada negocio y ofrecen estrategias personalizadas.
• Acceso a los recursos de AWS: los partners de AWS tienen acceso privilegiado a sus recursos, herramientas y opciones de soporte. Esto abarca desde soporte técnico hasta materiales de capacitación y documentación de mejores prácticas.
• Aumenta la eficiencia y reduce los costes: con sus muchos años de experiencia en proyectos, los partners de AWS pueden ayudar a aumentar el rendimiento del entorno. Ayudan a identificar y eliminar costos innecesarios.
• Mitigación de riesgos: los partners de AWS están familiarizados con los errores comunes al implementar el marco. Ayudan a identificar problemas antes de que tengan un impacto en el negocio.

Como partners de AWS desde hace tiempo, Claranet y Geko combinamos experiencia y conocimientos en tecnologías de la nube con un profundo entendimiento del ecosistema de AWS. Esto garantiza una optimización eficiente del entorno y una migración sin problemas a la infraestructura existente.

¿Quieres aprovechar al máximo las oportunidades del AWS Well-Architected Framework? Contacta con nuestro equipo de expertos. 

La entrada Cómo migrar a la nube con AWS Well-Architected Framework se publicó primero en Geko Cloud.

Introducción a SSM

SSM son las siglas de Systems Manager, un conjunto de herramientas que nos facilitan la vida, no sólo para acceder a las máquinas a través de una consola virtual, sino también para la ejecución de comandos remotos, extraer registros de los equipos, y como no, aplicar actualizaciones.

Con la suite de programas de SSM se pueden actualizar no sólo instancias EC2, si no también equipos on-prem, así como máquinas virtuales, equipos on-the-edge (IoT) como raspberrys, etc.

Systems Manager es un servicio que ejecuta un agente en el propio equipo (ec2 / on-prem, etc), del mismo modo que los agentes virtuales en entornos VMware, usados para extraer métricas de las instancias, pero en el caso de SSM la consola de gestión es remota, o lo que es lo mismo, se encuentra dividida en diferentes end-points. Es por ello por lo que el agente debe comunicarse con el servicio de SSM a través de red. Los equipos que quieran ser gestionados, deberán tener no sólo el agente instalado sino también conectividad de red para llegar a los endpoints de AWS SSM.

En este artículo hemos usado un par de instancias EC2 , una Linux y otra Windows:

Para la Linux hemos usado una AMI de RedHat, y en el caso del equipo Windows, se trata de la versión 2019.

Novedades de AWS Systems Manager (SSM) y Patch Manager 2024

AWS ha lanzado nuevas actualizaciones que mejoran la automatización y escalabilidad de SSM, haciendo que el parcheado en entornos multi-cloud y on-premise sea aún más eficiente. Entre las novedades destacan:

• Optimizaciones en tiempos de parcheado: Se ha mejorado la velocidad de instalación y actualización de parches, lo que reduce significativamente las ventanas de mantenimiento.
• Compatibilidad ampliada: AWS Systems Manager ahora soporta un mayor número de sistemas operativos, permitiendo gestionar más entornos desde una sola interfaz.
• Actualización automática de agentes: Una nueva funcionalidad permite actualizar el agente SSM de manera automática, garantizando que las máquinas gestionadas siempre operen con la versión más segura y eficiente del software.

Role para SSM

Para que el equipo pueda comunicarse con SSM, es necesario disponer de un role. Por ello vamos a generar un “service role” nuevo, accediendo al apartado IAM y seleccionado la opción “Roles” y clicando en el botón “Create role”:

Seleccionamos como “Trusted entity” el “AWS Service”, y abajo en el apartado “Use case”, el servicio EC2. Seleccionamos siguiente y añadimos las políticas que son necesarias:

Para ello introducir en la casilla de búsqueda el nombre “ssm”, y escoger entre las opciones que aparecen la “AmazonSSMManagedInstanceCore”

Asignamos el nombre que deseemos y nos aseguramos de que en el apartado de “trusted entities”, el valor de “principal” seleccionado es el servicio “ec2.amazonaws.com”, servicio con el que se va a invocar este role y al que estamos dando permiso:

El siguiente paso será añadir este role a las instancias. El modo más sencillo será marcar desde el panel la instancia a modificar, tal como se muestra en la imagen.

En el desplegable asignarle el role que acabamos de crear.

Nuevas amenazas de seguridad y la importancia del parcheado

En 2023, una serie de vulnerabilidades críticas, como la CVE-2023-30799, demostraron cómo los ataques a sistemas desactualizados pueden comprometer rápidamente la seguridad de las empresas. Esto subraya la importancia de mantener todos los equipos parcheados para mitigar riesgos. Los ciberataques que explotan vulnerabilidades en sistemas operativos, software empresarial y aplicaciones no solo generan pérdidas económicas, sino también daño a la reputación de la empresa.

La gestión de parches se convierte en una primera línea de defensa. Tener un sistema centralizado como AWS Patch Manager garantiza que no se pasen por alto actualizaciones críticas, eliminando puntos débiles.

Mejores prácticas en el parcheado de equipos

Hoy en día, la automatización inteligente y el uso de herramientas basadas en inteligencia artificial son tendencias clave en la gestión de parches. Algunas de las mejores prácticas incluyen:

• Priorizar parches con IA: Herramientas basadas en inteligencia artificial pueden analizar vulnerabilidades y recomendar qué parches son más urgentes, reduciendo la sobrecarga operativa y minimizando el riesgo de ataques.
• Simulación de vulnerabilidades: Realizar simulaciones para entender cómo una vulnerabilidad podría impactar a la organización permite priorizar la aplicación de parches. Las organizaciones pueden usar estas simulaciones para ajustar sus cronogramas de parcheado, asegurándose de que los sistemas críticos están protegidos primero.
• Pruebas en entornos de desarrollo: La implementación de canary testing es ahora más común. Con esta técnica, los parches se aplican primero en entornos de prueba antes de su implementación en producción, reduciendo el riesgo de interrumpir servicios críticos.

Automatización de la aprobación de parches: Para evitar el impacto negativo de parches no probados, se puede configurar la aprobación automática escalonada, donde los parches se aprueban para ciertos entornos (como desarrollo o pruebas) antes de ser aplicados en producción.

Instancias EC2 / managed nodes

En nuestro caso, hemos desplegado un equipo RedHat para la variedad Linux por un motivo: las AMI oficiales distribuidas por RedHat no llevan incorporado el agente, mientras que las AMI de Windows distribuidas por Microsoft o las AMI de Amazon Linux sí lo tienen.

La nueva funcionalidad de actualización automática de agentes permite que los equipos gestionados siempre cuenten con la última versión del agente SSM, lo cual mejora la eficiencia del parcheado y la seguridad de los nodos.

En caso de que nuestra distribución no tenga el agente, se puede instalar manualmente. Puedes revisar el siguiente enlace para ver qué distribuciones están soportadas:

Manual de instalación del agente SSM

Fleet Manager

Ahora que ya tenemos los equipos con el agente de SSM instalado y con el “service role” asociado, podríamos acceder al apartado de “fleet manager”, lugar donde se visualiza a modo de registro los equipos gestionados con SSM, tanto equipos EC2, como equipos on-prem, etc. Esta herramienta está dentro de las opciones de SSM:

Los equipos gestionados a través de SSM, reciben el nombre de nodos, es por ello por lo que, en la vista de este servicio, los equipos registrados se identifican en la columna de “Node Id”:

Los equipos que aparecen son los que están registrados en la región actual. Tener en cuenta que AWS SSM es un servicio regional, eso quiere decir que si tenemos una cuenta en varias regiones, será necesario repetir el proceso descrito en este artículo para cada región de manera independiente.

Como todo software, el agente de SSM recibe constantes mejoras. Es por ello recomendable habilitar en el apartado “settings”, la actualización automática:

Impacto en cumplimiento normativo

El parcheado constante también es fundamental para cumplir con normativas de seguridad como GDPR y las nuevas regulaciones de protección de datos. Empresas de todo el mundo deben asegurarse de que sus sistemas estén protegidos contra vulnerabilidades que podrían exponer información confidencial. El mantenimiento regular de sistemas y la capacidad de auditar el historial de parches aplicados se han vuelto componentes clave en auditorías de cumplimiento.

Tendencias recientes en ciberseguridad y parcheado

El enfoque Zero Trust ha ganado popularidad como estrategia de seguridad. Este modelo asume que ninguna entidad, dentro o fuera de la red corporativa, es de confianza, lo que hace que el parcheado continuo y la actualización de todos los sistemas sea aún más crucial. Con la federación de entornos multinube y la dispersión de recursos en diferentes plataformas, Patch Manager facilita la gestión centralizada de parches en un ecosistema diverso.

Baselines

Las “baselines” son manifiestos que definen un determinado nivel de cumplimiento con una política de seguridad. En el servicio de “patch manager” existen diferentes “baselines”, pero es muy recomendable crear propia una con las configuraciones que nos interese. Es un proceso realmente sencillo.

Para acceder al apartado de las “baselines”, ir a “Node Management” y seleccionar la opción “Patch Manager”:

Y en la pantalla que aparece acceder al botón “View predifined baselines”

En la vista de “baselines”, aparecen muchísimas, cada una para un sistema operativo diferente. Es en este momento cuando vamos a crear una personalizada. Para ello clicar sobre el botón “Create patch baseline”

En el nuevo apartado, seleccionar un nombre y una familia de SO que va a estar asociada a la “baseline”:

Definir la versión del SO, así como otros aspectos que definirán el nivel de cumplimiento:

Hay opciones como el “auto approval”, que permiten aprobar la instalación de una determinada actualización, al cabo de unos días de su publicación, o a partir de una determinada fecha, evitando así que parches día 0, no muy testeados, pudieran romper la estabilidad de los equipos. Incluso esto permitiría tener equipos de PRE o TEST donde instalar parches días antes que en los equipos de producción a modo de “canary testing”.

Igual de importante es el apartado de excepciones de paquetes. Con ello se evita la instalación de determinados paquetes que pueden romper el servicio (sistemas con kernels compilados a mano, paquetes Windows que no se llevan bien con algún otro programa de terceros, etc).

Para añadir excepciones debe usarse el siguiente formato:

En este momento ya tenemos una “baseline” propia. Cuando las “baselines” son propias, para encontrarlas luego, hay que especificar que el propietario somos nosotros. Para ello en el buscador de baselines, especificar “Owner: Self” tal como se muestra a continuación:

De lo contrario la vista por defecto sólo muestra “baselines” estándar provisionadas por AWS.

Patch groups

Una vez tenemos definidas las “baselines”, vamos a definir los “patch groups”. Un “patch group” establece la relación entre las “baselines” y los equipos sobre los que se van a aplicar, en función del valor de un tag que especificaremos más tarde en los equipos.

Para crear un “patch group”, es muy sencillo, sólo tenemos que seleccionar la “baseline” que acabamos de crear, desplegamos el menú “Actions” y seleccionamos la opción “Modify patch groups”

Se abrirá un apartado para generar los patch groups, introduciendo un nombre. En nuestro caso “Windows_Production”

Una vez introducido el nombre, fijándonos en respetar la nomenclatura, clicamos en el botón “Add” y cerramos el asistente.

Tags

Los tags son metadatos que nos ayudan a identificar a quien pertenece un recurso, una unidad de imputación de costes, etc. En este caso, con los tags también podemos asociar los nodos a los “patch groups” correspondientes. Para ello se usa siempre el mismo valor de tag “Patch Group”. Ojo! Es “case sensitive”

Vamos al apartado de las instancias, seleccionamos una de ellas, y editamos el apartado de tags para añadir el de “Patch Group”:

Si al introducir el tag, nos encontráramos con un error de tipo “’Patch Group’ is not a valid tag key.”

Es necesario deshabilitar la check box de metadata tagging en la configuración de la instancia:

Dejar la casilla siguiente deseleccionada y volver a probar a añadir el tag en el equipo.

Maintainance Windows

Recapitulemos. En este momento ya tenemos la instancia con el agente de SSM instalado y el role para interactuar con el servicio. Hemos creado una “baseline” propia, y luego la hemos asignado a unos “patch groups”. Finalmente hemos “tageado” las instancias con un tag que apunta directamente al “pach group” que nos interesa.

Las ventanas de mantenimiento son un apartado importante porque no sólo contiene la calendarización de las actualizaciones, sino también el listado de ejecuciones.

Vamos a proceder creando una ventana de mantenimiento a través del siguiente apartado:

Debemos introducir el nombre para la ventana, y fijar el cron. Se pueden establecer expresiones de cron con la nomenclatura típica o bien seleccionando las preestablecidas de cada hora o cada día.

Los valores de “Duration” y “Stop initiating task”, son obligatorios, y es recomendable dejarlos con unos valores como los siguientes:

Finalmente escoger zona horaria para hacer coincidir los horarios de la ventana con la que nos interese.

Al terminar tendremos un listado de las ventanas programadas, y datos interesantes como su próxima ejecución:

Configuración del parcheado

En este momento vamos a realizar el proceso que aglutina todos los pasos anteriores, y que capacita a “patch manager” para realizar las actualizaciones de los sistemas. Para ello acceder al apartado de “Patch Manager” y clicar en “Configure Patching”

Escoger los “patch groups” que se quieran actualizar:

Escoger la ventana de mantenimiento que se ha creado en el paso anterior:

Y dejar la operación que más se ajuste a lo que queremos hacer. En este caso vamos a escoger “Scan and Install”

En este momento, en el “dashboard” de de “Patch Manager”, deberíamos tener una vista de equipos pendientes de actualizar. Los valores en este apartado irán cambiando en función de si hay paquetes pendientes, fallos en las actualizaciones, etc.

Para poder realizar un seguimiento de las acciones realizadas, las podemos consultar en el “Run Command”

En este apartado hay dos pestañas. Una con los comandos en ejecución en este momento, que saldrán con un reloj al lado:

Y otra pestaña con el histórico de acciones:

Si en el proceso de instalación de actualizaciones, hay algún paquete marcado como reinicio necesario, el equipo se reiniciará inmediatamente. Tener esto en cuenta para establecer las ventanas de acuerdo con las necesidades del negocio:

Tras la instalación de los parches, y los reinicios en caso de haberlos, en el “dashboard” de “Patch Manager” saldrán ahora las instancias como conformes de acuerdo a las “baselines” establecidas:

Cloudwatch

En la consola del histórico de comandos, podemos ver las tareas ejecutadas, como en este caso. Si clicamos sobre el id de la tarea, podemos acceder a su detalle:

Dentro podemos ver los equipos sobre los que se ha ejecutado la acción, y podemos , seleccionando uno de esos equipos, ver el detalle de las operaciones. Para ello seleccionar y clicar sobre el botón “View output”

Las operaciones van probando todas las plataformas, por ello primero intentarán ejecutar el parcheado sobre un Windows, luego sobre un Linux y finalmente sobre un MacOS. Por ello para ver el estado de las actualizaciones, escogemos la plataforma del equipo que estamos consultando.

En la ventana “Output” veremos el registro, pero a menudo este se trunca por ser excesivamente largo:

Si queremos consultar esos datos podemos enviarlo a un “log group” de Cloudwatch. Para ello, primero vamos a CloudWatch y creamos un “log group”:

Ponemos un nombre y especificamos el periodo de retención.

El segundo paso es modificar el role de la máquina para que tenga permisos para escribir en Cloudwatch, por ello habrá que añadir una “in-line policy” como esta:

Le ponemos un nombre a esta “policy” y la guardamos:

Quedando el role del equipo como:

Volvemos a system manager, apartado “Mantainance Window”  y dentro de las tareas (marco la tarea y selecciono edit):

Y en el apartado “Output Options” , escribir el nombre del log group a donde lo vamos a enviar:

Guardamos los cambios, y a partir de ahora al seleccionar el output de las tareas, veremos que nos aparece un enlace hacia Cloudwatch:

Y si consultamos ese enlace, nos llevará a la información de salida, pero ya sin truncar:

Con las mejoras recientes de AWS Systems Manager y Patch Manager, la gestión de parches se ha vuelto más eficaz, abarcando más sistemas operativos y mejorando la seguridad a través de la actualización automática de agentes. Estas mejoras, combinadas con buenas prácticas y la automatización, permiten a las organizaciones mitigar riesgos de seguridad y cumplir con las normativas más estrictas, garantizando la continuidad de sus operaciones. 

¿Quieres saber más? Contacta con nuestro equipo

La entrada Parcheado de equipos con Patch Manager se publicó primero en Geko Cloud.

• Información: saber en qué se ha gastado el dinero, es decir, visibilidad/asignación de costes.
• Optimización: optimizar los costes mediante la reducción de tarifas/estrategia de reducción de escala/…).
• Operar: mejora continua y supervisión de su estrategia FinOps, y automatización.

Para cada fase, intentaremos describir los conceptos clave y el mejor enfoque, en función del proveedor de cloud (principalmente Amazon Web Services y Microsoft Azure) y del entorno del cluster (producción/no producción).

Informar

En el mundo de Kubernetes y especialmente con los servicios gestionados, asignar costes puede ser una auténtica pesadilla porque para hacerlo bien hay que tener en cuenta e identificar múltiples recursos: por un lado, respecto a Kubernetes como los pods, pero también a nivel del proveedor Cloud (y teniendo en cuenta costes como balanceador de carga/nodo/almacenamiento/red/…)

La asignación de costes es el proceso de dividir facturas y asociar cada parte a un centro de costes, que podría ser una aplicación/departamento/equipo e intentar obtener la mayor precisión posible. De este modo, se obtiene una mayor visibilidad de los costes. En un entorno de nube, esto no es fácil porque algunos recursos se comparten entre muchos centros. Por otro lado, también hay que gestionar descuentos como reservas, ancho de banda de red y muchos otros elementos.

Para lograrlo, se utilizan etiquetas para identificar al propietario de los recursos (por ejemplo, aplicación1) y, a continuación, es necesario establecer una estrategia adicional para asignar los elementos no etiquetados.

Además, los proveedores cloud cobran a nivel de host (con la excepción de AWS EKS que se ejecuta en modo Fargate completo y GKE Autopilot), no a nivel de contenedor. Por lo tanto, debe asignar una cantidad determinada de recursos de host (vCPU/Memoria/…) a cada contenedor y, a continuación, resumirla en función de su estrategia de aplicación de etiquetas. También debes tener en cuenta los «costes compartidos», como el coste primario de Kubernetes, y los «costes ociosos» (porcentaje de recursos de host no utilizados). No puedes utilizar el servicio de gestión de costes de un proveedor de nube común, como AWS Cost Explorer o Azure Cost Management, para crear la distribución de costes.

Utilizar una herramienta de terceros como Cloudhealth podría ser útil en tu tarea de distribución de costes, pero la realidad es que tiene un coste elevado, a menos que puedas utilizar herramientas como Kubecost para obtener una estimación de la distribución de costes (funciona con AWS y GCP).

No existe una estrategia única que funcione en todos los casos, tienes que encontrar la que mejor se adapte a tu caso de uso. Estas son algunas de las pautas:

1. Hay que definir una estrategia de etiquetado. Debe ser la misma que la definida respecto al proveedor de la nube.
2. Utiliza Kubernetes Labels con tu estrategia de etiquetado definida para la asignación de costes.
3. Agrupa contenedores mediante espacios de nombres de Kubernetes para simplificar la asignación de costes.

Optimizar

La fase de optimización se centra en los procesos de reducción de costes. Algunos de ellos pueden aplicarse independientemente del proveedor de la nube, pero otros dependen de especificaciones.

Podemos agrupar las optimizaciones en cuatro categorías:

1. Rightsizing: asignar la cantidad adecuada de recursos (vCPU/Memoria) a hosts y pods.
2. Off-hours: desconectar o reducir recursos durante las noches y los fines de semana.
3. Spot node: utilizar instancias spot para nodos Kubernetes.
4. Reserva de nodos: comprar una instancia/máquina virtual (o planes de ahorro para AWS).

A modo de guía rápida, te compartimos el siguiente diagrama, en el que puedes encontrar el orden de las optimizaciones recomendadas en función del entorno del cluster (producción o no producción):

Redimensionar

El redimensionamiento puede realizarse a nivel de pod/contenedor y/o a nivel de host/nodo.

Nota: redimensionar significa ajustar las capacidades de los recursos, pero también añadir/eliminar recursos idénticos.

Contenedor

En el mundo de los contenedores, existen varias estrategias de escalado: Escalado horizontal (HPA)

Al igual que un grupo de autoescalado de EC2 o Azure VMSS, el escalado horizontal tiene como objetivo añadir o eliminar recursos (pods en este caso) para mantenerse al día con la carga de trabajo actual.

Kubernetes Horizontal Pod AutoScaling está diseñado para aplicaciones sin estado, que pueden iniciarse rápidamente para gestionar picos de uso y detenerse con elegancia.

Escalado vertical (VPA)

A diferencia del escalado horizontal, que añade o elimina pods, el escalado vertical puede aumentar o disminuir los recursos de los pods (CPU/Memoria) tras un periodo de evaluación.

El autoescalado vertical de Kubernetes es especialmente útil para ajustar las demandas de CPU y memoria al consumo real de los contenedores. A menudo, las demandas de los contenedores están sobredimensionadas, desperdiciando recursos.

VPA puede ajustar automáticamente los recursos de los contenedores. Sin embargo, no  es recomendable. Tómalo como consejo y luego ajusta tus definiciones de recursos de Kubernetes. 

Redimensionamiento de nodos

Tus pods utilizan recursos de nodo, por lo que cuando utiliza HPA o VPA, es obligatorio poder ajustar su capacidad.

El Kubernetes Cluster Autoscaler puede añadir o eliminar nodos para optimizar la capacidad de los recursos del cluster.

El PodDistruptionBudget es un elemento esencial cuando se activa el cluster Autoscaler para evitar el tiempo de inactividad de la aplicación.

Otro concepto importante relativo al escalado de nodos es la coherencia con la carga de trabajo. Esto significa que se debe tener en cuenta la relación CPU/memoria de su nodo para evitar tener demasiada memoria o CPU sin utilizar. Por ejemplo, tus pods consumen más memoria que CPU, pero la capacidad de los nodos es más o menos igual. En este caso, estarás malgastando recursos de CPU y aumentando el coste de tu infraestructura. Para evitarlo, cambia el tipo de instancia de nodo a una instancia optimizada para memoria.

Para detectar el problema de coherencia con la carga de trabajo, comprueba el «uso solicitado de CPU» y el «uso solicitado de memoria». Por ejemplo, tienes un problema si el «uso de CPU» es del 100% mientras que la «demanda de memoria» es solo del 50%.

Fuera de horario

Fuera de hora significa detener o reducir la capacidad de los recursos por la noche (y los fines de semana). Para los entornos que no son de producción, debería ser la norma.

Parar los recursos entre las 8 de la tarde y las 7 de la mañana y los fines de semana tiene una ventaja, y es que reduce el coste en un 60%. 

kube-downscaler es el punto de entrada para clusters de producción y no producción (debe combinarse con Cluster Autoscaler para ahorrar dinero).

Este proyecto de código abierto reducirá los despliegues/clusters estáticos/HPA basándose en políticas definidas (tiempo/no conforme con condiciones de exclusión como la restricción del espacio de nombres).

Producción

En un entorno de producción, debes asegurarte de que, incluso fuera de las horas de trabajo, tu cluster/aplicación cliente permanece altamente disponible y tolerante a fallos:

• Tiene al menos 2 réplicas de cada aplicación crítica.
• Distribuidas en al menos 2 nodos.

No se trata realmente de horas valle, sino de una reducción de escala cuando disminuye la carga del cluster.

No producción

Un cluster que no sea de producción debería poder escalarse hasta 0 trabajadores, pero con los clusters Kubernetes gestionados, algunos servicios en la nube tienen limitaciones (ver más abajo).

cluster-turndown es un proyecto de código abierto que facilita la realización de operaciones fuera de producción. Actualmente, el proyecto es compatible con GKE, EKS y KOPS en AWS.

AWS EKS

Puedes reducir el número de trabajadores (grupo administrado o no administrado) a 0, pero no olvides que AWS sigue cobrando por la administración del cluster.

AZURE AKS

Azure AKS es diferente a AWS porque Azure no cobra por la gestión del cluster (a menos que añadas la opción uptime SLA.sta opción no tiene sentido para un cluster que no sea de producción), pero no puedes reducir el grupo de nodos por defecto (sistema) a 0.

El coste depende del tamaño de la máquina virtual. Para los pools de trabajadores, puedes reducirlos a 0.

Nodo spot 

Los Spot Nodes son otra buena forma de reducir el coste de los clusters Kubernetes. En general, las instancias/máquinas virtuales spot son recursos «normales» que se benefician de un descuento significativo. Pero este descuento tiene un inconveniente: los proveedores de la nube no garantizan la disponibilidad de estos recursos. Pueden interrumpirse en cualquier momento.

Esto significa que las aplicaciones en ejecución deben ser tolerantes a fallos para un entorno de producción (fuera de producción, esto no es obligatorio, pero debes aceptar el riesgo de tiempo de inactividad hasta que un nuevo nodo esté listo).

Cada proveedor de nube ofrece una forma de recibir una notificación (API de metadatos local) unos segundos/minutos antes de que el nodo se apague. Esto mitiga el impacto del apagado del nodo.

Para utilizar con éxito los nodos spot, es ideal considerar el uso de:

• node affinity y anti-affinity (identificar pods que puedan soportar/desplegarse en nodos spot).
• Kubernetes cluster-autoscaler con la función de expansión del cluster-autoscaler (para volver automáticamente al tipo bajo demanda si no hay más spots disponibles).
• la función MixedInstancePolicy de cluster-autoscaler  [toma diferentes instancias (deben tener la misma capacidad de CPU y Memoria) para mejorar la disponibilidad de Spots. Exr5.2xlarge/r5a.2xlarge/r5d.2xlarge/r5ad.2xlarge/i3.2xlarge)] – solo AWS

AWS anunció la compatibilidad con instancias spot en un grupo de nodos administrados. Con esta nueva característica, el drenaje de nodos y la estrategia de instancias spot son gestionados por AWS. Además, ofrece unaestrategia de asignación de capacidad optimizada yreequilibrio de capacidad, dos características interesantes para los grupos de Spot AutoScaling.

Azure tiene algunas limitaciones/condiciones para utilizar los nodos spot:

• El pool de nodos por defecto (sistema) no admite Spot Nodes (y debe tener al menos 1 VM). 
• No puede mezclar nodos estándar y nodos spot en el mismo pool de nodos.
• Debe crear uno (o más) pool de nodos estándar y otro (o más) pool de nodos spot.

Producción

El consejo más común para utilizar nodos spot en un cluster de producción es distribuir la capacidad de nodos entre nodos bajo demanda/estándar y nodos spot para evitar sufrir un apagado completo si los nodos spot no están disponibles. La distribución depende principalmente de las aplicaciones alojadas.

Por ejemplo, la distribución podría ser

• 30% Spot – 70% A la carta/Estándar
• 50% Spot – 50% A la carta/Estándar
• 70% Spot – 30% A la carta/Estándar

Fuera de producción

En un entorno fuera de producción, la estrategia de distribución puntual puede ser mucho más agresiva que en producción, ya que no es necesaria una disponibilidad absoluta. Incluso puede apuntar a la distribución solo con nodos puntuales. En caso contrario, como en un entorno de producción, elige un equilibrio entre bajo demanda/estándar y puntual.

Producción

Para un cluster de producción debes iniciar el proceso de reserva lo antes posible. Puedes empezar poco a poco reservando solo, por ejemplo, el 10% de tu capacidad e ir reservando más con el tiempo.

AWS

Utilizar AWS Fargate (parcial o totalmente) es una elección fácil, ya que solo los planes de ahorro informático pueden cubrir tanto EC2 como Fargate.

Alternativamente, si tienes una mezcla de instancias On-Demand y Spot, puedes elegir cubrir el 100% de tu On-Demand y si no tienes una instancia Spot, depende de la carga del cluster. 

Azure

El punto de partida es comprar máquinas virtuales reservadas para el conjunto de nodos por defecto (sistema). Si tienes una mezcla de instancias Standard y Spot, puedes elegir cubrir el 100% de tu instancia Standard y si no tienes una instancia Spot, depende de la carga del cluster.

Con la función de cancelación de reservas, puedes ser realmente agresivo en la cobertura de reservas, ya que el punto de equilibrio se alcanza rápidamente (los gastos de cancelación son sólo el 3% de los gastos de reserva restantes). Consulta la documentación de Azure para obtener más información.

No producción

AWS

Si no ejecutas tu cluster únicamente con nodos de subasta y no cambias a grupos de 0 nodos durante las noches o los fines de semana, puedes reservar el número mínimo de nodos operativos.

Azure

Como no puedes reducir el pool de nodos por defecto (sistema) a 0, puedes adquirir máquinas virtuales reservadas para cubrirlos.

En el caso de los pools de nodos de trabajo, si los reduces a 0 durante las noches/los fines de semana, no puedes comprar reservas. Como alternativa, puedes reservar el número mínimo de nodos de trabajo.

Con la función de cancelación de reservas, puedes ser muy agresivo en la cobertura de reservas, ya que el punto de equilibrio se alcanza rápidamente (los gastos de cancelación son sólo el 3% de los gastos de reserva restantes). Consulta la documentación de Azure para obtener más información.

Particularidades de AWS Fargate

Obligatorio:

• Solo cargas de trabajo interrumpibles.

Limitaciones:

• Statefulset no soportado (usar EFS para volumen persistente)
• No está disponible en todas las regiones de AWS
• Solo admite ALB como tipo de balanceador de carga
• Máximo 4vCPU y 30GB de memoria por contenedor

Opciones:

• Fargate
• Fargate con instancias puntuales

Modelo de precios

• Por vCPU por hora y por memoria (GB) por hora.

Fargate es un buen candidato para:

• Clusters muy pequeños
• Pruebas rápidas/POC

Operar

La fase de operaciones permite mejorar continuamente tu estrategia FinOps. Sus controles permiten:

• Cambios en los costes globales
• Cambios en los costes elemento por elemento
• Dar a los desarrolladores los medios para supervisar su uso de Kubernetes y animarles a hacerlo.
• Utilizar las últimas funcionalidades del proveedor de Cloud (por ejemplo, disponibilidad de la instancia/vm de nueva generación)
• Comprobar si se pueden aplicar nuevas optimizaciones

Esta es una lista no exhaustiva de cosas que hay que hacer/comprobar durante la fase de operaciones, que DEBEN llevarse a cabo en entornos de producción y de no producción.

Si quieres saber más sobre recursos útiles relacionados con Kubernetes desde la perspectiva de FinOps, aquí te dejamos nuestras recomendaciones: 

• Mejores prácticas de Google Cloud para ejecutar Kubernetes de forma rentable
• Libro blanco FinOps para Kubernetes de la FinOps Foundation

¿Necesitas ayuda? Contacta con nuestro equipo.

La entrada Cómo gestionar un cluster Kubernetes desde una perspectiva FinOps se publicó primero en Geko Cloud.

En este artículo, explicaremos cómo funciona la federación en Kubernetes, sus ventajas, inconvenientes y algunos aspectos técnicos importantes que permiten su implementación.

¿Qué es la federación en Kubernetes?

La federación en Kubernetes permite gestionar múltiples clusters a través de un panel de control maestro. Esto se logra utilizando un conjunto de APIs que permiten la creación, actualización y eliminación de recursos de manera sincronizada en todos los clusters federados. Una vez que Kubernetes Federation (KubeFed) se instala en el cluster maestro, este proporciona flexibilidad para gestionar clusters distribuidos en diferentes ubicaciones geográficas o incluso en distintas plataformas de nube.

Ventajas de la federación en Kubernetes

1. Alta disponibilidad: Los clusters federados permiten distribuir aplicaciones en diferentes regiones. Por ejemplo, si tenemos un cluster en Sudamérica y otro en Europa, los usuarios pueden ser atendidos por el cluster más cercano, lo que mejora la disponibilidad y el rendimiento.
2. Menor latencia: Al servir las aplicaciones desde el cluster más cercano a los usuarios, se reducen significativamente los tiempos de respuesta.
3. Despliegue multi-cloud y on-premise: La federación en Kubernetes permite combinar clusters en diferentes proveedores de nube como AWS, Google Cloud, Azure, Alibaba Cloud, e incluso clusters en entornos on-premise (data centers propios), permitiendo una arquitectura híbrida muy flexible.
4. Disaster Recovery (recuperación ante desastres): Los clusters pueden replicarse entre sí, de modo que si un cluster falla (por ejemplo, debido a la caída de un data center), las aplicaciones seguirán funcionando a través de otro cluster.
5. Gestión centralizada: KubeFed permite gestionar los recursos y la infraestructura de todos los clusters desde un único lugar, facilitando el despliegue y la administración de manera más eficiente.

Inconvenientes de la federación en Kubernetes

1. Complejidad: Al utilizar la federación, la complejidad operativa aumenta. Es necesario gestionar correctamente los objetos federados para evitar errores que puedan afectar a todos los clusters.
2. Errores globales: Si se comete un error en la definición de un objeto federado, el impacto será a nivel global, afectando a múltiples clusters simultáneamente.
3. Sobrecarga operativa: Aunque la federación centraliza la gestión, cada cluster sigue teniendo sus propios recursos y componentes, lo que añade una capa adicional de gestión.

Aspectos técnicos de la federación en Kubernetes

Estructura de los objetos federados

Un punto clave de la federación es la capacidad de definir y replicar objetos entre diferentes clusters. Los objetos federados se organizan en tres partes principales:

1. Template: Define los recursos comunes que serán replicados en todos los clusters. Es la base sobre la cual se crea el objeto, por ejemplo, un deployment o un configmap. La sección Template incluye la especificación del recurso como si fuera un objeto estándar de Kubernetes.
2. Placement: Esta sección permite especificar en qué clusters será replicado un determinado recurso federado. Podemos decidir que un recurso específico solo se replique en algunos clusters, en lugar de en todos.
3. Overrides: Esta es una de las características más potentes de la federación. Permite modificar partes específicas del objeto federado en ciertos clusters. Por ejemplo, podríamos ajustar el número de réplicas de un deployment en un cluster sin que afecte a los demás clusters.

Ejemplo: Modificación de réplicas

Imagina que tienes un deployment federado con tres réplicas en cada cluster. Con la federación, podrías ajustar el número de réplicas de un cluster específico mediante los Overrides, por ejemplo, reduciendo el número de réplicas en un cluster de prueba a solo una, mientras que los demás clusters mantendrán las tres réplicas originales.

Habilitación de APIs y recursos customizados

Por defecto, Kubernetes Federation ofrece un conjunto de APIs federadas listas para usar. Sin embargo, es posible federar recursos adicionales, incluidos los Custom Resources (CRDs). Para habilitar una nueva API federada, simplemente se utiliza el comando:

Esto habilita la federación para ese tipo de recurso, permitiendo su gestión en todos los clusters federados.

Casos de uso de la federación en Kubernetes

Despliegue multi-regional

En arquitecturas de alta disponibilidad, la federación en Kubernetes permite desplegar aplicaciones en clusters distribuidos por diferentes continentes. Por ejemplo, un e-commerce global podría tener sus aplicaciones replicadas en clusters en América, Europa y Asia, permitiendo un servicio óptimo para los usuarios locales.

Disaster recovery

La capacidad de replicar recursos federados en diferentes clusters es especialmente útil para escenarios de recuperación ante desastres. Si un data center falla, la aplicación puede seguir funcionando en otro cluster sin interrupciones, garantizando la continuidad del negocio.

Personalización de despliegues

Mediante el uso de los Overrides, podemos personalizar los despliegues para que cada cluster tenga características específicas. Por ejemplo, podríamos querer que un cluster en producción tenga un número mayor de réplicas que uno en un entorno de desarrollo o pruebas.

La federación en Kubernetes es una herramienta poderosa para gestionar múltiples clusters distribuidos geográficamente o en diferentes nubes. A pesar de la complejidad añadida, las ventajas en cuanto a alta disponibilidad, recuperación ante desastres y gestión centralizada la hacen una solución ideal para organizaciones que necesitan operar en múltiples regiones o requieren una infraestructura distribuida robusta.

¿Necesitas ayuda? Contacta con nuestro equipo.

La entrada La federación en Kubernetes: qué es, ventajas y casos de uso se publicó primero en Geko Cloud.