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).

How Kubernetes Works: a Declarative Orchestrator

Most descriptions of Kubernetes list its components (pods, deployments, services) without explaining the central mechanism. The fundamental concept lies elsewhere: Kubernetes is first and foremost an orchestrator, and its core engine relies on a reconciliation loop.

You don't tell Kubernetes what to do. You tell it what you want your system to look like. This distinction, declarative versus imperative, changes everything.

In practice, you describe the desired state in manifest files, typically in YAML format: "I want 3 replicas of this image, exposed on port 80, with these environment variables." You submit this manifest to the Kubernetes API via kubectl. From that point on, Kubernetes continuously compares the actual state of the cluster (what is actually running) to the desired state (what you declared), and acts to bring them into alignment. If a node dies, its pods are rescheduled elsewhere. If you change from 3 to 10 replicas in the manifest, Kubernetes starts 7 more. If a container crashes, it gets restarted.

This reconciliation loop is the heart of everything Kubernetes does: self-healing, scaling, rolling updates, and rollbacks. To dive deeper into this mechanism and the other capabilities it enables, learn more about container orchestration.

Architecture in Brief: Control Plane, Nodes, Pods

A Kubernetes cluster is divided into two parts. The control plane is the brain: it makes global decisions, accepts API requests, schedules workloads, and monitors the state of the cluster. It relies on a few key components, including the API server (kube-apiserver), the scheduler (kube-scheduler), and the controller manager (kube-controller-manager), along with a distributed data store that holds the entire cluster state, traditionally etcd.

Nodes are the machines that actually run the workloads. On each node, an agent called kubelet receives instructions from the control plane and launches containers through a container runtime (containerd, CRI-O, etc.). The smallest deployable unit is not an individual container but a pod: one or more containers that share a network and storage. Higher-level objects (Deployment, Service, Ingress, ConfigMap, Secret) describe how pods should be managed, exposed, and configured.

This architecture is also the source of a common confusion with Docker, whose role is actually complementary to Kubernetes rather than competitive.

Why K8S Became the Orchestration Standard

According to the CNCF Annual Cloud Native Survey 2025, published in January 2026, 98% of surveyed organizations have adopted cloud native techniques, and 82% of container users deploy Kubernetes in production, up from 66% in 2023. The dominance is massive. But explaining it solely through technical qualities would be incomplete; it is also a story of ecosystem dynamics and aligned interests.

On the technical side, three properties explain adoption. First, the declarative model described above: it makes deployments reproducible, versionable in Git, and resilient to failures. Second, portability: the same manifest works on a development machine (Minikube, kind, k3d), on an on-premise cluster, and on any cloud. Third, extensibility: the Kubernetes API accepts Custom Resource Definitions (CRDs) and custom controllers (Operators), turning it into a platform for building platforms. This triggered a massive ecosystem dynamic.

On the strategic side, the story is less often told. By 2014, Google had more than a decade of experience managing containers at scale with its internal systems Borg and Omega, whose design principles were shared publicly through academic research papers (Omega in 2013, Borg in 2015). Rather than open-sourcing Borg itself, which remained tightly coupled to Google's proprietary infrastructure, the team created Kubernetes as a new project inspired by that experience, with a distinct implementation designed from the outset for external adoption. The project was released as open source in June 2014 and donated to the Cloud Native Computing Foundation in 2015. This neutrality, a project hosted by a Linux foundation rather than a cloud provider, proved decisive. No competitor could afford not to adopt it without being marginalized from the emerging cloud-native ecosystem. AWS, which initially pushed its own proprietary solution (ECS), announced EKS in late 2017 and launched it in general availability in June 2018. By then, the standard was sealed.

On the ecosystem side, the network effect did the rest: Helm for packaging applications, Prometheus for monitoring, Istio and Linkerd for service mesh, ArgoCD and Flux for GitOps, Trivy and Falco for security. Each additional tool reinforces the value of the standard. On the talent side, Kubernetes skills have become massively in-demand across DevOps and SRE roles, creating a virtuous cycle: more trained engineers, more adopting companies, more engineers getting trained.

In the CNCF 2025 report, the community now describes Kubernetes as "boring," using the term as the highest praise: a mature, predictable tool whose APIs no longer break with every release. That is exactly what you want from infrastructure that has become standard.

