Related Issues/PRs
Background
As discussed in reshaprio/reshapr#123 (comment), the logic for injecting the Reshapr Proxy as a sidecar container into Kubernetes Pods is being migrated from the main reshapr repository to reshapr-controllers to enforce separation of concerns.
The original implementation proposed in PR #147 used a JAX-RS REST endpoint to manually generate JSON patches. This logic will be adapted to integrate smoothly with the java-operator-sdk framework currently used in the admission module.
Proposed Architecture
To properly address sidecar injection, routing, and session affinity natively in Kubernetes, the implementation will consist of two parts:
1. Mutating Admission Webhook (admission module)
The existing PodMutator will be updated to:
- Intercept Pod creation requests and check for the
io.reshapr/inject: "true" annotation.
- Inject the
reshapr-proxy sidecar container into the Pod spec.
- Check for the
io.reshapr/control-plane-url annotation and mount it as the RESHAPR_CONTROL_PLANE_URL environment variable in the sidecar.
- Check for the
io.reshapr/token-secret-name annotation and mount the Kubernetes Secret as an env or envFrom binding for the sidecar.
- Dynamically inject the label
reshapr.io/proxy-injected: "true" into the mutated Pod's metadata for subsequent routing.
2. Companion Kubernetes Operator (operator module)
A new reconciler (DeploymentProxyReconciler) will be created to:
- Watch
Deployment resources annotated with io.reshapr/inject: "true".
- Automatically provision a dedicated Kubernetes
Service (e.g., reshapr-proxy-<app-name>) for routing traffic to the injected proxy instances.
- Ensure the dedicated
Service is configured with sessionAffinity: ClientIP so that subsequent MCP requests map to the correctly initialized Pod.
- Configure the Service selector to match the
reshapr.io/proxy-injected: "true" label dynamically applied by the Mutating Webhook.
Additional Context
By provisioning a dedicated Service with ClientIP session affinity, we avoid interfering with or polluting the target application's primary Service while fulfilling MCP routing requirements for the proxy.
Related Issues/PRs
Background
As discussed in reshaprio/reshapr#123 (comment), the logic for injecting the Reshapr Proxy as a sidecar container into Kubernetes Pods is being migrated from the main
reshaprrepository toreshapr-controllersto enforce separation of concerns.The original implementation proposed in PR #147 used a JAX-RS REST endpoint to manually generate JSON patches. This logic will be adapted to integrate smoothly with the
java-operator-sdkframework currently used in theadmissionmodule.Proposed Architecture
To properly address sidecar injection, routing, and session affinity natively in Kubernetes, the implementation will consist of two parts:
1. Mutating Admission Webhook (
admissionmodule)The existing
PodMutatorwill be updated to:io.reshapr/inject: "true"annotation.reshapr-proxysidecar container into the Pod spec.io.reshapr/control-plane-urlannotation and mount it as theRESHAPR_CONTROL_PLANE_URLenvironment variable in the sidecar.io.reshapr/token-secret-nameannotation and mount the Kubernetes Secret as anenvorenvFrombinding for the sidecar.reshapr.io/proxy-injected: "true"into the mutated Pod's metadata for subsequent routing.2. Companion Kubernetes Operator (
operatormodule)A new reconciler (
DeploymentProxyReconciler) will be created to:Deploymentresources annotated withio.reshapr/inject: "true".Service(e.g.,reshapr-proxy-<app-name>) for routing traffic to the injected proxy instances.Serviceis configured withsessionAffinity: ClientIPso that subsequent MCP requests map to the correctly initialized Pod.reshapr.io/proxy-injected: "true"label dynamically applied by the Mutating Webhook.Additional Context
By provisioning a dedicated
ServicewithClientIPsession affinity, we avoid interfering with or polluting the target application's primary Service while fulfilling MCP routing requirements for the proxy.