Skip to main content
Global
AIMenta
Blog

APAC eBPF Kubernetes Observability Guide 2026: Hubble, Pixie, and groundcover

A practitioner guide for APAC platform engineering teams adopting eBPF-powered Kubernetes observability in 2026 — covering Hubble as the Cilium ecosystem network observability layer using eBPF kernel probes to provide real-time service dependency maps, L7 flow inspection, and DNS query visibility for APAC clusters running Cilium CNI without sidecar proxies; Pixie as a CNCF sandbox auto-instrumentation platform that deploys as a Kubernetes DaemonSet and captures HTTP request traces, PostgreSQL query text, and DNS flows via eBPF in minutes without modifying APAC application code; and groundcover as an eBPF-native APM platform correlating auto-collected application traces with Kubernetes pod resource metrics in a unified UI compatible with OpenTelemetry SDK enrichment for APAC business context.

AE By AIMenta Editorial Team ·

Why eBPF Is Changing APAC Kubernetes Observability

Traditional Kubernetes observability required code changes: add the OpenTelemetry SDK, configure exporters, redeploy. For APAC teams with dozens of microservices in multiple languages, instrumentation becomes a multi-quarter project. eBPF (extended Berkeley Packet Filter) changes this: probes run in the Linux kernel, capturing application behavior from outside the process — HTTP requests, database queries, network flows — without touching APAC application code. The promise is instant deep observability without instrumentation debt.

Three tools cover the APAC eBPF observability spectrum:

Hubble — Cilium's eBPF network observability layer with real-time service dependency maps and network flow inspection for APAC Kubernetes clusters.

Pixie — CNCF sandbox auto-instrumentation platform that collects application traces, SQL queries, and logs via eBPF without code changes across APAC Kubernetes workloads.

groundcover — eBPF-native APM combining auto-collected traces, metrics, and logs with Kubernetes infrastructure correlation in a single APAC observability platform.

How eBPF Observability Works in APAC Kubernetes

Traditional APAC observability:
  Application code → OTel SDK → APAC sidecars/agents → external APAC backend
  Requires: SDK integration per language, sidecar injection, APAC app restart

eBPF APAC observability:
  Linux kernel eBPF probe → intercepts syscalls/network events
  → captures HTTP headers, SQL text, network flows
  → NO APAC application code change, NO APAC restart

What eBPF can capture from APAC Kubernetes workloads:
  ✓ HTTP/gRPC request + response headers (L7 protocol parsing)
  ✓ SQL query text + execution time (PostgreSQL/MySQL protocol parsing)
  ✓ DNS queries and responses (including resolution time)
  ✓ TCP connection establishment and teardown (L3/L4 flows)
  ✓ Process CPU and memory usage (per-container granularity)
  ✓ File I/O patterns (read/write per process)

What eBPF CANNOT capture from APAC workloads:
  ✗ Application-level business context (user ID, order ID, APAC tenant)
  ✗ Custom span attributes (need OTel SDK for APAC business events)
  ✗ Encrypted payload content (TLS termination inside process)
  ✗ Application-specific metrics beyond protocol patterns

Hubble: APAC Cilium Network Flow Visibility

Hubble APAC installation (with Cilium)

# APAC: Install Hubble alongside Cilium CNI

# Assuming APAC Cilium already installed via Helm
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true
# APAC: Hubble Relay aggregates flows from all APAC nodes
# APAC: Hubble UI provides service dependency map dashboard

# APAC: Install Hubble CLI
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --fail --remote-name-all \
  "https://github.com/cilium/hubble/releases/download/${HUBBLE_VERSION}/hubble-linux-amd64.tar.gz"
tar xzvf hubble-linux-amd64.tar.gz
chmod +x hubble && mv hubble /usr/local/bin/hubble

# APAC: Verify Hubble Relay is reachable
hubble status

Hubble APAC network flow inspection

# APAC: Inspect live network flows from Hubble CLI

# APAC: Show all flows to/from the apac-payments service
hubble observe \
  --namespace apac-payments \
  --follow \
  --output json | jq '.flow | {src: .source.pod_name, dst: .destination.pod_name, verdict: .verdict, proto: .l4}'

# APAC: Find all DNS queries from apac-order-service
hubble observe \
  --from-pod apac-production/apac-order-service \
  --protocol DNS \
  --follow

