Add optional SQL proxy sidecar for OpenShift compatibility#808
Draft
Add optional SQL proxy sidecar for OpenShift compatibility#808
Conversation
b9fa69c to
6e2aea9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR introduces an optional sidecar container (
crate-control) for CrateDB pods that acts as a lightweight SQL proxy for operator actions. The goal is to replace the operator's current use ofpod_execfor administrative SQL operations.pod_execis restricted or unsupported in OpenShift, which prevents the operator from performing required bootstrap and maintenance tasks.With this change, the operator can communicate with CrateDB via an in-cluster HTTP endpoint instead of exec into pods. This mechanism is fully backwards compatible: existing clusters without the sidecar continue to use
pod_exec.High-level design
Sidecar
Each CrateDB pod gets an additional container exposing a small HTTP API:
POST /exec5050The sidecar:
http://localhost:4200/_sql)Because requests originate from localhost, existing host-based authentication remains unchanged:
Authentication between operator and sidecar is handled exclusively via the injected bootstrap token.
The implementation uses
Bottle+waitress+ Python stdlib (urllib) to keep the memory footprint small.Operator integration
When enabled, the operator:
clusterIP: None) for reaching sidecarspod_execThe sidecar image version is aligned with the operator version (same tag/commit via CI).
For clusters created before this feature (or when the sidecar is not present), the operator automatically falls back to the existing
pod_execbehavior.OpenShift testing guide
The following steps describe how to manually verify the operator and sidecar on an OpenShift cluster.
Prerequisites
Ensure the cluster has:
crate-operatorRBAC and storage classes applied1. Build and deploy the operator
From the
crate/crate-operatorrepository:Deploy the operator using the newly built image.
2. Build and publish the sidecar image
From the sidecar directory:
Configure the operator to use this image:
Restart the operator after updating this env variable.
3. Deploy a CrateDB cluster
Create a new CrateDB custom resource.
Verify:
crate-controlsidecar4. Verify logs and behavior
Check operator and sidecar logs
Confirm:
pod_execcalls are used when the sidecar is present/healthendpoint reports ready/execNotes
Checklist
CHANGES.rst