> ## Documentation Index
> Fetch the complete documentation index at: https://docs.e6data.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/query/clusters/create-and-manage) 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

```yaml theme={"theme":{"light":"github-light","dark":"github-dark"}}
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
```

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
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:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
# 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

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
# 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:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
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:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
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.

## See also

* [Create and manage clusters](/query/clusters/create-and-manage)
* [Lifecycle states and error codes](/query/clusters/lifecycle-states)
* [AWS In-VPC](/platform/deploy/aws-cloudprem) · [Azure In-VPC](/platform/deploy/azure-cloudprem)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.