# APAC: Show dropped flows (network policy blocks)
hubble observe \
  --verdict DROPPED \
  --namespace apac-production \
  --last 100

# APAC: Output:
# DROPPED: apac-production/apac-frontend → apac-production/apac-database
#          (port 5432) — CiliumNetworkPolicy apac-db-policy blocking frontend
# APAC: Reveals misconfigured APAC network policy without test traffic

Pixie: APAC Zero-Code Auto-Instrumentation

Pixie APAC deployment

# APAC: Deploy Pixie to Kubernetes cluster — one command
px deploy

# APAC: Requires: Kubernetes 1.21+, Linux kernel 4.14+, APAC cluster admin
# APAC: Deploys as DaemonSet — one Pixie collector per APAC node
# APAC: Ready in ~2 minutes after deploy

# APAC: Verify all nodes have Pixie running
px get viziers
# NAME              CLUSTER          STATUS   AGE
# apac-prod-cluster asia-northeast1  Healthy  2m

Pixie APAC PxL script — slowest SQL queries

# APAC: PxL script — find slowest PostgreSQL queries across APAC cluster

import px

# APAC: Query Pixie's in-cluster DB query data (last 5 minutes)
df = px.DataFrame(table='pgsql_events', start_time='-5m')

# APAC: Filter to production namespace
df = df[df.ctx['namespace'] == 'apac-production']

# APAC: Add service label from pod context
df.service = df.ctx['service']

# APAC: Calculate query stats
df = df.groupby(['service', 'req_body']).agg(
    latency_p99=('latency', px.percentile(99)),
    count=('latency', px.count),
)

# APAC: Filter to slow queries (>100ms p99)
df = df[df.latency_p99 > 100 * px.MILLISECONDS]
df = df.sort('latency_p99', ascending=False)
df = df.head(20)
px.display(df, 'APAC Slowest SQL Queries')
# → Shows top 20 slow APAC SQL queries without any application instrumentation

Pixie APAC HTTP request breakdown

# APAC: PxL script — HTTP error rate by APAC service and endpoint

import px

df = px.DataFrame(table='http_events', start_time='-10m')
df = df[df.ctx['namespace'] == 'apac-production']
df.service = df.ctx['service']

# APAC: Group by service and endpoint
df = df.groupby(['service', 'req_path']).agg(
    total=('latency', px.count),
    errors=('resp_status', lambda x: px.sum(x >= 500)),
    latency_p95=('latency', px.percentile(95)),
)
df.error_rate = df.errors / df.total

# APAC: Show endpoints with >5% error rate
df = df[df.error_rate > 0.05]
px.display(df, 'APAC High Error Rate Endpoints')
# → HTTP error analysis from eBPF — no OTel SDK required

groundcover: APAC Correlated APM

groundcover APAC deployment

# APAC: Deploy groundcover to Kubernetes cluster via Helm
helm repo add groundcover https://helm.groundcover.com
helm repo update

helm install groundcover groundcover/groundcover \
  --namespace groundcover \
  --create-namespace \
  --set global.groundcoverToken="APAC_GC_TOKEN" \
  --set global.clusterId="apac-production"

# APAC: groundcover deploys:
#   - DaemonSet: eBPF collector on each APAC node
#   - Deployment: in-cluster storage (Clickhouse + object storage)
#   - Service: APAC Sensor API for OTel ingest

groundcover APAC OpenTelemetry enrichment

# APAC: Enrich eBPF auto-traces with custom business context via OTel SDK
# eBPF captures HTTP traces; OTel SDK adds APAC business attributes

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# APAC: Send custom spans to groundcover's OTel endpoint
provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(
        OTLPSpanExporter(
            endpoint="http://groundcover-sensor.groundcover:4317"  # APAC in-cluster
        )
    )
)
trace.set_tracer_provider(provider)

apac_tracer = trace.get_tracer("apac-order-service")

def process_apac_order(order_id: str, customer_id: str):
    with apac_tracer.start_as_current_span("process_apac_order") as span:
        span.set_attribute("apac.order_id", order_id)
        span.set_attribute("apac.customer_id", customer_id)
        span.set_attribute("apac.region", "sg")
        # APAC: groundcover correlates this custom span
        # with the eBPF-captured HTTP and SQL traces
        # for the same request — unified APAC trace view
        ...

