Kubernetes on CloudPe — Frequently Asked Questions

Category: Compute · Kubernetes

This FAQ covers the most common technical and commercial questions customers ask when evaluating CloudPe Managed Kubernetes.

Cluster Basics & Versions

What Kubernetes versions does CloudPe support?

CloudPe offers multiple Kubernetes version templates at cluster creation time. Available versions are shown as selectable templates in the dashboard when you create a cluster. The underlying network plugin (CNI) depends on the version selected — see the Networking section below.

Where is Managed Kubernetes available?

Mumbai, across two zones: IN-WEST2 and IN-WEST3.

How do I create a cluster?

From the dashboard: Compute → Kubernetes → + Create Cluster. You’ll configure:

1. Cluster name, description, project, and region (region cannot be changed after creation)
2. A Kubernetes version template
3. Control plane: High Availability on/off, master count, and master node flavor
4. Worker nodes: node count, flavor, and container/Docker volume size per node
5. SSH key for node access (existing key or generate a new one)
6. Review the pricing estimate and configuration summary, then create

Cluster provisioning typically takes 10–15 minutes.

Can clusters also be managed via API instead of the dashboard?

Yes. CloudPe exposes the OpenStack Magnum API for full cluster lifecycle management — creating and listing cluster templates, creating/resizing/upgrading/deleting clusters, and managing worker node groups and autoscaling limits. This requires an OpenStack Application Credential, which only the project owner can generate.

Can I upgrade a cluster’s Kubernetes version after creation?

Yes, one minor version at a time (e.g. 1.31.2 → 1.32.13 → 1.33.10), via the dashboard or the Magnum API upgrade action. A few things to know:

• Node groups within a cluster can only differ by one minor version at a time.
• The Kubernetes API is unavailable during an update unless the control plane is running in HA mode.
• Cross-CNI version jumps may have specific requirements — check with support for your specific version path before upgrading a production cluster.

Compute & Scaling

Is the control plane free?

Yes. Kubernetes cluster management (the control plane) is provided at no charge. You are billed only for the compute resources of the master and worker node VMs you provision.

Is High Availability (HA) available for the control plane?

Yes. Enabling HA deploys 3 master nodes behind a Load Balancer running in Active/Active mode, instead of a single master. This removes the control plane as a single point of failure and is recommended for production clusters. Enabling HA brings the associated Load Balancer into your billing — see Additional Charges below.

Can worker nodes scale up and down?

Yes, both ways:

• Manual scaling — change the worker node count anytime from the cluster detail page, or via the Magnum API.
• Automatic scaling (Cluster Autoscaler) — enable autoscaling on a worker group and set a minimum/maximum size. Worker count increases automatically when pods are pending due to insufficient resources, and decreases when nodes sit idle.

You can also create additional worker groups with different node flavors (e.g. a dedicated high-memory pool) alongside your default worker group, and scale each independently.

Are Kubernetes worker nodes priced differently from a standalone VM?

No. Worker nodes are billed under the same pricing model as standard virtual machines — you pay only for the vCPU, RAM, block storage, and any floating/public IPs actually consumed.

Pricing

CloudPe Kubernetes pricing is based on the compute flavors you select for master and worker nodes — there are no separate fixed Small/Medium/Large Kubernetes packages. Total cost depends on:

• Master node flavor and count
• Worker node flavor and count
• Any additional services used (see below)

For current flavor rates and full pricing details, refer to the CloudPe Pricing page.

What’s chargeable beyond compute?

For exact current rates on any of the above, refer clients to the CloudPe Pricing page.

Storage

What CSI driver is used, and does it support VolumeSnapshot?

CloudPe uses the OpenStack Cinder CSI driver (cinder.csi.openstack.org), which supports the native VolumeSnapshotClass, VolumeSnapshotContent, and VolumeSnapshot CRDs for point-in-time volume snapshots.

• The CSI snapshotter version used must not exceed release-5.0 of kubernetes-csi/external-snapshotter.
• The snapshot CRDs and snapshot-controller must be installed into the cluster (they are not enabled by default) before snapshots can be created.
• deletionPolicy: Delete on a VolumeSnapshotClass removes the underlying snapshot when the VolumeSnapshot object is deleted; use Retain to preserve it independently.

Can each pod have its own dedicated Persistent Volume?

Yes. Dynamic provisioning works through a standard StorageClass (provisioner cinder.csi.openstack.org) → PersistentVolumeClaim → pod volumeMounts, and volumes can be sized as needed (e.g. 5Gi). The storage tier name used in the StorageClass (e.g. a specific NVMe tier) must match the tier name in CloudPe exactly, including case.

Can Persistent Volumes be resized later?

Yes — expansion only (e.g. 5Gi → 10Gi); shrinking is not supported. This requires allowVolumeExpansion: true on the StorageClass. After updating the PVC’s storage request, the pod or deployment must be restarted so the filesystem can grow into the new capacity. Existing data is not affected.

Networking

Which CNI plugin is used, and is NetworkPolicy enforced?

The CNI depends on the Kubernetes version selected at cluster creation:

• Older version templates use Flannel — NetworkPolicy objects can be created but are not enforced.
• Newer version templates use Cilium — NetworkPolicy is fully enforced.

Customers with a hard requirement for enforced NetworkPolicy should select a Cilium-based version template.

Can I provision an HTTP/HTTPS Load Balancer for application traffic?

Yes. CloudPe supports provisioning Layer 7 (HTTP/HTTPS) Load Balancers for Kubernetes workloads. See Pricing above for rates.

Can I provision a separate TCP Load Balancer for raw TCP passthrough (e.g. an SSH gateway)?

Yes. CloudPe supports Layer 4 (TCP) Load Balancers, allowing any custom TCP service or port to be exposed independently of the HTTP/HTTPS Load Balancer.

Do Load Balancers get a static/reserved public IP?

Yes. A static Floating/Public IP is assigned to the Load Balancer and remains associated with it as a stable endpoint.

Security & Access

What access do customers get to their cluster — kubeconfig only, or node-level access too?

Both. Customers receive a downloadable kubeconfig file from the dashboard for kubectl/API access, and can also SSH directly into master and worker nodes using the SSH key configured at cluster creation.

Monitoring

Is there built-in cluster monitoring?

Yes, as an opt-in feature enabled at cluster creation. It deploys:

• Prometheus (with node-exporter and kube-state-metrics)
• Alertmanager
• Grafana dashboards

Access is via kubectl port-forward to each component’s in-cluster service. This monitoring stack is provided as a convenience and should be supplemented with your own monitoring for production-critical workloads.

Advanced / API Reference

Cluster behavior (network driver, storage driver, volume sizes, autoscaler settings, component versions) is controlled through Magnum cluster template labels when using the API. CloudPe recommends always specifying explicit component version tags (never latest) for predictable cluster creation and upgrade behavior.

Common cluster creation issues and fixes:

• Floating IP quota exceeded → disable floating IP allocation in the cluster template.
• Load Balancer quota exceeded → disable the API Load Balancer in the cluster template unless HA is required.
• Volume quota exceeded → reduce container volume size, node count, or select a different volume type.