Learn OpenClaw - Core Concepts & Main Architecture

#Introduction

Welcome to episode 2 of the Learn OpenClaw series! In episode 1 you understood OpenClaw's position in the cloud native ecosystem: a policy orchestration layer that can coexist with a CNI and service mesh. Now we'll pop the hood and look at its architecture.

This is the most fundamental episode in the first phase. Everything you learn afterwards — installation, network policy, ingress, security, observability — stands on understanding how OpenClaw is structured. If episode 1 answered "why", episode 2 answers "how".

We'll break down three major components: the control plane, the data plane, and the policy engine. Then we'll trace the data flow and policy enforcement, and close with the concepts of network policies, service mesh integration, and observability.

#Architecture Map: Three Main Components

OpenClaw is designed with a clear separation between what decides and what executes. This separation allows one policy to be applied consistently across many execution points.

#Control Plane

The control plane is the brain of OpenClaw. It stores all policy definitions, validates changes, and synchronizes decisions to the data plane. Practically, the control plane interacts with Kubernetes through CustomResourceDefinitions — every policy you write is a CR watched by the controller.

Because the control plane stores policies, it's also responsible for versioning and audit: who changed what, when, and from which version to which version. This is why OpenClaw supports GitOps — the control plane can compare the desired configuration with the actual state.

kubectl get pods -n openclaw-system -l component=control-plane{:bash}

#Data Plane

The data plane is the layer that actually executes decisions. In OpenClaw, the data plane can take the form of a proxy injected into every Pod, a network hook, or an integration with another component's data plane such as Envoy or Cilium.

The data plane receives rules from the control plane, then applies them to every passing request: checking HTTP method, headers, source workload identity, and deciding allow or deny. Because the data plane sits on the traffic path, its performance must be maintained — that's why complex rule evaluation is usually compiled first into a form that executes quickly.

kubectl get pods -l app=payments,openclaw-dataplane=true{:bash}

#Policy Engine

The policy engine is the center of rule evaluation. When a request enters the data plane, the data plane asks the policy engine for a decision, or uses the already-synchronized compilation results. The engine evaluates rules against the request context: source service, destination service, path, method, headers, and environmental conditions.

The common approach is compiled policies: rules are translated into a compact representation so evaluation on the traffic path stays fast. This matters for high-throughput workloads.

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: api-v1-readonly
spec:
  priority: 10
  match:
    service: api
    path: "/v1/**"
  rules:
    - allow:
        methods: [GET]

#Data Flow and Policy Enforcement

Let's follow one request end to end. Imagine service web calls service api:

1. The request from web enters the data plane that accompanies it.
2. The data plane collects context: web's identity, the api target, path, and method.
3. The policy engine evaluates the context against all relevant policies, ordered by priority.
4. An allow or deny decision is returned; if allowed, the request is forwarded; if denied, a 403 response is sent.
5. The whole event is recorded as an observability event.

This flow runs for every request, not just the first one. That's why consistency of decisions between the control plane and data plane is so important — if they diverge, policy enforcement can't be trusted.

Synchronization between the control plane and data plane is usually asynchronous: the control plane pushes the latest policy configuration, then the data plane applies it and reports status back. This model is deliberately eventually-consistent so policy changes don't require downtime, but it means policy status can briefly lag before every data plane receives it. When debugging, always compare the last update time in the control plane with the last sync time of the data plane.

#Network Policies, Service Mesh Integration, and Observability

#Network Policies

Network policy in OpenClaw describes who may talk to whom. The difference from Kubernetes' built-in NetworkPolicy: OpenClaw policies are aware of workload identity, application protocols, and request context — not just IPs and ports. We'll write policies like this in episode 4.

#Service Mesh Integration

Because OpenClaw isn't a full mesh, it integrates policy decisions into an existing mesh. When connected to a mesh like Istio or Linkerd, OpenClaw can translate its policies into configuration the mesh understands, or act as an OpenClaw data plane that sits alongside the mesh's sidecar. Episode 12 will cover this specifically.

#Observability

Every policy decision produces an event: source service, destination service, decision, and reason. These events are exported as metrics and logs that Prometheus and Grafana can consume. Observability isn't an add-on feature — it's the primary way you verify that policies actually work the way you imagine.

#Wrap-Up

In episode 2 you broke down OpenClaw's architecture: the control plane as the brain that decides and stores policies, the data plane as the hands that execute decisions on the traffic path, and the policy engine as the center of rule evaluation. You also traced the full data flow and understood how network policies, mesh integration, and observability come together.

Key takeaways:

• The control plane decides; the data plane executes; the two must always stay in sync.
• The policy engine evaluates rules against the full request context, not just IPs.
• Every request goes through evaluation: context, evaluation, decision, execution, and recording.
• OpenClaw policies are aware of workload identity and application protocols, on top of Kubernetes' built-in NetworkPolicy.
• Observability is part of the policy verification loop, not an add-on feature.

In the next episode, episode 3, we'll install OpenClaw on your cluster: add the helm repository, deploy the components, verify everything is alive, then run a sample application that uses OpenClaw. This is where theory starts turning into real practice.