When Kubernetes Adds Value, and When Other Approaches Are a Better Fit

The fact that K8S is the standard doesn't mean it's the right answer to every problem. Choosing Kubernetes, a PaaS, or a combination of both depends on the technical and organizational context; at Clever Cloud, many teams use both in parallel for different workloads.

Kubernetes delivers real value in several contexts:

• strong portability requirements: multi-cloud, hybrid, or on-premise combined with cloud, where the Kubernetes manifest becomes a common denominator;
• distributed architectures that apply 12-factor app principles and the "cattle" approach (interchangeable, stateless instances) with sophisticated orchestration needs;
• strategic alignment with the CNCF ecosystem (Helm, Operators, ArgoCD, Istio, etc.) or client/partner prerequisites that impose the standard;
• need for a shared platform across large teams, with a dedicated platform engineering team or the willingness to outsource that responsibility to a managed service.

Conversely, in other contexts, a PaaS like Clever Cloud delivers the same outcomes as Kubernetes (industrialized deployments, autoscaling, resilience) without the operational complexity of the orchestrator. This is particularly true for standard application architectures (web + backend + database) where the effort of configuring and operating Kubernetes doesn't translate into tangible added value.

And for intermediate workloads (IoT, edge, development environments, small clusters), the differences between K3S and K8S are worth weighing before deciding: the lightweight distribution is often a better fit. The de facto standard is not a moral obligation. It is a powerful and costly tool to operate, and its use should be chosen based on the problems it solves, often as a complement to other approaches rather than a replacement.

The Limits of the Standard: Operational Debt

Running Kubernetes in production is not trivial. That's one of the reasons why many companies that adopt K8S opt for a managed service rather than a self-managed installation.

The sources of complexity are numerous: configuring access control correctly (RBAC), choosing and operating a network plugin (CNI), wiring up persistent storage (CSI), setting up observability, managing certificates, performing minor and major upgrades without downtime, hardening security, managing control plane backups. Each of these topics is a discipline in itself. The CNCF 2025 report shows that challenges have actually shifted from purely technical to organizational: 47% of organizations now cite "cultural changes with the development team" as their top obstacle, ahead of raw technical complexity.

At the heart of this debt sits a less-discussed component: etcd. It is the distributed key-value database that stores the complete state of the cluster. etcd is solid for moderately sized clusters, but becomes a bottleneck at scale. It's no coincidence that Google announced in late 2024 the replacement of etcd with Spanner for its managed GKE offering, retaining only the API compatibility layer. AWS, for its part, has built a "new generation" etcd architecture to handle scale. K3S, designed for lightweight environments, has pushed the logic further by offering several alternatives to etcd, including SQLite as the default. When the central component needs to be re-engineered to handle production use at scale, it's a telling sign.

This realization is what led us, at Clever Cloud, to rethink this component. Our Clever Kubernetes Engine replaces standard etcd with Materia etcd, our reimplementation of the etcd protocol built on top of Materia KV and FoundationDB, replicated across three Paris datacenters. This approach is also part of what makes Clever Cloud unique: a multi-tenant control plane that scales horizontally without degrading performance, benefits from FoundationDB’s continuous failure simulation model, and frees teams from managing thousands of fragile etcd instances.

But whether you choose CKE or another service, the principle remains the same: if you want Kubernetes in production without building a dedicated platform engineering team, a managed Kubernetes is almost always the right decision.

In Summary

Kubernetes became the standard for good technical reasons, but also thanks to an alignment of interests that drove the industry to converge around a neutral project governed by the CNCF. The core mechanism, the reconciliation loop and the declarative model, explains its robustness. The ecosystem that has built up around it explains its staying power.

That doesn't mean it should be adopted for everything. For many contexts, a PaaS or another approach is a better fit, and in practice, the two often coexist within the same architecture, each where it delivers the most value. For serious distributed architectures, it remains the tool of reference, provided you account for the operational debt it introduces and choose between running it yourself or relying on a managed service.

This is precisely the promise that Clever Kubernetes Engine, our managed Kubernetes, seeks to deliver: standard Kubernetes, operated in France on sovereign infrastructure, with a control plane redesigned to eliminate the friction of etcd at scale. And for teams that don't need Kubernetes, our PaaS remains the most direct path to production.

FAQ

Are K8S and Kubernetes the same thing?

