Instead of installing, patching and monitoring the control plane, deploy your application directly. portvMind Kubernetes takes over the burden of container operations with a managed control plane, automated node pool scaling and CSI integration. Your team stays on the product instead of the infrastructure.
Kubernetes is an open-source orchestration platform that runs, scales and heals containerized applications on a cluster of servers. You define how many replicas of your application should run and how it should be updated; Kubernetes continuously maintains that state.
The difficulty of Kubernetes is not in using it but in operating it. Installing the control plane (API server, etcd, scheduler), making it redundant, running version upgrades without downtime and managing certificates all require serious expertise.
With portvMind Kubernetes, the control plane is our responsibility. You define your worker node pools and deploy your application. Thanks to the CSI integration, Block Storage attaches directly as a persistent volume, and Load Balancer exposes your services to the outside. The cluster runs in the Istanbul or Ankara region, and your data stays in the country.
Installation, redundancy, version upgrades and certificate management are on us.
When load rises, the number of worker nodes grows automatically according to the rules you define.
Attach Block Storage directly as a persistent volume.
Define pools with different instance types for different workloads — CPU and GPU run side by side.
Not a proprietary fork, but upstream Kubernetes. Your manifests and Helm charts run anywhere.
The cluster runs in the Istanbul and Ankara data centers, preserving data sovereignty.
| Feature | Detail |
|---|---|
| Control plane | Managed, redundant |
| Node pools | Multiple pools; instance type per pool — CPU and GPU side by side |
| Storage | Block Storage CSI driver |
| Load balancing | Load Balancer integration |
| Access | kubectl, console, OpenStack-compatible API |
| Metering | Per minute — based on worker node resources (GPU pools hourly) |
Supported Kubernetes versions and the upgrade schedule are published in the documentation.
For detailed technical specifications and release notes, see Documentation
Enter your cluster configuration and node pools, and see the total cost instantly.
Metering: Per minute — based on compute resources in worker node pools and attached storage
Billing is based on the compute resources in your worker node pools and the storage attached to them.
Your resources are metered for as long as they are running — you never pay for time you don’t use. In the console you can define a monthly or period-specific budget and get alerts when your spending reaches the 50%, 80% and 100% thresholds. Turn on overrun forecasting to see in advance whether your current consumption rate will take you over budget by the end of the period.
Alerts arrive by e-mail; with webhook support they can also be sent to Slack, Microsoft Teams or your own application.
Budget alerts send notifications; they do not stop resources automatically. You decide which resource to scale down.
The full pricing modelRunning AI workloads on containers makes resource management radically easier. You define GPUs as a separate node pool; your training jobs go to that pool and your serving workloads go to the general pool. Two different hardware profiles run side by side in the same cluster.
In practice this means: when a training job starts, only the GPU nodes come into play, and when the job ends the pool shrinks. You keep the expensive resource running only for as long as it is needed. You publish your model inference services in the same cluster behind a Load Balancer and scale the replica count with load.
Your training datasets sit in Object Storage; since the cluster is in the same region, there is no extra transfer cost for data access.
Resources in GPU node pools are metered hourly; the rest of the cluster continues to be metered per minute.
On the compute resources in your worker node pools and the storage attached to them. You can see your cost in advance by configuring your cluster in the calculator.
Standard Kubernetes manifests and Helm charts work compatibly. The guides in the documentation and the support team will guide you through the migration.
Yes. You can define one pool for general-purpose workloads and a separate pool for training or inference services that need GPUs, and route your workloads to the right pool with labels.
Yes. Since no dependency on a proprietary extension is created, you can move your workloads to any environment that runs standard Kubernetes.