CKE in public beta: managed, sovereign, and properly integrated Kubernetes

So we built our own orchestrator. It runs on micro-VMs and gives us a clean kernel boundary between workloads, with no shared kernel between tenants. That is what runs tens of thousands of applications in production on our PaaS today, and for most projects it is still the shortest path from a commit to production.

When Docker arrived, some workloads fit better as a container image than as one of our native runtimes. So we added a Docker runtime to the platform, where it made sense. Not to replace our approach, but to broaden it.

Then Kubernetes established itself as the de facto standard for container orchestration. Its ecosystem (Helm, operators, GitOps, and so on) became unavoidable for many teams.

We could have kept saying that, in many cases, Kubernetes is not the best path to production. That is still true. But it was no longer enough. That is why we are launching CKE, our Clever Kubernetes Engine, available in public beta starting today.

As many know, we resisted for years the idea of offering Kubernetes as just another checkbox in the Console. Not because Kubernetes is useless, but because it has too often become a default answer to problems the PaaS solves more simply: deploying an application, scaling it, monitoring it, isolating it, connecting it to a database, managing its environment variables, its logs and its lifecycle. And we still believe that.

But Kubernetes has become the common language of a large part of the cloud-native ecosystem. Helm, operators, GitOps, already-containerized workloads, internal platforms and existing toolchains are part of the daily reality of many teams. And our reason for being is to make life easier for technical teams.

The question was no longer “should we do Kubernetes?”, but “can we do Kubernetes without giving up what makes Clever Cloud?”

Not a quickly repackaged Kubernetes

The fastest way to ship managed Kubernetes is to wrap an upstream distribution behind an admin console, add a provisioning API, and bill the cluster by the hour. It is a valid strategy if you want to ship fast. It is not the one we wanted.

For CKE, we had three requirements that cannot be solved by simply bolting Kubernetes on top of the rest of the platform.

The first is sovereignty. CKE is operated in Europe, on our infrastructure and that of our partners, and can also be deployed on the on-premises infrastructure of customers who need it. No dependency on US hyperscalers, no grey areas around data jurisdiction, no vague promises about where the infrastructure actually runs.

The second is integration with the rest of Clever Cloud. We did not want to create a Kubernetes silo sitting alongside the PaaS, the managed databases, the object storage and the private network. We wanted a Kubernetes that fits inside the same platform, with the same Console, the same tooling, the same billing, the same governance rules and the same managed services.

The third is operational predictability. Kubernetes is a complex distributed system, and its behaviour under load depends heavily on its foundations. We did not want to operate a product whose underlying layer would remain a black box or a default-accepted limitation. That is what led us to work on something few providers touch: Kubernetes’ internal consistency layer.

Under the hood: Materia etcd on FoundationDB

In Kubernetes, etcd is the component that stores cluster state: manifests, resources, secrets, node state. It is the source of truth for the entire orchestrator.

It is also one of the most sensitive components in the system.

etcd works very well within the scope it was designed for. But its limits at scale are well known: store size, latencies under heavy write load, behaviour during network partitions, backup and restore operations, the need for compaction and fine-grained monitoring. When Kubernetes becomes a critical foundation, etcd becomes an operational concern in its own right.

We did not want to build CKE on top of a brick we would then treat as a fragile black box.

So we took the problem back to its root: keep the contract Kubernetes expects, but replace the internal consistency layer with an implementation backed by FoundationDB. We call it Materia etcd.

FoundationDB gives us distributed ACID transactions, a robust consistency model, and a deterministic simulation testing approach that fits very well with how we build critical infrastructure.

For end users, this work is invisible. That is precisely the point. Under the hood, this foundation lets us build CKE with the auto-scaling, auto-healing and operational predictability we expect from a Clever Cloud service.

We will come back to Materia etcd in more detail soon, because the topic deserves a dedicated article.

Standard Kubernetes on the developer side

All this work on the underlying layer has a simple goal: on the user side, CKE has to be standard Kubernetes.

Your manifests work without modification. Your Helm charts install normally. Your Argo CD or your Flux plugs in like on any other cluster. Your Kubernetes operators run without surprises.

CKE does not try to reinvent the developer interface of Kubernetes. That would be counterproductive. If you already have a Kubernetes deployment chain, the goal is for it to run on CKE with as little friction as possible.

The difference happens elsewhere: in how this Kubernetes integrates with the rest of the Clever Cloud platform.

Kubernetes when you need it, the PaaS when it is enough

CKE does not replace our PaaS. It complements it.

For many applications, the PaaS remains the best choice: less operations, less configuration, less YAML, less maintenance surface. If your application fits naturally in a Clever Cloud runtime, the PaaS is often still the simplest and most robust path.

But there are cases where Kubernetes is the right tool.

You may need to install :

• An operator;
• Reuse existing manifests;
• Standardize a GitOps chain;
• Deploy a workload already distributed as a Helm chart;
• Run an internal platform built around the Kubernetes API;
• Or simply meet the habits of a team that already works with Kubernetes day to day.

In those cases, the problem is not Kubernetes itself. The problem is Kubernetes isolated from the rest of your system.

That is where CKE changes things. You can keep a Node.js API on the PaaS, a static frontend on Cellar, a managed PostgreSQL database, and run on CKE only the component, the operator or the workload that really needs Kubernetes.

All within the same Clever Cloud environment.

Native integration with the Clever Cloud ecosystem

CKE was designed to integrate with the services you already use on Clever Cloud.

• Cellar, our S3-compatible object storage, can be used from your Kubernetes workloads.
• Managed databases (PostgreSQL, MySQL, MongoDB, Redis, Materia) attach to your cluster the same way they do to any other Clever Cloud application.
• IAM as a Service lets you manage authentication and permissions on the cluster and on the teams that access it.
• Network Groups lets you connect your CKE cluster to your existing Clever Cloud PaaS applications, in the same private network.