Yes. K8S is an abbreviation: the letter K, followed by 8 (representing the eight letters in "ubernete"), followed by S. Both refer to the same container orchestration system.

What is the difference between Docker and Kubernetes?

Docker is a containerization engine: it packages an application with its dependencies into an image that runs as a container. Kubernetes is an orchestrator: it deploys, monitors, and scales those containers across a fleet of servers. This is one of the most commonly misunderstood distinctions in the ecosystem, even though the two tools serve different and complementary purposes.

Is Kubernetes free?

The software is open source and free under the Apache 2.0 license. But the infrastructure it runs on, the engineering time to maintain it, and the complementary tools (monitoring, backups, security) have a real cost. That's why many companies opt for a managed Kubernetes offering.

Do you always need Kubernetes for production deployments?

No. Kubernetes provides sophisticated orchestration, particularly suited to distributed architectures requiring portability, CNCF ecosystem alignment, or advanced orchestration. For many other contexts, a PaaS delivers the same outcomes (industrialized deployment, autoscaling, resilience) without the operational complexity. And in practice, the two approaches often coexist within the same architecture.

What is the difference between K3S and K8S?

K3S is a CNCF-certified Kubernetes distribution (not a fork), designed to be lightweight and suited for resource-constrained environments: edge, IoT, development machines, small clusters. It replaces some components with lighter alternatives and ships as a single binary. The differences between K3S and K8S come down to several specific architectural choices worth evaluating before making a decision.

How do I get started with Kubernetes?

The fastest way is to spin up a local cluster with Minikube, kind, or k3d, then deploy a simple application via a YAML manifest. For production, the reasonable choice for most teams is a managed Kubernetes offering.

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.

Nantes, France — Clever Cloud, a European cloud provider, announces the public beta launch of Clever Kubernetes Engine (CKE) on April 27, 2026, in the afternoon. The product will be previewed at Devoxx starting April 22, where attendees will be able to test it directly at the Clever Cloud booth.

Built for production and scalability

Kubernetes has become the standard for container orchestration. Clever Cloud spent two years developing a managed, sovereign version designed to integrate naturally into the Clever Cloud ecosystem and operate with the same simplicity as the platform's other services. CKE is built to handle real production workloads, with high scalability and predictable behavior at scale.

To achieve this, Clever Cloud developed Materia etcd, a reimplementation of Kubernetes' internal consistency layer built on FoundationDB. This foundational work — invisible to the end user — is what guarantees CKE's robustness and stability in production, notably through native auto-scaling and auto-healing capabilities.

CKE integrates natively with existing Clever Cloud services — Cellar object storage (S3-compatible), managed databases, IAM as a Service, Network Groups — and remains accessible via standard industry tools: kubectl, Helm, or GitOps.

Sovereign by design

Hosted and operated in Europe by Clever Cloud on its public cloud, CKE offers organizations a concrete alternative to the Kubernetes offerings of major American platforms, without compromising on performance or legal data control. CKE can also be deployed on the customer's own on-premises infrastructure.

Access details

The public beta is open to all Clever Cloud customers from April 27, 2026, via feature activation performed by the user. Notably, some customers have already had access through a private test for over six months, allowing the product to be refined before this general release.

"Clever Cloud has long developed alternatives to Kubernetes. Our customers expressed a clear need for this technology, and we decided to build it alongside them, with the level of technical excellence and sovereignty that defines our platform." — Quentin Adam, CEO of Clever Cloud

Learn more

It was built to manage infrastructure — and in doing so, it carries complexity and then hidden costs. And at Clever Cloud, our guiding principle is to empower developers productivity, security, and autonomy.

Since then, the context has changed. The market is evolving, our clients too, and we now have the technological maturity to address such a need … in our own way. Here's why we took the time to create our own version of ETCD, and why Kubernetes is finally arriving at Clever Cloud.

Why we didn’t jump on Kubernetes earlier

In the past, we never saw Kubernetes as a key driver for simplification. It’s sometimes experienced as an additional layer of complexity, especially for teams who just want to deploy, scale, and secure their applications: focus on value creation without spending too much time on the rest. 

But scaling up often creates complicated machinery. As a cloud provider, we have to deliver on a very large scale. Our orchestrator, developed and enriched through 15 years of production experience, enables this. By directly executing runtimes (about fifteen, including Node.JS, PHP, Rust, Scala, Docker, etc.), our orchestration goes further in fine-grained provisioning and auto-scaling, smarter updates, and better security.

