In short: K3s is a CNCF-certified Kubernetes distribution optimized for constrained environments (edge, IoT, labs). K8s refers to the original Kubernetes project, designed for large-scale production clusters. The choice depends on your available resources, deployment context, and operational workload.

K8s: Standard Kubernetes for Enterprise Environments

K8s is the abbreviation of Kubernetes, with the “8” representing the eight letters between the “K” and the “s”. It is the original open-source project maintained by the Cloud Native Computing Foundation (CNCF) and initially developed by Google.

Kubernetes is designed for large-scale production environments: multi-node clusters, high availability, integration with public clouds (AWS, GCP, Azure), or on-premises datacenters. Its control plane includes several separate components: API server, scheduler, controller manager, etcd, deployed independently, which provides maximum flexibility but requires significant operational expertise.

Typical requirements for a production control plane node: at least 2 vCPUs and 2 GB of RAM for Kubernetes components alone, excluding etcd and application workloads.

K3s: A CNCF-Certified Kubernetes Distribution, Not a Fork

K3s is a certified Kubernetes distribution, not an unofficial lightweight version or a fork. Created by Rancher Labs, it was donated to the CNCF in June 2020 and passes the same Sonobuoy conformance tests as all certified distributions. Any valid Kubernetes manifest works on K3s.

Its main goal is to drastically reduce the resources required to run Kubernetes in constrained environments (edge, IoT, CI/CD, labs) without giving up API compatibility.

What K3s Changes Compared to K8s

• A single binary under 70 MB (supporting x86, ARM64, ARMv7, and S390X), including the containerd runtime, Flannel CNI, a Traefik ingress controller, and a Klipper load balancer.
• SQLite as the default datastore in single-node mode instead of etcd. In high-availability configurations (minimum three server nodes), K3s can use embedded etcd or an external datastore (MySQL, PostgreSQL, external etcd).
• Alpha and beta components removed to reduce the attack surface and memory footprint.

Important point: K3s does not remove etcd; it makes it optional. In single-node mode, SQLite is sufficient. In high availability, embedded or external etcd is supported - although the latter is not officially supported by the K3s team.

Resource Footprint

K3s can run with as little as 512 MB of RAM on an agent node. According to the official documentation (updated May 2026), a server node (control plane) requires 2 GB of RAM and 2 CPU cores, excluding application workloads. A load-tested profile is available in the K3s resource profiling guide. It is worth noting that tests on hardware with 1 GB of total RAM showed instability across K3s, k0s, and MicroK8s when deploying real application workloads (even a lightweight Kubernetes cluster still consumes non-negligible control-plane resources).

Key Technical Differences

Datastore

Runtime and packaging

K8s no longer provides a default runtime since the removal of dockershim (v1.24, 2022). Starting with Kubernetes 1.24, you must install a CRI-compatible runtime (containerd or CRI-O). K3s embeds containerd directly into its binary.

Control Plane Architecture

In K8s, control plane components (API server, scheduler, controller manager) are separate processes. In K3s, they are merged into a single binary, which reduces overhead but limits some advanced isolation configurations.

Scalability

K3s is suitable for moderately sized clusters. In high-availability configurations (3 server nodes, 4 vCPU / 8 GB RAM), the official documentation indicates a capacity of around 1,200 agents. For very large clusters (several thousand nodes), K8s remains the reference.

K3s vs K8s Comparison Table

Use Cases: Which One Should You Choose?

Choose K3s if:

• You deploy on constrained hardware (Raspberry Pi, industrial appliances, edge servers with limited RAM).
• You manage remote IoT or edge clusters, potentially in disconnected environments.
• You need a development or CI cluster that starts quickly, including on modest hardware.
• You want an operational cluster with minimal initial configuration.

Choose K8s (or an enterprise distribution) if:

• You orchestrate hundreds or thousands of production nodes.
• Your workloads require advanced cloud-native integrations (storage, load balancers, IAM) provided by hyperscalers.
• You need alpha or beta API components unavailable in K3s.
• Your organization has a dedicated SRE team operating clusters.

Hybrid Use Cases: K3s and K8s Together

K3s and K8s are not mutually exclusive. Several hybrid architectures are documented in production:

Fleet Management with Rancher

Edge K3s clusters are managed from a central control plane running on K8s or RKE2. The Home Depot (large American retailer with more than 2,300 stores) manages its sites using K3s supervised through Rancher.

K3s for Dev and Staging, K8s for Production

API compatibility guarantees that manifests and Helm charts tested on K3s work in production on an enterprise cluster. This parity reduces surprises when promoting environments.

CI/CD

Test pipelines run on K3s (low cost, fast startup) while production environments use managed K8s clusters.

Managed Kubernetes: A Third Path

Neither K3s nor K8s solves the question of daily operations: updates, certificates, control plane monitoring, or failure management. This is precisely what managed Kubernetes solutions cover.

Hyperscalers (EKS, GKE, AKS) provide this management within their own clouds. But managed solutions also exist outside these ecosystems, especially for organizations that want to retain control over their data and choose sovereign Kubernetes, or even French-operated Kubernetes.

