> For the complete documentation index, see [llms.txt](https://docs.e6data.com/query-engine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.e6data.com/query-engine/guides/clusters/cloudprem-cluster-operations.md).

# 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-engine/guides/clusters/create-and-manage-clusters.md) 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
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
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
# 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
# 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
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
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-engine/guides/clusters/create-and-manage-clusters.md)
* [Lifecycle states and error codes](/query-engine/guides/clusters/lifecycle-states-and-error-codes.md)
* [AWS In-VPC](/query-engine/guides/deployment/aws-in-vpc.md) · [Azure In-VPC](/query-engine/guides/deployment/azure-in-vpc.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.e6data.com/query-engine/guides/clusters/cloudprem-cluster-operations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.