Managed Kubernetes
Move your applications to Kubernetes with every layer underneath ready
Once your order is approved, your cluster is built automatically together with its network, load balancer, public IP and private image registry. Deploy with full admin access and the tools you already use, while your data stays in Türkiye.
Why now
- Your services run as containers spread over a few virtual servers, and every release is manual. When one server goes down its services go with it; on Kubernetes the same services spread across nodes and a lost replica comes back on another one.
- On campaign morning the order service slows under load while the reporting service on the same server competes for resources. On Kubernetes each service scales on its own, so only the busy one gets more replicas.
- Your self-built cluster keeps its control plane on a single server, and nobody can deploy while it reboots. Here the control plane runs on three nodes and the API keeps answering when one of them fails.
- Pull limits on a public registry keep stalling new environment builds, and the team waits for hours. On Nesnet, cluster components and public images come from Nesnet's own registry and its cache.
- A customer has written data residency in Türkiye into the contract, and your overseas Kubernetes service cannot meet it. Nesnet clusters run in two data centres in Türkiye, and the data never leaves the country.
What changes
| Today | With Nesnet |
|---|---|
| Network, load balancer, storage and registry are set up one by one, and the cluster is ready weeks later. | Every layer is built in one run when the order is approved, and the first cluster is usable in under half an hour. |
| The control plane lives on one server; lose it and you lose deployments too. | Lose one of three control-plane nodes and the API keeps running at the same kubeconfig address. |
| Every new service needs its own public IP, its own rule and a ticket to the network team. | Declare the service as a LoadBalancer and the public IP and load balancing come with it. |
| A Kubernetes upgrade turns into a weekend project. | Start the upgrade from the portal, and workers are replaced by nodes built on the new version. |
| Your support ticket bounces between network, storage and Kubernetes vendors. | The same Nesnet team builds and runs the cluster and everything under it, so you report a problem in one place: Nesnet’s support team. |
From today to live: how it works
- 1
Discovery call
Settle with Nesnet's team how many clusters, which node size and how many workers you need. You review your current containers and manifests together and agree the order in which they move.
- 2
Quote and order
The quote is made up of cluster, worker node and load balancer lines. The moment the order is approved, provisioning starts without any further request from you.
- 3
The cluster builds itself
Edge gateway, egress IP, network, load balancer and cluster are created in sequence by Nesnet's automation. When the portal shows the cluster as ready, you download the admin kubeconfig.
- 4
First deployment
Push your images to the private registry, deploy with kubectl or Helm and publish services through a LoadBalancer or Ingress. If you are moving an existing system, a non-critical service is tried on the new cluster first.
- 5
Grow and upgrade
As load grows, resize worker pools or add new ones, and start an upgrade from the portal when a new Kubernetes version arrives. Patches for the platform underneath are applied by Nesnet's team on a regular cycle.
What you get
A cluster ready in half an hour
Provisioning starts the moment the order is approved, and the edge gateway, egress IP, network, load balancer and cluster are created in sequence by a single automation run. In Nesnet's own measurement, the first cluster was usable with all of those layers in about 22 minutes.
An API that never hangs on one server
Production clusters run the control plane on three separate nodes, so the Kubernetes API keeps answering when one is lost. The API address sits on a fixed virtual IP, so you never have to update your kubeconfig as nodes change.
Publish a service with one line
Declare a service of type LoadBalancer and a virtual service opens on the load balancer, with a public IP from Nesnet's own address block. The load balancer is included with every cluster, so there is no appliance to order and no ticket for the network team.
Many services behind one address
Ingress rules route outside HTTP and HTTPS traffic to the right service inside the cluster by host name and path. Even with dozens of microservices, you do not have to set aside a public IP for each one.
Data stays put when pods move
Applications that hold databases and files keep their persistent volumes on distributed NVMe storage rather than on the node. When a pod moves to another node its volume follows, and the application comes back up with the same data.
A deleted claim keeps its disk
When the cluster is created you choose the default storage class's file system (ext4 or xfs) and its reclaim policy. With Retain, deleting a PersistentVolumeClaim leaves the disk in place, and the data on it can be recovered by hand.
Separate worker pools for separate jobs
Open separate worker pools for web traffic, background jobs and databases, each with its own node size, count and disk size. Pools are added and resized from the portal, so in a busy period only the pool that needs it gets more nodes.
Start small and add nodes as you grow
Worker nodes come in S (2 vCPU, 4 GB RAM), M (4 vCPU, 8 GB) and L (8 vCPU, 16 GB). A test environment starts on a few small nodes and production grows on large ones, with the worker count changed through a single value in the cluster definition.
Upgrade Kubernetes from the portal
When a newer Kubernetes version is available, an upgrade option appears in the cluster details and starts with a single action. Workers are never patched in place; nodes built on the new version take over, and a progress indicator shows in the cluster list meanwhile.
Images in a registry of your own
A private image registry open only to your organisation comes with the cluster, and every image you push is scanned for vulnerabilities. You see an image carrying a known flaw before it reaches production, then rebuild and push the fixed version.
Outside registry outages do not stop you
Images you pull from public registries are served from the cache in Nesnet's own registry instead of being downloaded again for every environment. A public registry's pull limit or outage never leaves the environment you need on campaign day half-built.
Full control with the tools you know
Download the cluster's admin kubeconfig from the portal and keep working with kubectl, Helm and your current manifests without changing a thing. Installing operators, CRDs or your own controllers never requires anyone's permission.
Every cluster on one screen
See whether each of your development, test and production clusters is still provisioning or ready, along with its control-plane and worker counts, on one screen in the cloud portal. Nobody has to email support to find out where provisioning stands.
Databases and queues from the same portal
With Managed Applications, databases such as PostgreSQL, MySQL, MongoDB and Redis, plus queue and analytics engines, install straight into your cluster from the same portal. The application and its database talk over the same network, with no separate database server to build and run.
Addresses that stay clear of your office network
Pod and service networks take their addresses from ranges outside the private blocks most corporate networks use. When you join your office to the cluster over VPN, an address clash never forces you to redraw your network plan.
Limit traffic between services by rule
Network policies let you decide which pod may talk to which service, so that only the order service can reach the payment service, for example. The rules are standard Kubernetes objects, versioned together with your application manifests.
Each team sees only its own space
Namespaces and role-based access control (RBAC) give each team the right to see and change only its own applications. A developer's access to the test environment never turns into the right to touch a production service.
GPU nodes for AI workloads
A GPU worker pool can be added to the cluster for work such as model inference and image processing. Pods that ask for a GPU land only in that pool, while the rest of your services keep running on standard nodes without wasting GPU capacity.
One wrong delete does not mean a rebuild
Your namespaces and persistent volumes are backed up every day to S3-compatible object storage, and a single namespace or volume can be restored when needed. A deployment deleted by mistake or corrupted data comes back without rebuilding the cluster.
Keep an eye on cluster health
Node CPU, memory and disk usage, along with pod restarts, are tracked in the Monitoring and Alerts product, and you get an alert when a threshold is crossed. Decide when to add capacity from measured usage rather than guesswork.
Why Nesnet
Your data stays in Türkiye
Your clusters, persistent volumes and images sit on Nesnet infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. You can state plainly in your own contracts which country holds the data.
One team builds the cluster and everything under it
The cloud portal, virtual network, load balancer, registry and cluster are all built by the same Nesnet team's automation, with no intermediary vendor. A problem in the network or storage is Nesnet's responsibility too.
Nesnet runs its own products on the same platform
Nesnet's own subscription software and www.nesnet.com run on the same Kubernetes infrastructure customers receive. Your cluster comes out of the same automation, so you ride the road Nesnet trusts with its own business.
Standard Kubernetes, no lock-in
The cluster is standard, upstream-compatible Kubernetes, with no Nesnet-specific resource types or tools to depend on. Your manifests and Helm charts behave here exactly as they do elsewhere, and they leave with you if you go.
Its own IP space, two upstream carriers
The public addresses your services use come from Nesnet's own IP space, and Nesnet reaches the internet through two separate upstream carriers. Your service address is never borrowed from another provider's pool or tied to a single line.
One monthly e-Invoice
Cluster, worker node and load balancer lines arrive on one monthly invoice, as an e-Invoice. Paying abroad by card drops off your finance team's list.
Example scenarios
Containers on virtual servers move into one cluster
Situation
A software team runs its services as containers on a few virtual servers. Every release is manual, a failed server takes its services down with it, and traffic is moved to another server by hand.
Outcome
The team takes a cluster with three control-plane nodes and three M-size workers; services spread across nodes and a failed replica comes back on another node by itself. Exposed services are published through a LoadBalancer or Ingress, and images are scanned in the private registry.
Development and production on separate clusters
Situation
A subscription software company worries that experiments in development will spill into production. Separating them by namespace in one cluster is not enough for resource use or access control.
Outcome
Two clusters are opened, with S-size workers for development and L-size workers for production, each with its own load balancer. Through the CI/CD Pipeline a push goes to development and an approved release to production, where the database runs redundantly through Managed Applications.
Only the order service grows in sale week
Situation
An e-commerce team's order service receives several times its normal traffic during sale week. Reporting and admin services on the same servers want resources at the same time.
Outcome
Before the sale, nodes are added to the worker pool and the order service's replica count goes up while every other service stays as it is. When the week ends the pool shrinks back, and the added nodes show up on their own invoice lines.
A software product moves home to Türkiye
Situation
A software company's product runs on Kubernetes in a cloud abroad. A new enterprise customer makes data residency in Türkiye a condition of the contract.
Outcome
A Nesnet cluster comes up from the same manifests and Helm charts, and the test environment moves first to be tried. On cut-over day the DNS record points at the new load balancer, and the old environment stays available for a while as a way back.
Installs stalled by public registry limits
Situation
A team's new environments keep stalling on a public registry's pull limits. The same images are downloaded from outside again for every environment.
Outcome
Cluster components come from Nesnet's registry, and the public images the team relies on are pulled through its cache. An outside registry's limit or outage no longer blocks a new environment.
Who does what
| Nesnet | You |
|---|---|
| Builds the cluster together with its network, edge gateway, egress IP, load balancer and public IPs. | You manage your application manifests, Helm charts and deployments. |
| Runs the cloud portal, virtual network, storage and physical servers underneath and applies platform patches on a regular cycle. | You define namespaces, access control (RBAC), network policies and application secrets. |
| Provides the private registry, vulnerability scanning and the cache for public registries. | You set resource limits and health checks (readiness, liveness) for your pods. |
| Keeps the management layer in an environment separate from customer workloads. | You decide how many workers you need and which node size. |
| Offers new Kubernetes versions as an upgrade option in the portal. | You choose when to upgrade and verify your application on the new version. |
Who it is for
Software teams that know Kubernetes
Teams who know Kubernetes but would rather not spend time building the network, storage and load balancing underneath it. Those layers arrive in the same run as the cluster, so day one is about deploying.
Teams that keep environments apart
Teams that want development, test and production on separate clusters. Each cluster comes with its own load balancer and public IPs, so an experiment in one never spills into another.
Subscription software companies
Software companies that want Kubernetes, a private registry, a delivery pipeline and object storage from one provider, on one network. They can tell their own customers in writing that data stays in Türkiye.
Developers without a Kubernetes team
Developer teams with no time to learn cluster operations. Combined with the CI/CD Pipeline, a push lands in test and an approved release ships to production.
Teams moving from VMs to containers
Teams that run their services across a few virtual servers and release by hand. On Kubernetes the same images spread across nodes, failed replicas restart on their own and scaling is one command.
May not be the right fit
Teams publishing a single web app, API or static site who have no wish to see a cluster. Nesly Serverless Platform suits them better: you push code and never deal with nodes or a kubeconfig.
Traditional applications that run on one server and have no containers to move. Virtual Servers suit them better: the application moves to a virtual machine as it is today.
Under the hood
Clusters are built by the cloud portal's Kubernetes extension through Kubernetes' own cluster lifecycle standard, Cluster API, and nodes boot from the images of an enterprise-supported Kubernetes distribution. The API endpoint sits on a fixed virtual IP, and pod networking comes from a standard CNI plug-in. Services of type LoadBalancer are published as virtual services on the platform's load-balancing layer, and persistent volumes are provisioned from distributed NVMe storage by the CSI driver. Component images come from Nesnet's own image registry. On top of these layers Nesnet adds its own automation: the organisation, edge gateway, egress IP, network, load balancer and cluster are created in a single run, and the registry is ready the moment the cluster is.
Building blocks
- Cloud portal and API
- tenant portal and the resource allocation your cluster runs in
- Kubernetes lifecycle extension
- create, scale, upgrade and delete clusters from the portal (Cluster API)
- Enterprise Kubernetes distribution
- compatible Kubernetes versions and node images
- Load-balancing layer
- virtual services behind LoadBalancer services
- Pod network (CNI)
- pod-to-pod networking and network policies
- Fixed API address
- a single virtual IP for the control-plane API
- Image registry and scanning
- a registry of your own, vulnerability scanning, cache for public registries
- Distributed NVMe storage
- where persistent volumes live
How it compares
| Option | When it is the right choice |
|---|---|
| Installing Kubernetes on your own virtual servers | The right call if you want to pick every component's version and setting yourself and you have an experienced team to keep the cluster healthy. Nesnet Virtual Servers can be the base; network, load balancer and storage integration remain your job. |
| Nesly Serverless Platform | Less work if you are shipping a web app, API or static site and do not want to run a cluster. Builds, addresses and HTTPS are handled by the platform. |
| Kubernetes from a large cloud provider abroad | If your users are spread across continents and you have no requirement to keep data in Türkiye, a provider that can place clusters in many regions may suit you better. |
Technical specifications
| Kubernetes | Standard, upstream-compatible |
|---|---|
| Default Kubernetes version | 1.33.1 |
| Provisioning | From the portal, with a declarative cluster lifecycle |
| Worker updates | Nodes are replaced, never patched in place |
| Control-plane nodes (production default) | 3 |
|---|---|
| Worker nodes (production default) | 3 |
| Control-plane API address | Fixed virtual IP |
| S | 2 vCPU · 4 GB RAM · 50 GB disk |
|---|---|
| M | 4 vCPU · 8 GB RAM · 100 GB disk |
| L | 8 vCPU · 16 GB RAM · 200 GB disk |
| Pod / service ranges | 100.96.0.0/11 / 100.64.0.0/13 |
|---|---|
| LoadBalancer service | Virtual service on the load balancer |
| Service public IP | From Nesnet address space, allocated as /32 |
| Load balancer | One per cluster, added automatically |
| Default StorageClass | ext4, CSI, disk deleted with the claim (Delete) |
|---|---|
| Chosen at cluster creation | Reclaim Delete or Retain; file system ext4 or xfs |
| Storage layer | All-NVMe |
| Version upgrade | From the portal, when a newer version is available |
|---|---|
| Worker pools | Several; each with its own count, disk and policies |
| Cluster sizing | By resizing the pools |
| Ingress | TCP / HTTP / HTTPS routing |
| Measured provisioning time | About 22 minutes (network, load balancer and IP included; measured with 1 control-plane + 1 worker) |
|---|---|
| Data centres | Equinix Istanbul (Dudullu), Türk Telekom Ankara; data stays in Türkiye |
If something breaks
If a control-plane node goes down
When one of the three control-plane nodes is lost, the remaining two keep quorum for the cluster's state store and the Kubernetes API stays up. The virtual IP moves to a healthy node, so the kubeconfig address does not change.
If a worker node breaks
A broken worker is not repaired in place. A new node VM is brought up and the old one removed, and pods are rescheduled onto healthy nodes.
If a pod moves to another node
Persistent volumes live in cloud storage, not on the node. When a pod lands on a new node, the CSI driver attaches its volume there and the data stays where it was.
If a physical server fails
Nodes run as virtual machines on the Nesnet cloud, where platform high availability is enabled. If a physical host fails, those VMs are restarted on other hosts in the platform, and a VM whose guest OS stops responding is restarted.
Frequently asked questions
Pricing and first steps
Pricing
Managed Kubernetes is billed monthly for the resources you use. The bill consists of a cluster unit plus worker node units in S, M or L size, with node vCPU, memory and disk counted on the same lines as virtual server resources. Each cluster includes one load balancer, and Nesnet’s team prepares your quote from these items.
What the price depends on
- Number and size of worker nodes (S, M, L)
- Number of clusters, for example separate clusters for development and production
- The load balancer added to each cluster
- vCPU, RAM and disk consumed on your workers by the databases and queues you install
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.Cluster count and node size are settled in one call, and the quote is built from those lines.
- 3.Once the order is approved the cluster is built and you download your kubeconfig from the portal.
Let Nesnet build the cluster while your team builds the product
Tell Nesnet's team how many clusters and which node size you need, and you will hear back within the same business day. Networking, load balancing, storage and the registry come with the cluster, and your data stays in Türkiye.