Clever Kubernetes Engine (CKE) is Clever Cloud’s managed Kubernetes service, designed for teams already using Kubernetes and wanting to delegate control plane management (updates, high availability, monitoring) without being constrained to a single hyperscaler. CKE explicitly targets teams that are not fully covered by the traditional  PaaS model (multi-runtime use cases, non-twelve-factor workloads, or the need for granular resource control).

FAQ

Is K3s a Kubernetes fork?

No. K3s is a CNCF-certified Kubernetes distribution. It passes Sonobuoy conformance tests and supports the same APIs as K8s. It is not maintained separately from Kubernetes: it follows upstream Kubernetes releases.

Can K3s Be Used in Production?

Yes, with some nuances. K3s is documented for production workloads in constrained environments (edge, IoT). For large-scale clusters or critical workloads with high SLA requirements, K8s (or an enterprise distribution such as RKE2) is more appropriate.

Does K3s Support Helm?

Yes. K3s includes an integrated Helm controller and is compatible with any valid Helm chart.

What Is the Difference Between K3s and K3d?

K3d is a tool that runs K3s inside Docker containers. It further simplifies the creation of local K3s clusters for development, but it is not intended for production use.

Does K3s Run on ARM?

Yes. ARM64 and ARMv7 are natively supported, which explains its popularity on Raspberry Pi devices and industrial appliances.

Managed Kubernetes vs Self-Hosted K3s: Which One Should You Choose?

Self-hosted K3s gives you full control but makes you responsible for operations (updates, security, high availability). Managed Kubernetes delegates this responsibility to an operator, at the cost of dependency on that provider. The choice depends on your operational resources and control requirements.

The Kubernetes vs Docker question deserves a precise answer, because the two technologies do not solve the same problem.

Docker is mainly used to build and run containers. Kubernetes is used to orchestrate those containers once the infrastructure becomes more complex. The two technologies are therefore often complementary, even though they are frequently- and incorrectly - presented as opposites.

Understanding this distinction helps clarify when Docker alone is enough, when Kubernetes becomes relevant, and why not every application actually needs a Kubernetes cluster.

Docker : Standardizing Application Execution

Docker popularized modern containerization. Its goal is simple: make applications run the same way regardless of the environment in which they are executed.

Before Docker, it was common for an application to work perfectly on a developer’s machine but fail once deployed to a server. Differences in system versions, missing dependencies, or inconsistent configurations made deployments significantly more difficult.

Docker largely solved this problem by packaging an application and its dependencies into an isolated container. In practice, the container includes the application itself, its libraries, dependencies, and some system components required for execution.

The environment becomes portable and reproducible. A Docker image can run on any compatible machine with predictable behavior. This standardization explains Docker’s massive adoption across CI/CD pipelines, development environments, and modern architectures.

Docker Is Not Just About “Running Containers”

In many teams, Docker has become an everyday tool. A developer can locally run a Node.js API, a PostgreSQL database, Redis, or an Nginx service without manually installing each component on their machine. Everything runs inside isolated containers.

This approach greatly simplifies local development, testing, demo environments, continuous integration, and application deployments.

For relatively simple applications, Docker alone may be sufficient. This is especially true when a team manages only a few services, operates a limited infrastructure, has low scalability requirements, or needs little operational automation. In such situations, adding Kubernetes may actually introduce unnecessary complexity.

Where Docker Reaches Its Limits

Docker works extremely well for running containers. However, it does not automatically solve large-scale orchestration challenges.

As the number of services grows, several questions quickly emerge:

• How do you distribute containers across multiple servers?
• How do you automatically restart a failed service?
• How do you perform updates without downtime?
• How do you automatically absorb traffic spikes?
• How do you monitor dozens or hundreds of distributed workloads?

Docker was not designed to handle this level of operational complexity on its own. That is precisely the role of container orchestration, where Kubernetes has become the most widely adopted standard.

Kubernetes: Automating Container Operations

Kubernetes is a container orchestrator. Its goal is not to replace Docker for image creation or containerization logic. Kubernetes operates at a higher level: infrastructure automation and operations management.

It can automatically deploy applications, distribute workloads across multiple machines, restart failed containers, manage high availability, perform auto-scaling, and orchestrate distributed architectures.

In other words, Docker runs containers. Kubernetes organizes their global behavior. That distinction is essential.

A Practical Example: Docker Alone vs Kubernetes

Consider a modern e-commerce platform. Initially, the application may remain relatively simple: a backend, a frontend, and a database. Docker is often enough to run this stack.

But over time, the architecture evolves: multiple microservices appear, some components need to scale independently, message queues are introduced, several environments must remain synchronized, availability becomes critical.

At that point, manually managing every container quickly becomes difficult. Kubernetes introduces automation mechanisms such as automatic workload recovery, load distribution, service replication, rolling deployments, and automatic reconciliation of the desired cluster state.

This is why Kubernetes has become the de facto standard for cloud-native orchestration.