APAC eBPF Observability Tool Selection

APAC Need                          → Tool             → Why

APAC Cilium network debugging      → Hubble            Built-in Cilium;
(network policy, DNS, flows)       →                  zero extra agents;
                                                       APAC L7 flow search

APAC instant K8s observability     → Pixie             Zero code changes;
(no instrumentation, fast)         →                  SQL/HTTP auto-capture;
                                                       APAC in 5 minutes

APAC Datadog-like platform         → groundcover       APM + infra correlated;
(APM + infra, lower cost)          →                  OTel compatible;
                                                       APAC in-cluster storage

APAC full-stack OTel platform      → Grafana LGTM      Mature; scalable;
(manual instrumentation acceptable) →                  APAC self-hosted option

APAC managed APM (no ops burden)   → Datadog / NR      Mature; APAC support;
                                   →                  higher cost per host

Related APAC Observability Resources

For the tracing tools (Jaeger, OpenTelemetry, SigNoz) that receive APAC traces from both eBPF auto-instrumentation and manual OTel SDK instrumentation, see the APAC distributed tracing guide.

For the Cilium CNI that Hubble extends with network observability, see the APAC Kubernetes networking guide.

For the continuous profiling tools (Pyroscope, Parca) that use eBPF for CPU profiling alongside Pixie's trace collection, see the APAC continuous profiling guide.

Beyond this insight

Cross-reference our practice depth.

If this article matches your stage of thinking, the underlying capabilities ship across all six pillars, ten verticals, and nine Asian markets.

All insights · Case studies · AI tools · Encyclopedia
Keep reading

Related reading

Blog

APAC AI Execution Infrastructure Guide 2026: E2B, Baseten, and Cerebrium

A practitioner guide for APAC AI engineering teams selecting execution infrastructure for AI agent code sandboxes, ML model inference, and serverless GPU compute in 2026 — covering E2B as secure cloud sandboxes for running LLM-generated Python code in isolated environments, enabling APAC AI data analyst and coding agent applications to execute arbitrary code safely without production infrastructure risk; Baseten as a managed ML model inference platform that converts PyTorch and HuggingFace models to auto-scaling GPU APIs via its Truss packaging framework, with TensorRT optimization and scale-to-zero for APAC variable traffic workloads; and Cerebrium as a serverless GPU cloud with sub-second cold starts on H100/A100 hardware, charging per GPU-second for APAC teams with bursty inference or training workloads who need flexible access to high-end GPU without committed instance costs.

 Blog

APAC Computer Vision Deployment Guide 2026: Ultralytics, LandingAI, and Roboflow Inference

A practitioner guide for APAC ML and engineering teams building and deploying computer vision systems in 2026 — covering Ultralytics YOLO as the state-of-the-art real-time CV framework for training, fine-tuning, and exporting YOLO models to TensorRT, ONNX, and TFLite for APAC edge and cloud deployment with one Python API; LandingAI as a no-code visual inspection platform enabling APAC factory quality engineers to build defect detection models using active learning with 50-200 labeled images and no ML expertise, with edge deployment for on-premise factory inference; and Roboflow Inference as an open-source CV model serving engine that deploys YOLO, GroundingDINO, and SAM2 as Docker APIs with one command, with Workflows for chaining multi-model CV pipelines into single API calls for APAC engineering teams.

 Blog

APAC ML Experiment Tracking and Data Versioning Guide 2026: DagsHub, Aim, and DVC

A practitioner guide for APAC data science teams implementing ML reproducibility through data versioning and experiment tracking in 2026 — covering DVC as a Git-compatible data version control tool that tracks large datasets and model artifacts in APAC cloud storage while storing lightweight metadata in Git, enabling reproducible ML pipelines with pipeline stage caching that skips unchanged preprocessing stages; DagsHub as an integrated ML project collaboration platform combining Git hosting, DVC data versioning, MLflow-compatible experiment tracking, and model registry in a GitHub-like interface; and Aim as an open-source self-hosted ML experiment tracker providing APAC regulated industry teams with complete data sovereignty over training metadata, rich run comparison, and hyperparameter visualization without cloud vendor dependency.

Want this applied to your firm?

We use these frameworks daily in client engagements. Let's see what they look like for your stage and market.

Talk to AIMenta