For us, containerization is not the be-all and end-all. If a runtime exists, we prefer to ease how to use it, natively provide it: this allows us to control the security updates of the base image without relying on the application team’s goodwill. For any code that doesn’t match an existing runtime, we naturally offer deployment via Docker images. However, bear in mind that while we can update the image, we cannot patch or update the encapsulated code.

However, as we continue to grow, we're meeting increasingly larger prospects who are using Kubernetes. The market demands Kubernetes. More and more customers want interoperability with their existing tools, fine-grained workload management, or simply a standard for their teams. We couldn’t ignore it.

The weakest link in Kubernetes: ETCD

Kubernetes is often called the “the cloud’s operating system”. But like every OS, it relies on a critical component: ETCD — a distributed key-value store meant to record the cluster’s global state. And that’s where problems begin.

ETCD can’t handle the load. Its architecture, designed for modest cases, sets a hard 8 GB technical limit. Performances drop as soon as you scale up, documentation is lacking, and project governance has been weakened by successive maintainer changes.

It’s no coincidence that Google, Microsoft and other hyperscalers have rewritten their own versions of ETCD — or that projects like k3s replaced it with PostgreSQL. It’s an operational nightmare when your job is to keep systems running. When each customer has their own Kubernetes cluster, it potentially means thousands of ETCD instances to manage, each with its quirks, backups, and varying performance. In short: a challenge for our teams 

Rethinking ETCD from the ground up: Our In-House Stack

So we did what Clever Cloud does best: smart reinvention. Using Materia KV, our serverless key-value database built on FoundationDB, we implemented ETCD our way.

Specifically, we recreated the key compatibility APIs (KeyValue, Watch, Lease, Compaction…) by interfacing them with infrastructure we fully control, offering:

• A multi-tenant architecture, designed for scale. Since we use FoundationDB as the database, we can apply horizontal scaling. Usually, adding nodes to ETCD slows it down — but each node added in MateriaETCD allows us to host more clients without negative impact;
• Fine-grained management of transactions, permissions, quotas, and statistics;
• A coherent stack maintained by our teams.

The result: a logically ETCD-compatible database — fast, reliable, scalable — built on FoundationDB, and operated at Clever Cloud scale. No more fragile clusters or overwhelmed DBAs: everything is integrated, industrialized, and instrumentable.

More importantly, this solution offers exceptional resilience, directly inherited from FoundationDB. Thanks to continuous simulation in a distributed environment, we can validate every software release across thousands of simulated failure scenarios. It’s a rare level of robustness that enables us to anticipate edge cases and guarantee very high service availability — and therefore, yours. This approach gives us unprecedented confidence in our ability to manage thousands of Kubernetes clusters without falling into the trap of exponentially growing operational complexity.

Clever Cloud Managed Kubernetes: a sovereign, pragmatic approach

We’re not changing our vision: our PaaS remains the best solution for teams seeking maximum productivity and security with minimal effort. But we also understand that some organizations need Kubernetes for architectural, portability, or standardization reasons.

That’s why our managed Kubernetes enters private access phase today. If you're a Clever Cloud customer and want to test it, you can contact us now to get it.

Our pledge? An integrated, secure, and mastered Kubernetes — built on a solid technical foundation. A Kubernetes that adheres to best practices — but without the flaws of its legacy components. A Kubernetes that finally lets you focus on your business.

Animé par Horacio Gonzalez - @LostInBrittany
avec la participation de :

• Mathieu Ancelin - @TrevorReznik
• Darya Khendrik - @DKhendrik
• Sébastien Allemand - @allema_s
• Anis Nielsen - @nielsenaa

Épisode enregistré le 18 décembre 2024

Chapitrage et Liens

00:00:16 : Intro et présentation des participants

00:03:25 : Problème de prod chez openai lié à Kubernetes : it's always kube-dns / coredns / kube-proxy
https://x.com/rauchg/status/1868047569299099903
https://status.openai.com/incidents/ctrsv3lwd797

