CloudPrem cluster operations

Manage e6data clusters in an In-VPC deployment with Kubernetes CRDs, kubectl, and GitOps - create, configure, scale, suspend, upgrade, and inspect.

In an In-VPC (CloudPrem) deployment, you can manage clusters through Kubernetes instead of the Console - using the QueryService custom resource, kubectl, and GitOps. Read Create and manage clusters first for cluster concepts, sizing, and lifecycle; this page covers doing the same through Kubernetes.

All examples use <NAMESPACE> for the namespace where e6data is installed.

How it works

The e6data operator watches for QueryService custom resources and reconciles them into the underlying deployments, services, and config that make up a running cluster. You create or patch a QueryService; the operator rolls out the desired state. Every operation - scaling, suspend, resume, version updates - is a change to the QueryService spec, which makes the model fully GitOps-compatible (commit the YAML and let Argo CD or Flux sync it).

Create a cluster

apiVersion: e6data.io/v1alpha1
kind: QueryService
metadata:
  name: analytics-prod
  namespace: <NAMESPACE>
spec:
  tenant: my-org
  workspace: production
  releaseRef: v2.14.0
  planner:
    replicas: 1
    queryTimeoutSeconds: 900
  queue:
    replicas: 1
  executor:
    replicas: 4
  autoSuspension:
    enabled: true
    maxIdleDurationMinutes: 30
  autoResume:
    enabled: true

kubectl apply -f cluster.yaml
kubectl get queryservice -n <NAMESPACE>

The operator provisions the cluster and moves it through Creating → Running.

Configure

The Console settings map to CRD fields: spec.planner.queryTimeoutSeconds, spec.queryResultCache.enabled / .ttlSeconds, spec.queryHistory.enabled, and spec.transpiler.enabled / .dialect. The CRD also exposes settings not in the Console:

Per-component resources - spec.planner.resources, spec.executor.resources (CPU/memory requests and limits).
Environment and config variables - spec.planner.environmentVariables, spec.planner.configVariables.
Scheduling - spec.tolerations, spec.podAnnotations, spec.podLabels to place cluster pods on dedicated node pools.
NVMe scratch - spec.nvme: true for spill-to-disk.
PostgreSQL gateway - spec.planner.pgGatewayEnabled and spec.gateway.serviceType.
Native executor - spec.nativeExecutor.enabled (a Rust-based engine) alongside or instead of the classic executor.

Scale

Each scaling mode maps to CRD fields, and you can also patch directly:

# Fixed size
kubectl patch queryservice analytics-prod -n <NAMESPACE> --type merge \
  -p '{"spec":{"executor":{"replicas":8}}}'

# Autoscaling
kubectl patch queryservice analytics-prod -n <NAMESPACE> --type merge \
  -p '{"spec":{"executor":{"autoscaling":{"enabled":true,"minExecutors":2,"maxExecutors":12}}}}'

QPS-based scaling uses spec.planner.qpsEnabled / qpsCount; scale-to-zero sets minExecutors: 0 with auto-suspension enabled.

Suspend and resume

# Suspend - scale all components to zero
kubectl patch queryservice analytics-prod -n <NAMESPACE> --type merge \
  -p '{"spec":{"planner":{"replicas":0},"queue":{"replicas":0},"executor":{"replicas":0}}}'

# Resume - restore replicas
kubectl patch queryservice analytics-prod -n <NAMESPACE> --type merge \
  -p '{"spec":{"planner":{"replicas":1},"queue":{"replicas":1},"executor":{"replicas":4}}}'

Or configure spec.autoSuspension (maxIdleDurationMinutes) and spec.autoResume (timeoutSeconds).

Version updates

Patch releaseRef to trigger a zero-downtime blue-green upgrade - the operator deploys the new version alongside the current one, switches traffic when healthy, drains the old version, and auto-rolls back on failure:

kubectl patch queryservice analytics-prod -n <NAMESPACE> --type merge \
  -p '{"spec":{"releaseRef":"v2.15.0"}}'

kubectl get queryservice analytics-prod -n <NAMESPACE> \
  -o jsonpath='{.status.deploymentPhase}'
# Stable → Deploying → Switching → Draining → Cleanup → Stable

Monitoring and diagnostics

The QueryService status sub-resource gives full visibility:

kubectl get queryservice analytics-prod -n <NAMESPACE> -o jsonpath='{.status.phase}'
kubectl get queryservice analytics-prod -n <NAMESPACE> -o yaml   # full status

Useful status fields: status.phase, status.ready, status.activeReleaseVersion, status.deploymentPhase, the per-component deployment health (plannerDeployment, queueDeployment, executorDeployment), and the activityHistory / scalingHistory / suspensionHistory lists.