Managed Kubernetes, control plane on us
We operate the control plane. You define worker pools at any size and scale them up and down as you need. Publish your applications over :80/:443 with eBPF networking and the Gateway API.
Control plane is freeTransparent worker pricing
The control plane is free on a single node; the 2 control nodes added for high availability ($12.00/mo) and the worker nodes are billed with hourly metering. You define worker pools at any size.
What a production cluster needs
Full kube-proxy replacement + Gateway API; no nginx-ingress.
Gateway API on :80/:443, load balancer in front — a single IP.
Scale the worker pool instantly from the panel; or turn on autoscaling and let the pool adjust itself between min and max based on pod demand.
3 control nodes + failover; the cluster keeps running if one node fails.
Download the kubeconfig and connect to the cluster directly with kubectl.
Security groups are set up automatically for the nodes; the API is certificate-protected.
Frequently asked questions about Kubernetes
A single control node is free. If you choose high availability (HA), the 2 added control nodes are billed. Worker nodes and persistent disks are charged with hourly metering; the load balancer is free.
High-performance eBPF-based networking — it fully replaces kube-proxy and comes with the Gateway API. You publish your applications over :80/:443 with HTTPRoute.
Yes, you create the cluster with 1.33, 1.34 or 1.35. Managed version upgrades are on our roadmap.
Currently the tr-ist-1 (Istanbul) region. Additional regions are on the roadmap.
You can create the cluster with 1.33, 1.34 or 1.35. Versions are pinned to validated builds; new versions are added as they are tested.
The load balancer for application ingress is free. Persistent disks (PersistentVolume) are billed separately as block storage; they are not included in the worker node fee.
Over :80/:443 with the Gateway API (GatewayClass cilium + HTTPRoute). In an HA cluster the load balancer distributes traffic across all nodes; you get a single ingress IP.
What do teams using Kubernetes say?
Managed Kubernetes (Managed K8s) Guide
Container-based architectures have become the standard for modern software development; yet running containers in production at scale, resiliently and automatically is a discipline in its own right. Kubernetes (K8s) does exactly that — but building a cluster from scratch, keeping the control plane highly available, backing up etcd, running version operations without interruption and designing the network layer correctly steals valuable time from application development, which is most teams’ actual job. Managed Kubernetes hands this operational burden to the provider: the control plane is managed, and you focus only on your applications and worker nodes. In this guide we examine end to end what Kubernetes is, the difference between managed and self-managed models, modern architectural choices such as eBPF-based networking and the Gateway API, high-availability and scaling capabilities, and how Tres differentiates this service.
What Is Kubernetes (K8s)?
Kubernetes (K8s for short) is an open-source container orchestration platform that automates the deployment, scaling, networking and lifecycle of containerized applications. Originally developed by Google, it is maintained today under the CNCF (Cloud Native Computing Foundation). Kubernetes decides which container runs where, restarts failed containers on its own (self-healing), scales with traffic and delivers zero-downtime deployment.
What Is Managed Kubernetes (Managed K8s)?
Managed Kubernetes is the model in which the control plane — the brain of the cluster — is operated by the cloud provider. The installation, maintenance, security patches and high availability of critical components such as the API server, scheduler, controller manager and etcd rest with the provider. Users manage only the worker nodes and workloads that run their applications. Amazon EKS, Google GKE and Azure AKS are well-known examples of this model; Tres delivers the same experience on domestic, KVKK-compliant infrastructure and with a free control plane.
How Does Kubernetes Work? The Control Plane and Worker Nodes
A Kubernetes cluster consists of two main layers. The control plane is the brain that makes the cluster’s decisions: the API server (the entry point for all commands), the scheduler (places pods on nodes), the controller manager (maintains the desired state) and etcd (the distributed database that holds the cluster’s state) all run here. The worker nodes are the servers where your application containers (pods) actually run; each node has a kubelet (the node agent) and a container runtime. In the managed model the control plane belongs to the provider and the worker nodes to you; you deploy your application with kubectl or CI/CD, and Kubernetes handles the rest.
The Difference Between Managed Kubernetes and Self-Managed
The answer to whether you should use managed Kubernetes or set it up yourself depends on your team’s level of expertise and operational capacity. A self-managed cluster gives you full control, but the 24/7 health, backup and upgrading of the control plane are entirely your responsibility.
| Criterion | Managed Kubernetes | Self-Managed |
|---|---|---|
| Control plane | Managed by the provider | The team sets it up and maintains it |
| Setup time | Minutes | Days–weeks |
| etcd backup | The provider’s responsibility | The team must set it up and monitor it |
| Version upgrades | Managed by the provider | Manual, with downtime risk |
| High availability | Ready-made HA control plane | The team must set it up |
| Expertise (K8s) required | Low–medium | High |
| Focus | Application development | Cluster operations |
Tip: The most underestimated cost of Kubernetes is the operational burden of the control plane. A cluster whose etcd backup has been forgotten, an API server that crashes during a version operation, or a control node that fails in the middle of the night are the scenarios teams fear most. Managed Kubernetes removes this risk — and at Tres a single control node is free.
Tres Managed Kubernetes Features
A single control node is free; you pay only for the worker nodes and resources you run. The 2 control nodes added for high availability (HA) are billed. Compared to models that charge per control plane, this makes a significant cost difference for teams running multiple clusters.
Instead of the classic iptables-based kube-proxy, eBPF-based networking is used. Running at the kernel level, eBPF handles service routing and network policies with lower latency and higher scale — a full kube-proxy replacement. This eliminates the performance bottleneck that traditional kube-proxy creates on large clusters, and NetworkPolicy is enforced more efficiently.
For traffic management, the modern Gateway API is used instead of the older nginx-ingress. Your applications are published over :80/:443 from a single IP with a load balancer in front. The Gateway API is the next-generation standard the Kubernetes community has defined for ingress; it offers role separation, richer routing rules and cleaner configuration.
With an optional 3 control nodes + failover, you can make the control plane highly available: even if one node fails, the cluster keeps running. For production workloads, the single point of failure created by a single control node is thereby eliminated.
You can grow or shrink the worker pool from the panel at any time; or enable autoscaling to have the pool adjust itself between min–max according to pod demand. It matches resources to demand under variable traffic, and you do not pay for idle capacity.
When the cluster is ready, you download the kubeconfig from the panel and connect directly to the cluster with kubectl. You deploy your applications with manifests (YAML), Helm or CI/CD pipelines.
Tip: The choice of eBPF and the Gateway API is not just about being modern. The classic kube-proxy + nginx-ingress stack creates performance and management complexity as clusters grow. eBPF provides faster routing at the kernel level, while the Gateway API provides more sustainable traffic management — together they prevent scaling problems in production clusters from the outset.
What Is Kubernetes Used For? Use Cases
- Microservice architectures: Deploying, networking and scaling large numbers of independent services.
- Teams deploying frequently with CI/CD: Safe releases many times a day with GitOps and automated deployment pipelines.
- Applications with variable traffic: Flexible capacity by growing the worker pool when traffic rises and shrinking it when it falls.
- Multi-environment management: Isolated and consistent management of dev / staging / prod environments.
- Cloud-native applications: Container-based, resilient and portable modern application infrastructure.
Who Should Use Managed Kubernetes?
Teams that run container-based applications but do not want to deal with control-plane operations — organizations moving to microservices, software teams with a CI/CD culture, SaaS and e-commerce platforms with variable load, and DevOps teams that need to manage multiple environments consistently — benefit the most from managed Kubernetes.
Kubernetes Network Architecture: Why eBPF and the Gateway API Matter
In Kubernetes, the network is the cluster’s most critical and most problem-prone layer. Two architectural choices set Tres apart from classic setups and, together with a load balancer, let you manage production traffic in a clean way.
| Topic | Classic Approach | Tres (Modern) |
|---|---|---|
| Service routing | kube-proxy (iptables) | eBPF (kube-proxy replacement) |
| Network performance | Bottleneck on large clusters | Kernel-level, low latency |
| Ingress | nginx-ingress | Gateway API |
| Traffic ingress | Separate ingress controller | :80/:443, load balancer in front, single IP |
| Network policy | Limited efficiency | Efficient NetworkPolicy with eBPF |
These choices prevent, from the outset, the performance and management problems that arise as your cluster grows; they form a sustainable foundation for teams that start small and scale up.
What Makes Tres Managed Kubernetes Different?
A single control node is free; you pay only for workers and resources. A cost advantage for those running multiple clusters.
A full kube-proxy replacement; a high-performance, low-latency service network.
The modern ingress standard; single IP, load balancer in front, clean traffic management.
Production assurance with an optional 3 control nodes + failover.
Instant scaling from the panel + autoscaling based on pod demand; no paying for idle capacity.
Kubernetes 1.33–1.35 support; pay-as-you-go in the KVKK-compliant Türkiye (Istanbul) location.
Frequently Asked Questions (FAQ)
What is Kubernetes (K8s)? +
Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, networking and lifecycle of containerized applications. Originally developed by Google, it is maintained today under the CNCF.
What does managed Kubernetes (Managed K8s) mean? +
It is the model in which the Kubernetes control plane (API server, scheduler, etcd, etc.) is operated by the cloud provider. Users manage only their worker nodes and applications; maintaining the control plane and its high availability rests with the provider.
Should I use managed Kubernetes or set it up myself? +
If you would rather not deal with the 24/7 health of the control plane, etcd backups and version operations, managed Kubernetes is more efficient. A self-managed cluster gives you full control but demands deep K8s expertise and operational capacity.
What is the control plane? +
It is the brain that makes the Kubernetes cluster’s decisions: it consists of the API server, scheduler, controller manager and etcd. It decides where pods are placed and keeps the cluster in its desired state.
Is the control plane really free? +
A single control node is free. If you choose high availability (HA), the 2 additional control nodes are billed; worker nodes and resources are charged pay-as-you-go, and the load balancer is free. This provides a cost advantage especially for teams running multiple clusters.
What is eBPF-based networking and what advantages does it offer? +
eBPF is a technology that runs at the kernel level to handle service routing and network policies with high performance. At Tres it is used as a full kube-proxy replacement; it eliminates the performance bottleneck that the classic iptables-based kube-proxy causes on large clusters.
What is the Gateway API and how does it differ from nginx-ingress? +
The Gateway API is the next-generation standard the Kubernetes community has defined for ingress. Applications are published over :80/:443 from a single IP with a load balancer in front. Compared to nginx-ingress, it offers richer routing, role separation and cleaner configuration.
Can a Kubernetes cluster be highly available? +
Yes. With an optional 3 control nodes + failover, the control plane can be made highly available; even if one node fails, the cluster keeps running and the single point of failure is eliminated.
Can I scale the worker nodes? +
Yes. You can grow or shrink the worker pool from the panel at any time, or enable autoscaling to have the pool adjust itself between min–max according to pod demand. You do not pay for idle capacity.
Which Kubernetes versions are supported? +
Tres supports current Kubernetes versions (the 1.33–1.35 range). Versions are pinned to validated builds; new versions are added as they are tested.
Which workloads is Kubernetes suitable for? +
It is suitable for microservice architectures, teams that deploy frequently with CI/CD, applications with variable traffic, multi-environment (dev/staging/prod) management and, more generally, container-based cloud-native applications.
How is the cost of Kubernetes calculated? +
A single control node is free; cost is calculated on the worker nodes and resources you run, on a pay-as-you-go model. To avoid paying for idle capacity, you can scale the worker pool to match your needs.
Are my data and cluster located in Türkiye? +
Yes. Your cluster and data reside in the Türkiye (Istanbul) location, in compliance with KVKK and data-residency requirements.
Can I migrate my existing Kubernetes workloads? +
Because Kubernetes is a standard (conformant) platform, applications that run on standard K8s can be migrated to Tres. Your container images and manifests (YAML) run as-is.