Modos de despliegue del Dynatrace Operator en Kubernetes: cuál elegir y por qué

Artículo revisado en abril de 2026 para incluir referencias específicas a entornos Dynatrace Managed, no solo SaaS. Se han añadido aclaraciones sobre las diferencias funcionales entre ambos modelos y su impacto real en el despliegue y aprovechamiento de la plataforma.

Este artículo está basado en la documentación oficial de Dynatrace vigente a abril de 2026 (Operator v1.8.x, DynaKube API v1beta6). La plataforma evoluciona con frecuencia — antes de implementar cualquier patrón, conviene revisar la documentación oficial actualizada.

Nota sobre SaaS y Managed: El contenido de este artículo sobre el Operator y los modos de despliegue aplica por igual a Dynatrace SaaS y Dynatrace Managed. Sin embargo, hay diferencias significativas entre ambos modelos que afectan a funcionalidades avanzadas. Se detallan al final del artículo en una sección específica.

En entornos de producción basados en contenedores y orquestados con Kubernetes, la monitorización integral es un reto creciente. Dynatrace OneAgent se ha consolidado como una solución potente para obtener visibilidad profunda en aplicaciones distribuidas, pero su despliegue en contenedores requiere decisiones arquitectónicas que afectan directamente a la calidad de los datos, la estabilidad del clúster y el coste operativo. Este artículo aborda los modos de despliegue disponibles, las diferencias reales entre ellos, los errores más comunes y los criterios para elegir correctamente.

El Dynatrace Operator: el punto de entrada real

Antes de hablar de modos de despliegue, hay que aclarar algo que mucha documentación desactualizada todavía omite: nadie debería desplegar hoy OneAgent directamente como DaemonSet de forma manual. Ese era el procedimiento hasta que Dynatrace lanzó el Operator. El despliegue manual no es el método recomendado ni está soportado activamente — la recomendación oficial es usar el Dynatrace Operator para la gestión automatizada del ciclo de vida, actualizaciones coordinadas y enriquecimiento de metadatos.

El Operator es el punto de entrada real. A partir de ahí, defines el modo de despliegue en un DynaKube Custom Resource — el objeto de Kubernetes que describe cómo quieres monitorizar tu clúster. Puedes instalarlo vía Helm (método recomendado) o kubectl apply.

Componentes que despliega el Operator

Es importante entender qué piezas entran en juego cuando aplicas un DynaKube:

Dynatrace Operator: gestiona el ciclo de vida de todos los componentes. Valida el DynaKube y coordina actualizaciones.
Webhook (mutating admission webhook): intercepta la creación de pods y les inyecta la configuración y los code modules de OneAgent antes de que arranquen.
CSI Driver: desplegado como DaemonSet, gestiona el almacenamiento de los binarios de OneAgent como volúmenes por nodo. Descarga los code modules una sola vez por nodo y los monta en los pods vía init container, evitando descargas redundantes.
OneAgent: recoge métricas de host desde los nodos de Kubernetes (en los modos que incluyen monitorización de infraestructura).
ActiveGate: enruta los datos de observabilidad al clúster de Dynatrace y monitoriza el API de Kubernetes.

Versión actual y compatibilidad

A abril de 2026, la versión estable es la 1.8.1 (publicada en febrero de 2026), con la 1.9.0 en release candidate. La versión 1.8 introdujo la API v1beta6 del DynaKube y capacidades como la auto-configuración OTLP para aplicaciones instrumentadas con OpenTelemetry.

Atención a las versiones de API del DynaKube: Las versiones v1beta1 y v1beta2 fueron eliminadas en el Operator 1.7. La v1beta3 dejará de servirse próximamente. Si buscas ejemplos YAML en internet, muchos están desactualizados — asegúrate de usar v1beta5 o v1beta6 según tu versión del Operator.

Los cuatro modos de despliegue

cloudNativeFullStack — el modo recomendado

Desde el Operator 1.0 (marzo 2024), cloudNativeFullStack es el modo por defecto. Combina monitorización de host y de aplicación usando dos mecanismos nativos de Kubernetes: mutating admission webhooks para interceptar pods antes de que arranquen, y CSI Driver para montar los code modules como volúmenes. El resultado es inyección automática sin race conditions y con menores privilegios que el modo clásico.

Cuándo usarlo: La mayoría de entornos Kubernetes productivos con autoscaling, alta rotación de pods o requisitos de seguridad.

classicFullStack — el modo legacy, aún soportado

