Container as a Service

CaaS (Container as a Service) is a service model in which you run your container-based applications on Kubernetes while DataKobi operates the control plane (API server, etcd, upgrades).

Get a Quote 0312 945 36 42

12 years of field experienceTR data centers24/7 on-site support

yük: –

Kubernetes is powerful but hard to operate: etcd backups, three minor version upgrades a year, CNI/CSI drivers, certificate rotation and CIS hardening demand constant effort. With DataKobi CaaS, this entire layer is our responsibility; your team simply deploys the application.

Clusters run in Ankara and Istanbul, with latency within Türkiye under 8 ms. When traffic rises, the Horizontal Pod Autoscaler and the cluster autoscaler grow resources automatically; when traffic drops at night, they scale back down to cut costs.

Key features

Managed control plane

Highly available API server, etcd and scheduler; upgrades without downtime.

Autoscaling

End-to-end elasticity from pod to node with HPA and the cluster autoscaler.

Built-in ingress and LB

NGINX ingress, cert-manager and an L4 load balancer come ready to use.

GitOps ready

ArgoCD/Flux integration; compatible with your registry and CI/CD chain.

What is the real cost difference between running Kubernetes yourself and CaaS?

The hidden line item of running your own cluster is engineer time: in CNCF surveys, organizations spend an average of 10+ engineer-hours a week on Kubernetes operations, and this multiplies during version upgrade periods. Add etcd disaster scenarios, security patches (for example IngressNightmare-like CVEs disclosed in 2025) and the on-call burden. With CaaS, a 99.99% control plane SLA is in the contract; upgrades are seamless and the version policy is kept current. Compared with the annual cost of a senior platform engineer in Türkiye, CaaS is typically 60%+ more economical for a mid-sized cluster.

Which workloads should move to Kubernetes, and which should not?

Good candidates: stateless APIs and web services, queue consumers, scheduled jobs and microservice architectures — these benefit directly from autoscaling and self-healing. Those needing care: monolithic applications should be containerized first, and software licensed per core (some Oracle/SAP components) should not be moved without a license analysis. Critical databases can technically run on Kubernetes, but for most customers we recommend a hybrid architecture that keeps the database in the managed Database Services layer — lower operational risk and a more mature backup discipline.

Technical Specifications

Kubernetes: Support for the 3 latest minor versions, CIS hardening
Storage: NVMe-based CSI, NFS/CephFS for RWX
Network: Calico or Cilium, NetworkPolicy support
Observability: Prometheus + Grafana + Loki stack
SLA: Control plane 99.99%, node pool 99.9%

Frequently Asked Questions

What is the difference between CaaS and my own Kubernetes cluster?

With your own cluster, control plane maintenance, version upgrades and security patches are your responsibility. With CaaS, this entire operational load shifts to DataKobi, and your team focuses on the application.

Will my existing Docker images work?

Yes. All OCI-compliant images are supported; you can connect your private registry or use DataKobi's registry service hosted in Türkiye.

Can I run stateful applications (databases, etc.)?

Yes. Our NVMe-backed CSI driver can take instant snapshots of PVCs. Even so, for critical databases we recommend a hybrid architecture with managed Database Services.

Does it work multi-zone?

Clusters can span the Ankara and Istanbul data centers; if a zone is lost, workloads are moved automatically to the healthy zone.

A 30-minute discovery call with your architect

We will listen to your needs and outline the right architecture and a clear pricing framework in the same call. The first consultation is free.

Book a Call