OpenKruise Agents v0.6.0 expands the runtime from a simple workload layer to a full data‑plane with its own traffic‑control components. The release introduces a traffic‑control‑plane service, a traffic‑proxy sidecar, and six new custom resources that enable declarative network policies, security profiles, and pool autoscaling. For practitioners, the shift means tighter outbound controls, automated credential injection, and the ability to upgrade or pause sandboxes without manual intervention.
Architecture Shift
The component count grows from four to six. The new traffic‑control‑plane distributes xDS configuration to Envoy‑based gateways, while the traffic‑proxy sidecar provides in‑pod L4 enforcement. Existing pieces remain:
- sandbox‑manager: northbound API, lifecycle, quota, and token orchestration.
- sandbox‑controller: reconciles Sandbox, SandboxSet, SandboxClaim, and warm‑pool resources; hosts admission webhooks.
- sandbox‑gateway: ingress gateway (host/path routing, wake‑on‑traffic) and egress gateway (policy‑driven L7 enforcement).
- agent‑runtime: sidecar exposing E2B‑compatible command, file, and port operations.
Two new CRDs double the total from six to twelve: PoolAutoscaler, TrafficPolicy, GlobalTrafficPolicy, SecurityProfile, and GlobalSecurityProfile. These resources create a multi‑tier control surface spanning cluster, tenant, and sandbox scopes.
Four Core Capabilities
1. Network Access Control & Token Management – Outbound traffic now follows a two‑stage path: L4 capture in the pod, then L7 inspection in the egress gateway. L4 denials are applied immediately; L7 policies (via SecurityProfile) can block, bypass, or transform requests, and can inject credentials from Kubernetes Secrets. Example TrafficPolicy configuration:
apiVersion: agents.kruise.io/v1alpha1
kind: TrafficPolicy
metadata:
name: sandbox-egress
spec:
selector:
matchLabels:
app: traffic-sample
egress:
rules:
- action: allow
to:
- service: {name: kube-dns, namespace: kube-system}
- action: allow
to:
- fqdn: api.example.com
- action: reject
ports:
- protocol: TCP
port: 443
to:
- cidr: 10.0.0.0/8
2. SandboxUpdateOps – Introduces checkpoint/restore and paused‑instance upgrades, allowing batch upgrades of hibernated sandboxes without waking each instance or losing filesystem state.
3. PoolAutoscaler – Declarative warm‑pool sizing with watermarks and optional cron schedules, enabling pre‑provisioned capacity for bursty workloads.
4. Automatic Pause/Resume – Probe‑driven idle detection, scheduled wake‑ups, and wake‑on‑traffic via the ingress gateway, reducing CPU consumption for idle sandboxes.
Operational and Security Implications
From a security perspective, outbound traffic is no longer left to the pod’s own networking stack; it is captured, inspected, and enforced centrally. This model reduces the attack surface for SSRF and credential leakage, especially when combined with token injection from Secrets. Practically, teams must adopt the new CRDs, define whitelist‑style TrafficPolicy rules, and ensure that required services (e.g., cluster DNS) are explicitly allowed.
Operationally, the checkpoint/restore path simplifies rolling upgrades across large sandbox fleets, while the PoolAutoscaler and auto‑pause features cut idle resource spend. However, the added components (traffic‑control‑plane, traffic‑proxy) introduce new failure domains that require health monitoring and observability.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Evaluate existing sandbox deployments for compatibility with the new data‑plane and migrate policies to the whitelist‑oriented TrafficPolicy model. Test checkpoint/restore workflows before large‑scale upgrades. Configure PoolAutoscaler to match expected burst patterns and enable auto‑pause to capture cost savings. Finally, instrument the traffic‑control‑plane and egress gateway to surface L4/L7 denials, ensuring that policy misconfigurations are caught early.