The Network Groups integration is probably the one that changes day-to-day work the most.

Kubernetes is often introduced into organizations as a new island: new console, new network, new secrets, new access rules, new billing, a new way to connect services together.

With CKE, the goal is the opposite. Kubernetes becomes one more brick in the Clever Cloud architecture, not a parallel world.

So you can build a hybrid architecture without workarounds: part on the PaaS, part on CKE, managed databases, object storage, private networking, and shared governance.

Enabling CKE and deploying a first application

For this demo, we will stick to the bare minimum: enable the feature, create a cluster, fetch a kubeconfig, add a node group, and deploy a first application with a LoadBalancer service.

On the prerequisites side, you will need Clever Tools version 4.3 or later, and kubectl installed locally.

Since the public beta opened on April 27, the Kubernetes feature can be enabled by any Clever Cloud customer, with a single command:

clever features enable k8s

You can then create a cluster. Give it a name, point to your organization, and the --watch option lets you follow the deployment progress:

clever k8s create my-cluster --org <your-org-id> --watch

Creation takes about a minute. At any time, you can list the clusters in your organization with clever k8s list.

Once the cluster is ready, fetch its kubeconfig and write it directly as your default local configuration:

clever k8s get-kubeconfig my-cluster --org <your-org-id> > ~/.kube/config

From there, it is standard Kubernetes. kubectl talks to the cluster, and your usual tooling follows. You can start by checking that everything is in place:

kubectl get nodes

At this stage, the list is empty: the cluster is created but has no compute capacity. This is a good moment to introduce the first CKE-specific API resource: the NodeGroup. A node group is a set of Kubernetes nodes with the same profile (same flavor, same region), managed as a unit. You describe it like any other Kubernetes resource, in a YAML file:

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: example-nodegroup
spec:
  flavor: M
  nodeCount: 2

And you apply it with kubectl:

kubectl create -f example-nodegroup.yaml

Sixty to ninety seconds later, the nodes join the cluster:

kubectl get nodegroups
NAME                DESIREDNODECOUNT   CURRENTNODECOUNT   FLAVOR   STATUS   AGE
example-nodegroup   2                  2                  M        Synced   2m

kubectl get nodes
NAME                      STATUS   ROLES    AGE   VERSION
example-nodegroup-node0   Ready       2m    v1.35.0
example-nodegroup-node1   Ready       2m    v1.35.0

To resize the node group, you stay within the Kubernetes API:

kubectl scale nodegroup example-nodegroup --replicas=4

With a cluster that now has compute capacity, you can deploy a first application. To keep things simple, an nginx exposed through a LoadBalancer service, which will automatically provision a load balancer on the Clever Cloud side:

kubectl create deployment nginx --image=nginx:alpine --replicas=2 
kubectl expose deployment/nginx --type=LoadBalancer --port 80 
kubectl get service nginx

A few seconds later, the service exposes a public address. This is exactly the responsive behaviour we mentioned about the private testing phase: provisioning a node group, scaling it or exposing a service requires no waiting and no manual configuration.

From here, it is Kubernetes like anywhere else. You can add persistent storage through the Clever Cloud CSI, install the Clever Kubernetes Operator to provision a managed database from your manifests, or plug in your usual GitOps chain. The cluster supports Kubernetes versions 1.34, 1.35 and 1.36, with 1.35 as the default. Everything is detailed in the CKE documentation.

What we saw during private testing and at Devoxx, and what is next

CKE is now in public beta, but some of our customers have had private access for several months. That phase was very useful to expose the product to real-world usage before opening it more widely.

The feedback has been very positive. The cluster behaves as expected, and the operations that come up most often in a Kubernetes team’s daily life, such as adding a node or setting up a load balancer, are fast and predictable. That is exactly the behaviour we were aiming for when we invested so much time into the internal consistency layer.

At Devoxx France, we presented CKE on the Clever Cloud booth for three days. The conversations confirmed two things we were already observing.

First, teams are not just looking for a Kubernetes cluster. They are looking for a Kubernetes that integrates cleanly with their platform, their network, their databases, their security constraints and their existing practices.

Second, and probably the most striking feedback, developers are not looking to put everything on Kubernetes. Many want to keep their classic applications on our PaaS, where it is the most efficient, and deploy on Kubernetes only the components that really warrant it, because of their complexity, their distributed architecture, or the constraints of the ecosystem they fit into.

This is exactly the kind of hybrid architecture CKE is designed to enable.

It is also why, ahead of the launch, we built the Clever Kubernetes Operator. It allows a workload running in a Kubernetes cluster, whether hosted with us or elsewhere, to provision and consume our managed services directly from the Kubernetes API: PostgreSQL, MySQL, MongoDB, Redis, Cellar or Materia.

For your teams, it is a kubectl apply that creates a managed database. For CKE, it is the natural tool to bridge Kubernetes workloads and the rest of the Clever Cloud platform.

The beta is open to all Clever Cloud customers. You can enable it right now, deploy your first workloads, and tell us what is missing, what surprises you or what you would like to see come next.

The discussion is open on our GitHub community, and the documentation is available here.

CKE does not replace our PaaS. It complements it.

For many applications, the PaaS remains the simplest path from a commit to production. But when you need Kubernetes, for an operator, a Helm chart, a GitOps chain, an already-standardized workload or an internal platform, you can now do it inside the Clever Cloud environment, with our infrastructure choices, our network, our managed services and our sovereignty requirements.

That is the kind of Kubernetes we wanted to build.