Kubernetes Development Experience

Connecting an existing Kubernetes cluster to the Crafting system (see Connected Infra) enables a set of Kubernetes development features from within Crafting sandboxes:

In-cluster Network Bridging: Direct access to pod IPs and Kubernetes Services from the sandbox.
Traffic Interception and Rerouting: Replace a deployed service with your in-development version.
Pod Filesystem and Environment Mirroring: Mirror the filesystem and environment of a running pod.
Kubernetes API Server Proxy: Access the cluster API from within the workspace.

In-cluster Network Bridging

After connecting a Kubernetes cluster and turning on Kubernetes Interception (cs k8s intercept start), the cluster's internal network is bridged into the sandbox's private network. Pod IPs and Kubernetes Services become directly accessible from any workspace, just as if the workspace were a pod in the cluster.

For example, after starting interception:

# Access a Kubernetes Service by DNS name
curl http://hello.default.svc.cluster.local

# Access a Pod directly by IP
curl http://POD-IP:8000

This allows an in-development service running in the sandbox to access all cluster dependencies (databases, caches, other services) using their cluster-native hostnames and addresses — with no configuration changes.

Traffic Interception and Rerouting

When turning on Kubernetes Interception, rules can be specified to intercept incoming traffic from running pods in the cluster and reroute it to a workload in the sandbox. This allows a developer to:

Make code changes locally in the sandbox.
Launch the service in the sandbox.
Test a complete end-to-end flow using the full production cluster deployment.

The target service is virtually replaced by the one running in the sandbox, without building a new container image or redeploying anything in the cluster.

Header-Based Filtering

By leveraging standard tracing headers (like tracestate and baggage) or custom headers, interception can be filtered so only requests with matching headers are rerouted. This means:

Multiple developers can intercept the same service simultaneously without interfering with each other.
The connected Kubernetes cluster remains immutable — production traffic is unaffected.

Kubernetes Endpoint and Tracing Headers

A Kubernetes Endpoint can be added to a sandbox to generate tracing headers in requests for end-to-end flows. This endpoint forwards traffic — with tracing headers injected — to either a Kubernetes Service or Ingress. All workloads in the end-to-end path must propagate these headers from incoming to outgoing requests.

The following tracing headers are injected by default when a Kubernetes endpoint is used:

tracestate: crafting-sandbox=$SANDBOX_ID
baggage: crafting-sandbox=$SANDBOX_ID

If workloads propagate other headers, they can be specified in the interception conditions using the -H flag. For example:

cs k8s intercept start -H 'Custom-Header: from{{.SandboxID}}' --ingress k8s:service:default:hello

In addition to .SandboxID, the following template variables are available in header values:

Variable	Description
`.SandboxID`	The unique identifier of the current sandbox
`.EndpointDNSSuffix`	The DNS suffix for endpoints; same as the `SANDBOX_ENDPOINT_DNS_SUFFIX` environment variable inside a workspace
`.EndpointBaseDomain`	The base domain of endpoints

Mirroring Pod Filesystem and Environment

By default, when Kubernetes Interception is turned on and targeting a specific workload in the cluster, the root filesystem and environment variables from one of the pods are mirrored into the sandbox workspace.

For example:

cs k8s intercept start -M deploy/default/hello:$SANDBOX_WORKSPACE

This makes the following available inside the workspace:

Path	Contents
`/run/sandbox/svc/k8s/CLUSTER/default/deploy/hello/rootfs`	Mirrored root filesystem of the pod
`/run/sandbox/svc/k8s/CLUSTER/default/deploy/hello/env`	Environment variables from the pod

The mirrored filesystem includes all mounted volumes. Combined with the environment variables, this makes it possible to run the in-development service under the exact same conditions as the Kubernetes pod.

Kubernetes API Server Proxy

After a Kubernetes cluster is connected, the cluster's API server can be accessed from any workspace using the URL:

http://CLUSTER.k8s.g.sandbox