Component versions and operations

Component versions for the Azure In-VPC deployment, the Kubernetes workloads it runs, how to upgrade them, the upgrade order, and how to roll back.

This page summarizes what an Azure In-VPC deployment runs and how to operate it.

Current versions

Component	Version
Kubernetes (AKS)	1.29+ (1.33 ideal)
Karpenter (AKS provider)	1.7.1
cert-manager	v1.17.2
Console	1.0.4603
Envoy	1.37.1-pgrouter-e6.36
XDS	1.0.350
e6-operator	Latest from your release
CRDs	~25 resources in the e6data.io group

Image tags for the operator and workspace components come from your e6data release notes. The versions here are accurate as of the most recent release; confirm the latest validated set with your onboarding engineer.

Install and upgrade pattern

Cluster-wide components (cert-manager, the operator) are installed with Helm. The e6-operator CRDs are applied with kubectl apply --server-side rather than Helm, because the combined CRD payload exceeds Helm's release-secret size limit. Workspace components (Console, Envoy, XDS) are driven by the operator from the NamespaceConfig and QueryRouter custom resources - to change their image tags, edit those resources and re-apply; the operator rolls out the new versions in place, with no downtime for queries.

Kubernetes workloads reference

Platform components (e6operator namespace, plus kube-system):

Kind	Name	Description
Deployment	e6operator	Controller managing all e6data CRDs.
Service	e6operator-webhook-service	Admission webhook for custom-resource validation.
Deployment	cert-manager (+ webhook, cainjector)	Issues the operator's webhook serving certificate.
Deployment	karpenter (in kube-system)	Provisions e6operator and engine nodes.

Workspace components (per workspace namespace):

Kind	Name	Description
Deployment	console	Web console UI and backend.
Deployment	<ws>-qr-envoy	Query-routing proxy (TLS termination, JWT).
Deployment	<ws>-qr-xds	Dynamic routing configuration for Envoy.
Deployment	mds-schema / mds-storage	Metadata services (created on demand).
DaemonSet	nvme-raid-disks-<ws>	Local-NVMe init (only on L-family nodes).
CronJob	compaction	Metadata compaction job.
Service	<ws>-qr-envoy-external	LoadBalancer for query and console traffic.

Resource footprint

Category	Cluster-level	Per workspace
VNet and networking	~6 resources (VNet, subnet, NAT GW + IP)	1 Load Balancer
AKS	1 cluster + system node pool	-
Managed Identities	1–2 (Karpenter, optional cert-manager)	1 (engine, shared by all components)
Federated credentials	1–2	2+ (engine, console; one per add-on SA)
Storage	1 ADLS Gen2 account	1 blob container
Role assignments	~6	2+ (metadata RW, data lake RO)
VMs	2 (system nodes)	0–N (engine nodes, scale to zero)

Upgrade order

If upgrading multiple components in one window:

1. cert-manager (if changed) - generally only every several months.
2. e6data CRDs - required before operator upgrades that depend on new fields.
3. e6data operator - the controller that manages all workspaces.
4. Workspace components (Envoy, XDS, Console) - by editing the workspace custom resources; the operator rolls them out.

Rolling back

If an upgrade causes issues, re-apply the previous image tag (for workspace components, in the NamespaceConfig/QueryRouter; for the operator, via helm upgrade with the prior tag). Coordinate rollbacks with your e6data support engineer so no in-flight changes are lost.

Where to see what's actually running

# Operator
kubectl get deployment e6operator -n e6operator \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# Workspace components (replace <WORKSPACE_NAME>)
kubectl get pods -n <WORKSPACE_NAME> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

# cert-manager
kubectl get deployment cert-manager -n cert-manager \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

See also

• Configure registry, Kubernetes, and networking
• Troubleshooting