El OneAgent corre como DaemonSet en cada nodo e inyecta los code modules en los pods que detecta. El problema: si un pod de aplicación arranca antes que el OneAgent del nodo, ese pod queda sin instrumentar y hay que reiniciarlo manualmente. En entornos con autoscaling agresivo esto no es una posibilidad teórica — es algo que ocurre con regularidad.

Cuándo usarlo: Entornos estables sin autoscaling frecuente, o como paso intermedio en una migración hacia cloudNativeFullStack.

Limitación adicional: En el Operator 1.7+, classicFullStack y metadata enrichment no son compatibles cuando se inyectan en los mismos pods de aplicación, ya que ambos intentan montar sobre /var/lib/dynatrace.

applicationMonitoring — solo capa de aplicación

Usa los mismos mecanismos que cloudNativeFullStack (webhook + CSI Driver) pero sin recoger métricas de host ni de nodo. Útil cuando la infraestructura ya está cubierta por otra herramienta y solo se necesita observabilidad de aplicación.

Cuándo usarlo: Entornos donde la plataforma de infraestructura es gestionada por otro equipo o herramienta, y solo se necesita instrumentar el código. También es el único modo soportado para AWS Fargate (sin CSI Driver).

hostMonitoring — solo infraestructura

El caso opuesto: monitoriza los nodos sin inyectar nada en los pods. Sin visibilidad de aplicación, solo métricas de sistema.

Cuándo usarlo: Nodos de sistema, workers dedicados a tareas de infraestructura, o como complemento a otros modos en entornos mixtos.

Tabla comparativa rápida

El problema que resuelve cloudNativeFullStack: la race condition

Este es el detalle técnico que más impacto tiene en producción y que más se subestima al diseñar el despliegue.

En classicFullStack, el OneAgent del nodo es responsable de detectar los pods nuevos e inyectar los code modules. Si el pod de aplicación arranca antes de que el OneAgent esté listo en ese nodo — algo habitual cuando escala un nodo nuevo y los pods se despliegan rápidamente — ese pod queda sin instrumentar. La solución es reiniciarlo, lo que en producción tiene un coste operativo y de disponibilidad real.

En cloudNativeFullStack, la inyección la ejecuta el mutating admission webhook antes de que el pod arranque. El CSI Driver descarga el code module una vez por nodo y lo monta como volumen en el init container del pod. El resultado: el pod arranca ya instrumentado desde el primer segundo, sin necesidad de que ningún agente esté corriendo previamente en el nodo.

Esto también tiene implicaciones de seguridad: cloudNativeFullStack no necesita acceso de escritura al sistema de ficheros del nodo, lo que reduce la superficie de ataque y simplifica el cumplimiento de políticas de seguridad estrictas.

Ejemplo mínimo de DynaKube

Este es un DynaKube básico para cloudNativeFullStack con namespace selector. Usa la API v1beta6 (Operator 1.8+):

yaml

apiVersion: dynatrace.com/v1beta6
kind: DynaKube
metadata:
  name: mi-cluster
  namespace: dynatrace
spec:
  apiUrl: https://ENTORNO.live.dynatrace.com/api
  # Para Managed: https://tu-servidor/e/ENVIRONMENT_ID/api
  oneAgent:
    cloudNativeFullStack:
      namespaceSelector:
        matchLabels:
          monitoring: dynatrace
  activeGate:
    capabilities:
      - kubernetes-monitoring
      - routing

Con esta configuración, solo los namespaces que tengan la etiqueta monitoring: dynatrace recibirán inyección de OneAgent. El ActiveGate se encargará de la monitorización del API de Kubernetes y del enrutamiento de datos.

Para etiquetar un namespace:

bash

kubectl label namespace mi-namespace monitoring=dynatrace

Decisiones, errores comunes y señales de alerta

Visibilidad vs. impacto operativo

cloudNativeFullStack ofrece la visibilidad más completa con el menor riesgo operativo. Sin embargo, requiere que el CSI Driver y el webhook estén operativos antes de que lleguen workloads al clúster. En migraciones desde classicFullStack, todos los pods existentes necesitan reiniciarse para recibir la inyección por el nuevo mecanismo — planifica la transición en una ventana de mantenimiento.

Automatización vs. control granular

El Operator facilita la automatización y escalabilidad. Por defecto, inyecta en todos los namespaces. Si necesitas limitar la cobertura, configura namespace selectors en el DynaKube como en el ejemplo anterior. Esto da un control granular sin sacrificar la automatización.

Errores comunes

Seguir desplegando DaemonSets manuales. El error más frecuente en equipos que llevan tiempo con Dynatrace: mantener el despliegue manual heredado sin migrar al Operator. Esto genera deuda operativa, dificulta las actualizaciones y priva al equipo de funcionalidades recientes como el enriquecimiento automático de metadatos Kubernetes, la gestión coordinada de versiones y la recolección de logs integrada.

