Real Kubernetes, minus the control-plane toil
Everything below is straight from the platform docs — no vapourware.
Versioned clusters
Choose your Kubernetes version at creation, with release and support status labelled. Upgrade the master node plan later as control-plane load grows — no downgrade surprises.
Worker node pools
Group workloads into pools with their own CPU/memory/disk configs. Add, edit, resize, reboot or delete pools independently — compute-heavy and memory-heavy apps stop fighting.
Pool autoscaling
AutoScale pools scale between min and max on CPU or memory thresholds, a custom attribute you push via API, or a cron schedule — the same policy engine as Auto Scaling.
Persistent volumes
Console-managed PVs plus dynamic provisioning through a Ceph RBD CSI StorageClass. PVCs bind on demand, volumes expand online (never shrink — the K8s API forbids it, and we say so).
MetalLB LoadBalancer
Native MetalLB integration: reserve service IPs into LB IP pools and expose Services of type LoadBalancer on floating external IPs that survive node failure. Or front it with a managed LB.
GPU & MIG ready
Run inference and training on E2E GPU nodes. MIG partitioning on H100/H200 slices one GPU into hardware-isolated instances for notebooks and lightweight serving — see TIR for the fully managed route.
How it works
From console to kubectl get nodes in four steps.
Configure the cluster
Pick the Kubernetes version, a default or custom VPC (mandatory — all nodes draw IPs from its pool), optional cluster encryption, and a security group allowing port 6443 for the API server.
Add node pools
Create static pools with a fixed worker count, or AutoScale pools with min/max nodes and an elastic, scheduled, or combined scaling policy.
Create & connect
Click Create Cluster; minutes later download the kubeconfig, run kubectl --kubeconfig=... proxy, and sign in to the Kubernetes dashboard with your token.
Ship workloads
Pull images from the private container registry with registry secrets, claim PVCs, reserve LoadBalancer IPs, and watch monitoring, alerts and the activity timeline.
Node pool scaling policies
Every AutoScale pool picks one of these, as documented.
| Policy | Scales on | How you configure it |
|---|---|---|
| Elastic — Default (CPU) | CPU utilization threshold | Set the threshold; nodes are added as CPU rises and removed as it falls |
| Elastic — Default (Memory) | Memory utilization threshold | Same mechanics, driven by memory instead of CPU |
| Elastic — Custom | Any attribute you define (e.g. NETTX, DISKWRIOPS, queue depth) | Name the parameter, set up/down thresholds, watch period and cooldown; update its value via a generated cURL command from scripts, hooks or cron |
| Scheduled | Time — cron recurrence | Upscale and downscale recurrences with target node counts for predictable peaks |
| Elastic + Scheduled | Both together | Combine a metric-driven policy with a time-driven baseline |
Master and worker nodes are standard E2E compute plans on the rate card — e.g. a modest worker pool of 3 nodes can start around ₹6/hr per node*.
Day-2 is documented too
The unglamorous parts are where managed Kubernetes earns its keep.
Security by default
Security groups as virtual firewalls on every cluster (at least one always attached), optional cluster encryption at creation, private IPv4 within your VPC, and automatic SSL certificate renewal for the cluster — manual override included.
Monitoring & alerts
Free per-node monitoring — CPU, disk read/write, network traffic — plus threshold alerts (trigger type, operator, severity) routed to user groups, and a full activity timeline of cluster actions.
Registry & secrets
Kubernetes Secrets keep credentials out of images; docker-registry secrets pull from E2E's private registry (registry.e2enetworks.net) with one kubectl command.
Frequently Asked Questions
Everything you need to know about Managed Kubernetes.
Managed Kubernetes
Yes — download the kubeconfig from the cluster details page and use standard kubectl against the API server (port 6443 must be open in the security group). The Kubernetes dashboard is available via kubectl proxy with token sign-in.
Pools scale on CPU, memory, cron schedules, or any custom attribute you publish — including queue depth or request backlog from an inference service. For fully managed autoscaling model endpoints without cluster ops, see the TIR platform, which is Kubernetes-native under the hood.
Multi-Instance GPU partitions one physical NVIDIA GPU (supported on H100 and H200) into hardware-isolated instances, each appearing as its own GPU type in Kubernetes via the NVIDIA device plugin. It's offered with E2E private clusters and suits notebooks, inference services and lightweight training that don't need a full GPU.
Yes — resize node pools, add or delete pools, power nodes on/off and reboot them, and upgrade the master node plan to a higher tier in the same series (downgrades aren't allowed). Cluster deletion removes all nodes, volumes and configuration permanently.
In E2E's Indian data centers (Delhi NCR and Chennai), operated by an NSE & BSE-listed Indian company — relevant if you have data-residency obligations.
Your cluster could be Active before standup ends
Bring your own manifests, we handle the rest.