Kubernetes vs Docker: Does One Replace the Other?

This is one of the most common questions, and the answer is clear: Kubernetes does not replace Docker.

For many years, Kubernetes used Docker as its container runtime. That is no longer the default behavior. Starting with version 1.20 (December 2020), Kubernetes deprecated direct Docker support through the “dockershim” component. This support was fully removed in Kubernetes 1.24, released in May 2022.

Since then, Kubernetes has relied on CRI-compatible runtimes (Container Runtime Interface) such as containerd or CRI-O.

This change has little impact on developers in day-to-day workflows. Docker-built images comply with the OCI (Open Container Initiative) standard and remain fully compatible with Kubernetes. The image format itself did not change: only the runtime layer inside Kubernetes clusters evolved.

In practice, Docker and Kubernetes still work together in many environments. Docker is used to build and test images locally. Kubernetes deploys and orchestrates them in production.

The confusion often comes from the fact that Docker historically existed at both stages. That is no longer true on the Kubernetes runtime side, but Docker remains heavily used for builds and development.

The Kubernetes vs Docker distinction is therefore not about replacement, but about roles: each technology operates at a different stage of the containerized application lifecycle.

When to Use Docker Without Kubernetes

Docker alone remains highly relevant in many situations. It is often the right choice for simple projects, internal applications, development environments, prototypes, small web platforms, or infrastructures with limited operational requirements.

In these scenarios, Kubernetes may represent significant operational overhead compared to the actual needs. In some cases, a lightweight distribution such as K3S may also be more appropriate than a full Kubernetes cluster.

Kubernetes is not automatically the best answer for every application, a position explicitly acknowledged at  Clever Cloud, including in the context of the launch of  Clever Kubernetes Engine (CKE), a managed Kubernetes platform developed and operated by Clever Cloud.

When Kubernetes Actually Becomes Useful

Kubernetes becomes valuable when an architecture requires advanced orchestration capabilities. This is especially true when multiple services must be coordinated, when deployments become frequent, when resilience becomes critical, when workloads fluctuate significantly, when teams already use GitOps practices, or when infrastructure becomes distributed or hybrid.

Some organizations also use Kubernetes to standardize deployments across multiple environments or cloud providers. In this context, choosing a managed Kubernetes platform often becomes central to reducing operational burden.

This is precisely the type of use case behind solutions such as CKE, designed to remain compatible with standard Kubernetes ecosystem tools while integrating with the broader Clever Cloud platform. 

Kubernetes or PaaS: It Is Not Always a Duel

Another common misconception is that Kubernetes necessarily replaces a PaaS (Platform as a Service). In practice, many applications run perfectly well on a traditional PaaS with less operational overhead and less complexity.

Even within the context of CKE, the positioning is explicit: Kubernetes does not replace the PaaS. The two address different operational models, not different levels of complexity: the PaaS takes care of operations, Kubernetes gives you control over them. Both run serious production workloads. The goal is therefore not to move every application onto Kubernetes, but to use it when it provides real technical or operational value.

Docker vs Kubernetes: Key Differences to Remember

Docker and Kubernetes Are Not Competing Technologies

The Kubernetes vs Docker question is not really about choosing one over the other: each addresses a different need at a different stage of the application lifecycle.

Docker simplified the creation and execution of containerized applications. Kubernetes automated their operation at scale.

Not every application needs Kubernetes. In many cases, Docker alone is enough. And to fully delegate operations, a PaaS takes over, including for distributed architectures and high resilience requirements. Kubernetes, for its part, becomes relevant when you need explicit control over orchestration, integration with the CNCF ecosystem, or multi-cloud portability on open standards. It is a choice of operational model and team needs, not a level of application complexity.

The real challenge is therefore not choosing "Docker or Kubernetes," but recognizing the point at which your orchestration needs make Kubernetes genuinely worthwhile.

FAQ

Are Docker and Kubernetes competitors?

No. Docker and Kubernetes address different needs. Docker is mainly used to build and run containers, while Kubernetes orchestrates them at scale.

Does Kubernetes replace Docker?

No. Since Kubernetes version 1.24 (May 2022), Docker is no longer used as the cluster’s internal runtime. Kubernetes now relies on CRI-compatible runtimes such as containerd or CRI-O. However, Docker images, which comply with the OCI standard, remain fully compatible with Kubernetes.

Why Has Kubernetes Become a Standard?

Kubernetes became the dominant standard thanks to its declarative model, portability across environments, and the cloud-native ecosystem built around the CNCF, where it has been a graduated project since 2016. Its ecosystem includes tools such as Helm, Prometheus, and Argo CD.

What Is the Difference Between K3S and Standard Kubernetes?

K3S is a lightweight Kubernetes distribution designed for edge environments, IoT, development, or small clusters, with lower resource consumption than standard Kubernetes.

Is Managed Kubernetes Better?

In many organizations, yes. Managed Kubernetes reduces the operational burden associated with the control plane, updates, security, and cluster resilience. This is the approach taken by  Clever Kubernetes Engine (CKE).

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.