No migrar de classicFullStack a cloudNativeFullStack. Muchos entornos siguen en classicFullStack por inercia, asumiendo que la migración es compleja. Lo es, pero el coste de no migrar también es real: reiniciar pods después de cada escalado de nodos, gestionar manualmente los huecos de cobertura, y exponerse a más privilegios de los necesarios.

Despliegue indiscriminado sin segmentación. Inyectar en todos los namespaces sin criterio genera volumen excesivo de datos, costes elevados y dificultad para identificar alertas relevantes. Usa namespace selectors para limitar la monitorización a los workloads que aportan valor real.

Ignorar el impacto en recursos y latencia. Subestimar el consumo de CPU, memoria y red del agente puede derivar en degradación del rendimiento de aplicaciones críticas. Dimensiona y prueba el impacto en entornos de pruebas o pre-producción antes de producción.

No versionar el DynaKube como infraestructura como código. Mantener el despliegue del Operator como un proceso manual o separado del pipeline de infraestructura dificulta las actualizaciones y genera inconsistencias. El DynaKube Custom Resource debería vivir en el repositorio de IaC (Infraestructura como Código), igual que cualquier otro recurso de Kubernetes.

Usar DynaKube con versiones de API obsoletas. Si copias un YAML de un tutorial de 2023, probablemente use v1beta1 o v1beta2. Estas versiones ya no se sirven en el Operator 1.7+. Revisa siempre que tu manifiesto use la versión de API compatible con tu Operator.

Señales operativas que indican problemas en el despliegue

Incremento inesperado en la latencia o errores en aplicaciones tras la instalación del agente.
Alertas recurrentes de saturación de recursos en nodos o pods donde corre OneAgent.
Pods sin instrumentar después del escalado de nodos (señal clásica de classicFullStack con race condition).
Falta de datos o telemetría incompleta en entornos dinámicos con alta rotación de contenedores.
Dificultad para correlacionar eventos o trazas debido a datos inconsistentes.
Costes crecientes de licenciamiento o almacenamiento sin aumento proporcional en el valor operativo.

Novedades recientes del Operator que afectan al despliegue

Desde el Operator 1.4 se han incorporado capacidades que complementan los modos de despliegue y que conviene conocer:

logMonitoring (Operator 1.4+): Una sección dedicada en el DynaKube permite configurar la recolección de logs directamente. Se puede combinar con cualquier modo de despliegue (cloudNativeFullStack, applicationMonitoring, etc.) sin configuración adicional fuera del DynaKube.

Auto-configuración OTLP (Operator 1.8+): El Operator puede configurar automáticamente aplicaciones instrumentadas con OpenTelemetry para exportar trazas, métricas y logs a Dynatrace vía el exportador OTLP. Esto simplifica enormemente la integración con OpenTelemetry en entornos mixtos y refuerza la estrategia de combinar OneAgent con estándares abiertos.

KSPM — Kubernetes Security Posture Management (Operator 1.4+): Permite evaluar la postura de seguridad del clúster directamente a través del Operator.

Extensions en Kubernetes (Operator 1.4+): Integración y monitorización de tecnologías adicionales mediante extensiones de Dynatrace desplegadas como componentes gestionados por el Operator, incluyendo el OpenTelemetry Collector de Dynatrace y el Extension Execution Controller.

Cuándo NO es recomendable desplegar OneAgent en contenedores

Si el entorno está compuesto principalmente por funciones serverless o contenedores extremadamente efímeros (duración menor a segundos), el modelo tradicional de OneAgent pierde efectividad. En estos casos, es mejor optar por telemetría basada en OpenTelemetry, logs estructurados y métricas exportadas por la aplicación, integrando todo en Dynatrace vía ingestión estándar.

Para AWS Fargate, Dynatrace soporta tres métodos de integración: inyección automática (con el Operator en modo applicationMonitoring sin CSI Driver), inyección en tiempo de build e inyección en runtime. Para AIX y Solaris, existe la inyección universal (universal injection), que permite instrumentar aplicaciones donde la auto-inyección no está disponible.

También es desaconsejable en clústeres con recursos muy limitados o donde la aplicación es extremadamente sensible a cualquier sobrecarga, salvo que se realicen pruebas rigurosas y ajustes finos.

Si la organización no dispone de procesos maduros de automatización y gestión de configuración, el despliegue puede generar más problemas que beneficios. Conviene invertir primero en plataforma y cultura DevOps, y abordar la instrumentación cuando el suelo esté firme.

