[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-observabilidad-sin-instrumentacion-ebpf-reemplazo-flota-sidecars":3},{"article":4,"author":54},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":23,"related_articles":34},"d0000000-0000-0000-0000-000000000661","a0000000-0000-0000-0000-000000000005","Observabilidad sin instrumentación: cómo eBPF reemplazó la flota de sidecars","observabilidad-sin-instrumentacion-ebpf-reemplazo-flota-sidecars","67% de los equipos de Kubernetes ahora usan herramientas de observabilidad basadas en eBPF, frente al 29% en 2024. Al mover la recopilación de telemetría al kernel, eBPF elimina los contenedores sidecar, reduce el uso de RAM en un 84% y ofrece menos del 1% de overhead de CPU.","## El 67% de los equipos de Kubernetes han cambiado a observabilidad eBPF\n\nSegún la Encuesta Anual CNCF 2026, **el 67% de los equipos de Kubernetes** ahora usan herramientas basadas en eBPF para al menos un pilar de observabilidad (métricas, trazas o logs) — frente al 29% en 2024 y el 41% en 2025.\n\nLa razón es simple: la observabilidad tradicional basada en sidecars (proxies Envoy, sidecars OpenTelemetry Collector, agentes Datadog) consume recursos enormes, añade latencia a cada solicitud y requiere cambios de código. eBPF hace todo desde el kernel — sin ningún cambio de aplicación.\n\n## Qué es eBPF y por qué importa\n\neBPF (extended Berkeley Packet Filter) es una tecnología que permite ejecutar programas sandboxed dentro del kernel Linux sin cambiar el código fuente del kernel.\n\n### Cómo funciona\n\n1. **Escribir un programa pequeño** en C o Rust\n2. **Adjuntarlo a un punto de enganche del kernel** — syscalls, eventos de red, tracepoints\n3. **El verificador eBPF del kernel** comprueba la seguridad del programa\n4. **El compilador JIT** traduce el bytecode eBPF a instrucciones máquina nativas\n5. **El programa se ejecuta** en el punto de enganche con rendimiento casi nativo\n\n```c\n\u002F\u002F Programa eBPF simplificado para rastrear solicitudes HTTP\nSEC(\"kprobe\u002Ftcp_v4_connect\")\nint trace_connect(struct pt_regs *ctx) {\n    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);\n    \n    u32 pid = bpf_get_current_pid_tgid() >> 32;\n    u16 dport = sk->__sk_common.skc_dport;\n    u32 daddr = sk->__sk_common.skc_daddr;\n    \n    struct event_t event = {\n        .pid = pid,\n        .dport = ntohs(dport),\n        .daddr = daddr,\n        .timestamp = bpf_ktime_get_ns(),\n    };\n    \n    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,\n                          &event, sizeof(event));\n    return 0;\n}\n```\n\n### Por qué importa para la observabilidad\n\nLa observabilidad tradicional requiere **instrumentación**. Este enfoque tiene tres problemas fundamentales:\n\n1. **Overhead de recursos** — cada sidecar consume CPU y memoria. En un clúster de 500 pods con sidecars Envoy, los sidecars pueden consumir el 30-40% de los recursos totales.\n2. **Brechas de cobertura** — solo puede observar lo que instrumenta.\n3. **Carga de mantenimiento** — cada lenguaje necesita su propia biblioteca de instrumentación.\n\neBPF resuelve los tres: se ejecuta en el kernel (cero overhead de aplicación), ve todo lo que el kernel ve (sin brechas), y funciona independientemente del lenguaje.\n\n## El stack de observabilidad eBPF en 2026\n\n### Cilium + Hubble: observabilidad de red\n\n**Cilium** es el CNI de facto para Kubernetes. **Hubble** proporciona:\n\n- **Visibilidad de flujos L3\u002FL4** — cada conexión TCP\u002FUDP entre pods\n- **Parsing de protocolos L7** — HTTP, gRPC, Kafka, DNS, PostgreSQL sin cambios de aplicación\n- **Auditoría de políticas de red** — ver qué políticas permiten o deniegan tráfico en tiempo real\n- **Mapeo de dependencias de servicios** — generación automática del grafo de servicios\n\n### Pixie: monitoreo de rendimiento de aplicaciones\n\nPixie (proyecto sandbox CNCF) proporciona **APM sin instrumentación**:\n\n- **Rastreo automático de protocolos** — HTTP\u002F1.1, HTTP\u002F2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS\n- **Profiling de CPU continuo** — flamegraphs desde stack traces eBPF\n- **Logging dinámico** — agregar trace points sin redespliegue\n- **Captura completa de solicitud\u002Frespuesta** — headers HTTP, queries SQL, payloads gRPC\n\n### Tetragon: seguridad runtime y auditoría\n\n**Tetragon** (por Isovalent\u002FCilium):\n\n- **Seguimiento de ejecución de procesos** — cada evento exec, fork y exit\n- **Monitoreo de acceso a archivos** — rastrear lecturas, escrituras y cambios de permisos\n- **Auditoría de conexiones de red** — registrar cada conexión saliente con contexto de proceso\n- **Aplicación de políticas de seguridad** — bloquear actividades sospechosas en tiempo real\n\n### Grafana Beyla: auto-instrumentación\n\n**Grafana Beyla** genera trazas y métricas compatibles con OpenTelemetry:\n\n- Detecta solicitudes HTTP, gRPC, SQL y Redis a nivel de kernel\n- Emite spans OpenTelemetry con propagación de contexto de traza\n- Se integra con Grafana Cloud, Tempo, Mimir y cualquier backend OpenTelemetry\n\n## Rendimiento: los números que importan\n\nBenchmarks de un **clúster Kubernetes de producción de 500 pods**:\n\n### Comparación de uso de memoria\n\n| Componente | Enfoque sidecar | Enfoque eBPF | Ahorro |\n|------------|----------------|-------------|--------|\n| Sidecars Envoy (500 pods) | 50 GB | 0 (Cilium CNI) | 50 GB |\n| Sidecars OTel Collector (500 pods) | 15 GB | 0 (Beyla DaemonSet) | 15 GB |\n| Agentes Cilium (20 nodos) | N\u002FA | 8 GB | -8 GB |\n| Agentes Beyla (20 nodos) | N\u002FA | 2 GB | -2 GB |\n| **Total** | **75 GB** | **12 GB** | **Reducción del 84%** |\n\n### Overhead de CPU\n\n| Métrica | Enfoque sidecar | Enfoque eBPF |\n|---------|----------------|---------------|\n| Latencia añadida por solicitud | 1-5ms | \u003C0.1ms |\n| Overhead de CPU por nodo | 8-12% | \u003C1% |\n| Impacto en latencia de cola (p99) | +15-30ms | \u003C1ms |\n\n## Guía de migración: de sidecars a eBPF\n\n### Fase 1: desplegar herramientas eBPF junto a sidecars (semanas 1-2)\n\n- Instalar Cilium como CNI\n- Desplegar Hubble para observabilidad de red\n- Desplegar Beyla como DaemonSet\n- Ejecutar ambos stacks en paralelo\n\n### Fase 2: validar y ajustar (semanas 3-4)\n\n- Verificar que las herramientas eBPF capturan las mismas señales\n- Ajustar la detección de protocolos de Beyla\n- Configurar dashboards espejo\n\n### Fase 3: eliminar sidecars gradualmente (semanas 5-8)\n\n- Comenzar con servicios no críticos\n- Monitorear regresiones de calidad de datos\n- Eliminar sidecars Envoy de servicios que no necesitan gestión de tráfico avanzada\n\n### Fase 4: stack eBPF completo (semanas 9-12)\n\n- Eliminar sidecars restantes\n- Desplegar Tetragon para seguridad runtime\n- Consolidar alertas en señales eBPF\n- Recuperar recursos liberados\n\n## Preguntas frecuentes\n\n### ¿La observabilidad eBPF funciona con cargas no-Kubernetes?\n\nSí. eBPF se ejecuta a nivel del kernel Linux, funcionando con cualquier carga de trabajo.\n\n### ¿eBPF puede reemplazar el tracing distribuido?\n\nPara muchos equipos, sí. Pero las trazas eBPF están limitadas a las fronteras solicitud\u002Frespuesta.\n\n### ¿Qué hay del tráfico cifrado (TLS)?\n\nLas herramientas eBPF pueden rastrear tráfico TLS adjuntándose a funciones de la biblioteca TLS.\n\n### ¿eBPF es seguro? ¿Un programa eBPF defectuoso puede crashear el kernel?\n\nNo. El verificador eBPF revisa cada programa antes de cargarlo. Un programa defectuoso fallará al cargar.\n\n### ¿Cómo maneja eBPF servicios de alto throughput (100K+ solicitudes\u002Fsegundo)?\n\nMediante agregación in-kernel y muestreo. Los programas eBPF calculan histogramas en los maps del kernel.","\u003Ch2 id=\"el-67-de-los-equipos-de-kubernetes-han-cambiado-a-observabilidad-ebpf\">El 67% de los equipos de Kubernetes han cambiado a observabilidad eBPF\u003C\u002Fh2>\n\u003Cp>Según la Encuesta Anual CNCF 2026, \u003Cstrong>el 67% de los equipos de Kubernetes\u003C\u002Fstrong> ahora usan herramientas basadas en eBPF para al menos un pilar de observabilidad (métricas, trazas o logs) — frente al 29% en 2024 y el 41% en 2025.\u003C\u002Fp>\n\u003Cp>La razón es simple: la observabilidad tradicional basada en sidecars (proxies Envoy, sidecars OpenTelemetry Collector, agentes Datadog) consume recursos enormes, añade latencia a cada solicitud y requiere cambios de código. eBPF hace todo desde el kernel — sin ningún cambio de aplicación.\u003C\u002Fp>\n\u003Ch2 id=\"qu-es-ebpf-y-por-qu-importa\">Qué es eBPF y por qué importa\u003C\u002Fh2>\n\u003Cp>eBPF (extended Berkeley Packet Filter) es una tecnología que permite ejecutar programas sandboxed dentro del kernel Linux sin cambiar el código fuente del kernel.\u003C\u002Fp>\n\u003Ch3>Cómo funciona\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Escribir un programa pequeño\u003C\u002Fstrong> en C o Rust\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Adjuntarlo a un punto de enganche del kernel\u003C\u002Fstrong> — syscalls, eventos de red, tracepoints\u003C\u002Fli>\n\u003Cli>\u003Cstrong>El verificador eBPF del kernel\u003C\u002Fstrong> comprueba la seguridad del programa\u003C\u002Fli>\n\u003Cli>\u003Cstrong>El compilador JIT\u003C\u002Fstrong> traduce el bytecode eBPF a instrucciones máquina nativas\u003C\u002Fli>\n\u003Cli>\u003Cstrong>El programa se ejecuta\u003C\u002Fstrong> en el punto de enganche con rendimiento casi nativo\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cpre>\u003Ccode class=\"language-c\">\u002F\u002F Programa eBPF simplificado para rastrear solicitudes HTTP\nSEC(\"kprobe\u002Ftcp_v4_connect\")\nint trace_connect(struct pt_regs *ctx) {\n    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);\n    \n    u32 pid = bpf_get_current_pid_tgid() >> 32;\n    u16 dport = sk->__sk_common.skc_dport;\n    u32 daddr = sk->__sk_common.skc_daddr;\n    \n    struct event_t event = {\n        .pid = pid,\n        .dport = ntohs(dport),\n        .daddr = daddr,\n        .timestamp = bpf_ktime_get_ns(),\n    };\n    \n    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,\n                          &event, sizeof(event));\n    return 0;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Por qué importa para la observabilidad\u003C\u002Fh3>\n\u003Cp>La observabilidad tradicional requiere \u003Cstrong>instrumentación\u003C\u002Fstrong>. Este enfoque tiene tres problemas fundamentales:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Overhead de recursos\u003C\u002Fstrong> — cada sidecar consume CPU y memoria. En un clúster de 500 pods con sidecars Envoy, los sidecars pueden consumir el 30-40% de los recursos totales.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Brechas de cobertura\u003C\u002Fstrong> — solo puede observar lo que instrumenta.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Carga de mantenimiento\u003C\u002Fstrong> — cada lenguaje necesita su propia biblioteca de instrumentación.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>eBPF resuelve los tres: se ejecuta en el kernel (cero overhead de aplicación), ve todo lo que el kernel ve (sin brechas), y funciona independientemente del lenguaje.\u003C\u002Fp>\n\u003Ch2 id=\"el-stack-de-observabilidad-ebpf-en-2026\">El stack de observabilidad eBPF en 2026\u003C\u002Fh2>\n\u003Ch3>Cilium + Hubble: observabilidad de red\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Cilium\u003C\u002Fstrong> es el CNI de facto para Kubernetes. \u003Cstrong>Hubble\u003C\u002Fstrong> proporciona:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Visibilidad de flujos L3\u002FL4\u003C\u002Fstrong> — cada conexión TCP\u002FUDP entre pods\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Parsing de protocolos L7\u003C\u002Fstrong> — HTTP, gRPC, Kafka, DNS, PostgreSQL sin cambios de aplicación\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Auditoría de políticas de red\u003C\u002Fstrong> — ver qué políticas permiten o deniegan tráfico en tiempo real\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mapeo de dependencias de servicios\u003C\u002Fstrong> — generación automática del grafo de servicios\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Pixie: monitoreo de rendimiento de aplicaciones\u003C\u002Fh3>\n\u003Cp>Pixie (proyecto sandbox CNCF) proporciona \u003Cstrong>APM sin instrumentación\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Rastreo automático de protocolos\u003C\u002Fstrong> — HTTP\u002F1.1, HTTP\u002F2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Profiling de CPU continuo\u003C\u002Fstrong> — flamegraphs desde stack traces eBPF\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Logging dinámico\u003C\u002Fstrong> — agregar trace points sin redespliegue\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Captura completa de solicitud\u002Frespuesta\u003C\u002Fstrong> — headers HTTP, queries SQL, payloads gRPC\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Tetragon: seguridad runtime y auditoría\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Tetragon\u003C\u002Fstrong> (por Isovalent\u002FCilium):\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Seguimiento de ejecución de procesos\u003C\u002Fstrong> — cada evento exec, fork y exit\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Monitoreo de acceso a archivos\u003C\u002Fstrong> — rastrear lecturas, escrituras y cambios de permisos\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Auditoría de conexiones de red\u003C\u002Fstrong> — registrar cada conexión saliente con contexto de proceso\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Aplicación de políticas de seguridad\u003C\u002Fstrong> — bloquear actividades sospechosas en tiempo real\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Grafana Beyla: auto-instrumentación\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Grafana Beyla\u003C\u002Fstrong> genera trazas y métricas compatibles con OpenTelemetry:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Detecta solicitudes HTTP, gRPC, SQL y Redis a nivel de kernel\u003C\u002Fli>\n\u003Cli>Emite spans OpenTelemetry con propagación de contexto de traza\u003C\u002Fli>\n\u003Cli>Se integra con Grafana Cloud, Tempo, Mimir y cualquier backend OpenTelemetry\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"rendimiento-los-n-meros-que-importan\">Rendimiento: los números que importan\u003C\u002Fh2>\n\u003Cp>Benchmarks de un \u003Cstrong>clúster Kubernetes de producción de 500 pods\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Ch3>Comparación de uso de memoria\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Componente\u003C\u002Fth>\u003Cth>Enfoque sidecar\u003C\u002Fth>\u003Cth>Enfoque eBPF\u003C\u002Fth>\u003Cth>Ahorro\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Sidecars Envoy (500 pods)\u003C\u002Ftd>\u003Ctd>50 GB\u003C\u002Ftd>\u003Ctd>0 (Cilium CNI)\u003C\u002Ftd>\u003Ctd>50 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Sidecars OTel Collector (500 pods)\u003C\u002Ftd>\u003Ctd>15 GB\u003C\u002Ftd>\u003Ctd>0 (Beyla DaemonSet)\u003C\u002Ftd>\u003Ctd>15 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Agentes Cilium (20 nodos)\u003C\u002Ftd>\u003Ctd>N\u002FA\u003C\u002Ftd>\u003Ctd>8 GB\u003C\u002Ftd>\u003Ctd>-8 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Agentes Beyla (20 nodos)\u003C\u002Ftd>\u003Ctd>N\u002FA\u003C\u002Ftd>\u003Ctd>2 GB\u003C\u002Ftd>\u003Ctd>-2 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Total\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>75 GB\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>12 GB\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>Reducción del 84%\u003C\u002Fstrong>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Overhead de CPU\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Métrica\u003C\u002Fth>\u003Cth>Enfoque sidecar\u003C\u002Fth>\u003Cth>Enfoque eBPF\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Latencia añadida por solicitud\u003C\u002Ftd>\u003Ctd>1-5ms\u003C\u002Ftd>\u003Ctd><0.1ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Overhead de CPU por nodo\u003C\u002Ftd>\u003Ctd>8-12%\u003C\u002Ftd>\u003Ctd><1%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Impacto en latencia de cola (p99)\u003C\u002Ftd>\u003Ctd>+15-30ms\u003C\u002Ftd>\u003Ctd><1ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"gu-a-de-migraci-n-de-sidecars-a-ebpf\">Guía de migración: de sidecars a eBPF\u003C\u002Fh2>\n\u003Ch3>Fase 1: desplegar herramientas eBPF junto a sidecars (semanas 1-2)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Instalar Cilium como CNI\u003C\u002Fli>\n\u003Cli>Desplegar Hubble para observabilidad de red\u003C\u002Fli>\n\u003Cli>Desplegar Beyla como DaemonSet\u003C\u002Fli>\n\u003Cli>Ejecutar ambos stacks en paralelo\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Fase 2: validar y ajustar (semanas 3-4)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Verificar que las herramientas eBPF capturan las mismas señales\u003C\u002Fli>\n\u003Cli>Ajustar la detección de protocolos de Beyla\u003C\u002Fli>\n\u003Cli>Configurar dashboards espejo\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Fase 3: eliminar sidecars gradualmente (semanas 5-8)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Comenzar con servicios no críticos\u003C\u002Fli>\n\u003Cli>Monitorear regresiones de calidad de datos\u003C\u002Fli>\n\u003Cli>Eliminar sidecars Envoy de servicios que no necesitan gestión de tráfico avanzada\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Fase 4: stack eBPF completo (semanas 9-12)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Eliminar sidecars restantes\u003C\u002Fli>\n\u003Cli>Desplegar Tetragon para seguridad runtime\u003C\u002Fli>\n\u003Cli>Consolidar alertas en señales eBPF\u003C\u002Fli>\n\u003Cli>Recuperar recursos liberados\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"preguntas-frecuentes\">Preguntas frecuentes\u003C\u002Fh2>\n\u003Ch3 id=\"la-observabilidad-ebpf-funciona-con-cargas-no-kubernetes\">¿La observabilidad eBPF funciona con cargas no-Kubernetes?\u003C\u002Fh3>\n\u003Cp>Sí. eBPF se ejecuta a nivel del kernel Linux, funcionando con cualquier carga de trabajo.\u003C\u002Fp>\n\u003Ch3 id=\"ebpf-puede-reemplazar-el-tracing-distribuido\">¿eBPF puede reemplazar el tracing distribuido?\u003C\u002Fh3>\n\u003Cp>Para muchos equipos, sí. Pero las trazas eBPF están limitadas a las fronteras solicitud\u002Frespuesta.\u003C\u002Fp>\n\u003Ch3 id=\"qu-hay-del-tr-fico-cifrado-tls\">¿Qué hay del tráfico cifrado (TLS)?\u003C\u002Fh3>\n\u003Cp>Las herramientas eBPF pueden rastrear tráfico TLS adjuntándose a funciones de la biblioteca TLS.\u003C\u002Fp>\n\u003Ch3 id=\"ebpf-es-seguro-un-programa-ebpf-defectuoso-puede-crashear-el-kernel\">¿eBPF es seguro? ¿Un programa eBPF defectuoso puede crashear el kernel?\u003C\u002Fh3>\n\u003Cp>No. El verificador eBPF revisa cada programa antes de cargarlo. Un programa defectuoso fallará al cargar.\u003C\u002Fp>\n\u003Ch3 id=\"c-mo-maneja-ebpf-servicios-de-alto-throughput-100k-solicitudes-segundo\">¿Cómo maneja eBPF servicios de alto throughput (100K+ solicitudes\u002Fsegundo)?\u003C\u002Fh3>\n\u003Cp>Mediante agregación in-kernel y muestreo. Los programas eBPF calculan histogramas en los maps del kernel.\u003C\u002Fp>\n","es","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:48.536646Z","67% de equipos K8s usan observabilidad eBPF. Cilium, Hubble, Pixie, Tetragon, Grafana Beyla — guía completa con plan de migración y benchmarks.","eBPF observability",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000006","Docker","docker",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000007","Kubernetes","kubernetes",[35,42,48],{"id":36,"title":37,"slug":38,"excerpt":39,"locale":12,"category_name":40,"published_at":41},"d0000000-0000-0000-0000-000000000683","Por qué Bali se está convirtiendo en el hub de impact-tech del Sudeste Asiático en 2026","por-que-bali-hub-impact-tech-sudeste-asiatico-2026","Bali ocupa el puesto 16 entre los ecosistemas startup del Sudeste Asiático. Con una concentración creciente de constructores Web3, startups de AI sostenible y empresas de eco-travel tech, la isla se consolida como capital de impact-tech de la región.","Ingeniería","2026-03-28T10:44:49.926489Z",{"id":43,"title":44,"slug":45,"excerpt":46,"locale":12,"category_name":40,"published_at":47},"d0000000-0000-0000-0000-000000000682","El mosaico de protección de datos de ASEAN: checklist de cumplimiento para desarrolladores","mosaico-proteccion-datos-asean-checklist-cumplimiento-desarrolladores","Siete países de ASEAN tienen ahora leyes integrales de protección de datos, cada una con diferentes modelos de consentimiento, requisitos de localización y estructuras de sanciones. Un checklist práctico de cumplimiento para desarrolladores.","2026-03-28T10:44:49.919345Z",{"id":49,"title":50,"slug":51,"excerpt":52,"locale":12,"category_name":40,"published_at":53},"d0000000-0000-0000-0000-000000000681","La transformación digital de 29 mil millones de dólares de Indonesia: oportunidades para empresas de software","transformacion-digital-29-mil-millones-dolares-indonesia-oportunidades-empresas-software","El mercado de servicios IT de Indonesia alcanzará los 29.030 millones de dólares en 2026, frente a los 24.370 millones de 2025. La infraestructura cloud, la AI, el comercio electrónico y los centros de datos impulsan el crecimiento más rápido del Sudeste Asiático.","2026-03-28T10:44:49.897658Z",{"id":13,"name":55,"slug":56,"bio":57,"photo_url":18,"linkedin":18,"role":58,"created_at":59,"updated_at":59},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]