00:06:38 : Amazon prétend que les développeurs ne codent qu'une heure par jour, et que l'IA est la solution pour plus de temps de codage
https://programmation.developpez.com/actu/365731/Amazon-pretend-que-les-developpeurs-ne-codent-qu-une-heure-par-jour-et-que-l-IA-est-la-solution-pour-plus-de-temps-de-codage-AWS-presente-Amazon-Q-Developer-son-outil-d-assistant-dote-d-IA/
https://programmation.developpez.com/actu/345479/Le-temps-perdu-par-les-developpeurs-couterait-des-milliards-aux-entreprises-un-gaspillage-qui-est-estime-a-environ-12-97-milliards-de-dollars-par-an/

00:17:50 : Les entreprises qui forcent les retours au bureau perdent leurs meilleurs talents
https://www.corporate-rebels.com/blog/what-happens-when-you-a-b-test-hybrid-work-the-results-are-fascinating
https://emploi.developpez.com/actu/365909/Les-entreprises-qui-forcent-les-retours-au-bureau-perdent-leurs-meilleurs-talents-selon-une-etude-les-donnees-disponibles-n-etablissent-pourtant-pas-que-les-employes-au-bureau-sont-plus-productifs/

00:31:40 : Transport for London hack - 30 000 employees reset in person MDP
https://www.bleepingcomputer.com/news/security/tfl-requires-in-person-password-resets-for-30-000-employees-after-hack/

00:35:40 : Le langage Go souffle ses 15 bougies et atteint sa position la plus haute sur l'indice Tiobe
https://programmation.developpez.com/actu/364901/Le-langage-Go-souffle-ses-15-bougies-et-atteint-sa-position-la-plus-haute-sur-l-indice-Tiobe-Google-annonce-que-le-nombre-d-utilisateurs-de-Go-a-plus-que-triple-au-cours-des-cinq-dernieres-annees/
State of Javascript : https://piccalil.li/links/state-of-java-script-2024/

