Belajar OpenClaw - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Selamat datang di episode 2 series Belajar OpenClaw! Di episode 1 kalian sudah memahami posisi OpenClaw di ekosistem cloud native: lapisan policy orchestration yang bisa hidup berdampingan dengan CNI dan service mesh. Sekarang kita akan membuka kap mesin dan melihat arsitekturnya.

Ini adalah episode paling fundamental di fase pertama. Semua yang kalian pelajari setelahnya — instalasi, network policy, ingress, security, observability — berdiri di atas pemahaman tentang bagaimana OpenClaw disusun. Kalau episode 1 menjawab "kenapa", episode 2 menjawab "bagaimana".

Kita akan membedah tiga komponen besar: control plane, data plane, dan policy engine. Lalu menelusuri alur data dan policy enforcement, dan menutup dengan konsep network policies, service mesh integration, dan observability.

#Peta Arsitektur: Tiga Komponen Utama

OpenClaw dirancang dengan pemisahan yang jelas antara yang memutuskan dan yang mengeksekusi. Pemisahan ini memungkinkan satu kebijakan diterapkan konsisten ke banyak titik eksekusi.

#Control Plane

Control plane adalah otak OpenClaw. Dia menyimpan seluruh definisi policy, memvalidasi perubahan, dan menyinkronkan keputusan ke data plane. Secara praktis, control plane berinteraksi dengan Kubernetes melalui CustomResourceDefinitions — setiap policy yang kalian tulis adalah sebuah CR yang diawasi oleh controller.

Karena control plane menyimpan kebijakan, dia juga yang bertanggung jawab atas versioning dan audit: siapa mengubah apa, kapan, dan dari versi berapa ke versi berapa. Inilah alasan OpenClaw mendukung GitOps — control plane bisa membandingkan konfigurasi yang diinginkan dengan keadaan aktual.

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

#Data Plane

Data plane adalah lapisan yang benar-benar mengeksekusi keputusan. Di OpenClaw, data plane bisa berwujud proxy yang disuntikkan ke setiap Pod, hook jaringan, atau integrasi dengan data plane milik komponen lain seperti Envoy atau Cilium.

Data plane menerima aturan dari control plane, lalu menerapkannya pada setiap request yang lewat: memeriksa metode HTTP, header, identitas workload asal, dan memutuskan allow atau deny. Karena data plane berada di jalur traffic, performanya harus dijaga — itulah mengapa evaluasi rule yang kompleks biasanya di-compile dulu menjadi bentuk yang cepat dieksekusi.

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

#Policy Engine

Policy engine adalah pusat evaluasi rule. Ketika sebuah request masuk ke data plane, data plane meminta keputusan ke policy engine, atau menggunakan hasil kompilasi yang sudah disinkronkan. Engine mengevaluasi rule terhadap konteks request: service asal, service tujuan, path, metode, header, dan kondisi lingkungan.

Pendekatan yang umum dipakai adalah compiled policy: rule diterjemahkan ke representasi yang ringkas sehingga evaluasi di jalur traffic tetap cepat. Ini penting untuk workload dengan throughput tinggi.

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

#Alur Data dan Policy Enforcement

Mari ikuti satu request end-to-end. Bayangkan service web memanggil service api:

1. Request dari web masuk ke data plane yang menemaninya.
2. Data plane mengumpulkan konteks: identitas web, target api, path, dan metode.
3. Policy engine mengevaluasi konteks terhadap semua policy yang relevan, diurutkan berdasarkan prioritas.
4. Keputusan allow atau deny dikembalikan; jika allow, request diteruskan; jika deny, response 403 dikirim.
5. Seluruh peristiwa dicatat sebagai event observability.

Alur ini dieksekusi untuk setiap request, bukan hanya yang pertama. Karena itu konsistensi keputusan antara control plane dan data plane sangat penting — jika keduanya berbeda, policy enforcement tidak bisa dipercaya.

Sinkronisasi antara control plane dan data plane biasanya berjalan asinkron: control plane mendorong konfigurasi policy terbaru, lalu data plane menerapkannya dan melaporkan status kembali. Model ini sengaja dibuat eventual-consistent supaya perubahan policy tidak membutuhkan downtime, tapi artinya status policy bisa sesaat tertinggal sebelum diterima seluruh data plane. Saat debugging, selalu bandingkan waktu update terakhir di control plane dengan waktu data plane terakhir sinkron.

#Network Policies, Service Mesh Integration, dan Observability

#Network Policies

Network policy di OpenClaw mendeskripsikan siapa boleh bicara dengan siapa. Bedanya dengan NetworkPolicy bawaan Kubernetes: policy OpenClaw sadar akan identitas workload, protokol aplikasi, dan konteks request — bukan hanya IP dan port. Kita akan menulis policy semacam ini di episode 4.

#Service Mesh Integration

Karena OpenClaw bukan mesh penuh, dia mengintegrasikan keputusan policy ke mesh yang ada. Saat terhubung dengan mesh seperti Istio atau Linkerd, OpenClaw bisa menerjemahkan policy-nya menjadi konfigurasi yang dimengerti mesh, atau menjadi data plane OpenClaw yang berdampingan dengan sidecar mesh. Episode 12 akan membahas ini secara khusus.

#Observability

Setiap keputusan policy menghasilkan event: service asal, service tujuan, keputusan, dan alasan. Event ini diekspor sebagai metrics dan logs yang bisa dikonsumsi Prometheus dan Grafana. Observability bukan fitur tambahan — dia adalah cara utama kalian memverifikasi bahwa policy benar-benar bekerja seperti yang kalian bayangkan.

#Penutup

Di episode 2 ini kalian sudah membedah arsitektur OpenClaw: control plane sebagai otak yang memutuskan dan menyimpan policy, data plane sebagai tangan yang mengeksekusi keputusan di jalur traffic, dan policy engine sebagai pusat evaluasi rule. Kalian juga menelusuri alur data lengkap dan memahami bagaimana network policies, integrasi mesh, dan observability menyatu.

Inti yang harus dibawa pulang:

• Control plane memutuskan; data plane mengeksekusi; keduanya harus selalu sinkron.
• Policy engine mengevaluasi rule terhadap konteks request lengkap, bukan hanya IP.
• Setiap request melewati evaluasi: konteks, evaluasi, keputusan, eksekusi, dan pencatatan.
• Policy OpenClaw sadar identitas workload dan protokol aplikasi, di atas NetworkPolicy bawaan Kubernetes.
• Observability adalah bagian dari loop verifikasi policy, bukan fitur tambahan.

Di episode 3 selanjutnya kita akan menginstal OpenClaw di cluster kalian: menambahkan repository helm, menyebarkan komponen, memverifikasi semuanya hidup, lalu menjalankan sample application yang memakai OpenClaw. Inilah saat teori mulai berubah menjadi praktik nyata.