Component Interaction Map

A summary of the main Runtime component relationships.

Agentic Friendly

Runtime components are easier to understand when viewed as relationships rather than isolated products.

Core Interaction Patterns

Network and exposure

  • MetalLB supports external service exposure in self-managed environments.
  • NGINX and APISIX expose and route user-facing traffic.
  • External DNS publishes hostnames for ingress and service endpoints.
  • cert-manager secures those endpoints with managed certificates.

Access and security

  • Keycloak provides identity for multiple Runtime UIs and APIs.
  • OpenFGA adds fine-grained authorization where simple role-based access is not enough.
  • OpenBao manages secrets and identity-bound access to sensitive values.
  • APISIX integrates with Keycloak for API-facing access control.

Execution and state

  • KubeAI orchestrates inference-serving workloads.
  • vLLM and FasterWhisper provide inference engines used within that serving layer.
  • Temporal and Argo Events handle workflow execution and event-based automation.
  • PostgreSQL stores structured operational state.
  • MinIO stores object-style data and shared artifacts.

Observability

  • Prometheus collects metrics from Runtime services.
  • Grafana Alloy forwards telemetry signals.
  • Loki stores logs.
  • Tempo stores traces.
  • Grafana brings these signals together into dashboards and operational views.

Delivery

  • GitLab produces versioned source and CI outputs.
  • Harbor stores images and artifacts.
  • Argo CD deploys the desired state into the cluster.

Important Examples

Some interactions are especially important in practice:

  • PgAdmin -> PostgreSQL PgAdmin exists to operate PostgreSQL more easily.
  • Grafana -> Prometheus, Loki, Tempo Grafana is the common interface for metrics, logs, and traces.
  • MinIO -> Argo Events, Argo Workflows, Tempo, KubeAI MinIO provides storage and credentials to several Runtime and higher-layer consumers.
  • Argo CD -> all platform components Argo CD is the main GitOps deployment engine across the stack.
  • GitLab and Harbor -> Argo CD GitLab and Harbor are upstream prerequisites because manifests, charts, and images must exist before Argo CD can deploy them.

Where To Go Next

For component-level details, use the Runtime components section. This page is intended as a summary of the main interaction model rather than an exhaustive dependency graph.

On this page