00:43:30 : Tools : Bruno, un client API Open Source
https://www.usebruno.com/
Alternative open source à Postman ( https://www.postman.com/ ) ou Insomnia ( https://insomnia.rest/ )

00:47:55 : Markitdown - https://github.com/microsoft/markitdown
microsoft opensource un tool python pour transformer des fichiers PDF, PowerPoint, Word, Excel, Images, Audio, HTML, CSV, JSON, XML, ZIP en markdown
https://www.clever.cloud/fr/blog/engineering-fr/2024/12/16/markitdown-as-a-service-de-lai-a-la-production-sur-clever-cloud/

Musique de fin : https://www.youtube.com/watch?v=JglOS8TRFp4

Animé par Horacio Gonzalez - @LostInBrittany
avec la participation de :
- Antoine Sabot-Durand- @antoine_sd
- Erwan Rougeux - @ERougeux
- Florentin Dubois - @FlorentinDUBOIS

Épisode enregistré le 18 juillet 2024

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Chapitrage et liens

00:00:16 : Introduction et présentation des participants

00:04:07 : Sujet: Plugin *.google.com dans chromium-based https://x.com/lcasdev/status/1810696257137959018?s=46&t=TTwUj4NwwFWNozryQD5j4Q

00:14:19 : Sujet: Open source et foundations Clever Cloud joins the Eclipse Foundation: https://www.clever.cloud/blog/press/2024/07/10/clever-cloud-joins-the-eclipse-foundation/

00:26:10 : les grands groupes et le cloud DevOps Topologies : https://web.devopstopologies.com/ We are leaving the cloud

https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0

Kubernetes Comic https://cloud.google.com/kubernetes-engine/kubernetes-comic

00:49:11 : HAProxy 3 !

https://www.haproxy.com/blog/announcing-haproxy-3-0 https://www.haproxy.com/blog/reviewing-every-new-feature-in-haproxy-3-0

Maglev https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf

https://engineering.fb.com/2018/05/22/open-source/open-sourcing-katran-a-scalable-network-load-balancer/

https://blog.cloudflare.com/high-availability-load-balancers-with-maglev

https://github.blog/2018-08-08-glb-director-open-source-load-balancer/ https://github.com/openelb/openelb

00:54:17 : Manifold: Digital Asset Management

3D DAM : https://manyfold.app/

Dans ce formidable épisode nous parlons de la disparition des protocoles TLS 1.0 et 1.1 sur Clever Cloud, de notre Operator pour Kubernetes, de Rolland Garros sauce NFT, des drivers Nvidia en open source pour Linux, des suites du DDos du bloggeur Amos, de sécurité autour d'Heroku et de Doctolib, de développement de module Kernel en Rust avant de présenter l'outil de la semaine pour enfin finir en musique.

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Timecode & Liens

00:00:00 Introduction et présentation d’Alexandre Gourdel

Avant de passer aux sujets de sociétés, quelques annonces de Clever Cloud

00:09:40 Removal of tls 1.0 and 1.1 (Clément)
https://www.clever.cloud/blog/engineering/2022/05/03/removal-of-tls-1-0-and-1-1-from-our-load-balancers-on-june-30/

00:12:40 Et si on testait le Clever Operator pour Kubernetes ? (Florentin)
https://blog.zwindler.fr/2022/05/17/et-si-on-testait-clever-kubernetes-operator/
https://www.clever.cloud/blog/engineering/2022/04/28/introducing-the-clever-cloud-rust-sdk/

00:15:56 Kubernetes 1.24: Introducing Non-Graceful Node Shutdown Alpha (Florentin)
https://kubernetes.io/blog/2022/05/20/kubernetes-1-24-non-graceful-node-shutdown-alpha/

00:19:05 Le sport se met aux NFT (Alexandre)
https://www.francetvinfo.fr/sports/manne-financiere-communaute-de-fans-elargie-attrait-des-sponsors-les-nft-nouvel-eldorado-dans-le-monde-du-sport_5116483.html
https://club.rolandgarros.com/fr
Un détenteur d’un NFT « RG Game, Seat & Match » bénéficiera de nombreux avantages : accès à la version virtuelle du court Philippe-Chatrier ainsi qu’à des expériences exceptionnelles (jouer sur les courts de Roland-Garros, remporter des billets pour les prochaines éditions du Grand Chelem parisien et du Rolex Paris Masters, visiter les coulisses du stade Roland-Garros…). Acquérir un NFT de cette collection, c’est aussi rejoindre une communauté de fans engagés, avec qui échanger et partager votre passion.

00:28:32 Nvidia ouvre les drivers linux de ses cartes graphiques (Clément)
https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1
En fait ils ont pas le choix
Quelques jours plus tôt, y’a deux boîtes qui ont réussi à casser LHR grâce à la fuite de février.

00:34:22 Amos a amélioré son serveur HTTP perso suite à un DDoS (Julien)
https://twitter.com/fasterthanlime/status/1520937581059448838
https://fasterthanli.me/articles/i-won-free-load-testing

00:45:45 À quoi ressemble la gestion d’un gros incident sécu, l'exemple Heroku
https://status.heroku.com/incidents/2413?updated
Tweet du seum pour heroku

00:52:48 La sécurité pour les nuls
https://www.francetvinfo.fr/internet/securite-sur-internet/enquete-doctolib-certaines-donnees-medicales-ne-sont-pas-entierement-protegees_5147644.html
Article touilleur : https://www.touilleur-express.fr/2022/03/08/le-chiffrement-de-bout-en-bout-et-la-signature-denveloppe/

01:02:00 Things Are Getting Rusty In Kernel Land (Florentin)
https://hackaday.com/2022/05/17/things-are-getting-rusty-in-kernel-land/
Conférence de Georges Thomas sur “Comment développer un module kernel en Rust”
Pourquoi des modules en Rust, plutôt qu’un autre langage ?
As kernel second-in-command [Greg Kroah-Hartman] put it, “drivers are probably the first place for an attempt like this as they are the ‘end leafs’ of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them.”
Mais qu’est-ce qui se passe ? Que se passe-t-il ?
At some point in the future, one of the interested parties, like Google, would start writing new drivers in Rust. Google seems to be very interested in converting parts of Android to Rust, likely in an attempt to thwart the continued pwnage of their OS from the likes of the NSO group.
Another interesting connection is that [Miguel Ojeda], lead developer of the Rust for Linux effort, is now employed full time by Prossimo for that purpose. Prossimo is an arm of the Internet Security Research Group, which is also famous for leading Let’s Encrypt.

01:10:45 L'Outil de la semaine
https://vscodecandothat.com/

01:16:13 La musique de l’épisode : Billy Paul - Your Song - https://www.youtube.com/watch?v=DbgYUj3jQoI