Diferencias entre Dynatrace SaaS y Managed que afectan a este contexto

Este es un punto que no se menciona lo suficiente en la documentación y que puede generar expectativas incorrectas. Todo lo explicado en este artículo sobre el Operator y los modos de despliegue funciona igual en SaaS y en Managed. Sin embargo, las funcionalidades avanzadas de la plataforma que luego consumen esos datos no son las mismas.

Qué funciona igual en SaaS y en Managed

El Dynatrace Operator, sus modos de despliegue y el DynaKube Custom Resource.
OneAgent, code modules, ActiveGate, CSI Driver.
Smartscape, detección automática de topología y dependencias.
Davis AI clásico: detección de anomalías y análisis de causa raíz basado en las métricas, trazas y logs recogidos por OneAgent.
Alertas, métricas personalizadas, APIs REST.
Management Zones, tags, metadata enrichment.

Qué solo está disponible en SaaS (con Grail)

Las siguientes funcionalidades requieren Dynatrace SaaS con Grail y no están disponibles en Managed:

Grail (el data lakehouse de Dynatrace): motor de almacenamiento y consulta avanzado. Sin Grail, no hay acceso a DQL avanzado, Notebooks ni Workflows.
Workflows: automatización nativa de la plataforma. No disponible en Managed.
Notebooks: entorno interactivo de análisis y consulta basado en DQL. No disponible en Managed.
Business Events: ingestión y análisis de eventos de negocio a través de múltiples fuentes. No disponible en Managed.
La nueva experiencia de Kubernetes (Explorer, Enhanced Object Visibility, visibilidad de objetos adicionales como Ingress, NetworkPolicies, CRDs, PVCs, con consulta de YAMLs vía DQL): requiere SaaS con Grail y licencia DPS con Kubernetes Platform Monitoring. En Managed se utiliza la experiencia Kubernetes Classic.
DQL completo: en Managed solo está disponible el subconjunto limitado de consultas; las capacidades avanzadas de DQL (timeseries, joins, funciones avanzadas) requieren Grail.

Qué implica esto en la práctica

Si trabajas con Dynatrace Managed, los datos que recoge OneAgent se siguen visualizando con Davis AI clásico, Smartscape, dashboards clásicos y la interfaz Kubernetes Classic. No pierdes la monitorización, pero sí el acceso a las herramientas de análisis más modernas de la plataforma.

Esto es importante a la hora de planificar el despliegue: si tu artículo de referencia o tutorial menciona Workflows, Notebooks, Business Events o la nueva experiencia de Kubernetes como parte del flujo de trabajo, ten en cuenta que esas piezas no estarán disponibles si estás en Managed.

La brecha funcional entre SaaS y Managed está creciendo. Grail es una pieza arquitectónica que Dynatrace no considera viable de desplegar on-premises por su complejidad (requiere cientos de pods en múltiples nodos de Kubernetes). Si tu organización está en Managed y estas funcionalidades son relevantes, conviene evaluar la migración a SaaS con tu equipo de cuenta de Dynatrace.

Resumen y recomendaciones prácticas

Usa cloudNativeFullStack vía Dynatrace Operator para la mayoría de entornos Kubernetes productivos. Es el modo por defecto desde el Operator 1.0 y resuelve los problemas históricos de race conditions y privilegios excesivos.
Si vienes de classicFullStack, planifica la migración. Los pods existentes necesitan reiniciarse. Programa la transición en una ventana de mantenimiento.
Implementa namespace selectors para controlar el volumen de datos y enfocar la monitorización en lo que aporta valor real.
El DynaKube Custom Resource debe vivir en tu repositorio de IaC — no lo gestiones manualmente. Y asegúrate de que usa una versión de API vigente (v1beta5 o v1beta6 a fecha de este artículo).
Combina OneAgent con OpenTelemetry en arquitecturas híbridas o serverless. El Operator 1.8+ facilita esto con la auto-configuración OTLP.
Aprovecha logMonitoring y KSPM como capacidades integradas del Operator que complementan los modos de despliegue.
Conoce las limitaciones de tu modelo de despliegue (SaaS vs. Managed) para no diseñar flujos de trabajo que dependan de funcionalidades no disponibles en tu entorno.

El despliegue de Dynatrace OneAgent en contenedores es una pieza clave en la estrategia de observabilidad moderna, pero debe abordarse con criterio arquitectónico y operativo. Comprender los modos actuales, los compromisos y las señales de alerta permite a los equipos SRE diseñar plataformas robustas, escalables y alineadas con las necesidades reales del negocio.

Referencias y documentación oficial

Autor

Tomas Pardellas

Ver todas las entradas