Kubernetes is a container orchestrator; the cloud is where it most often runs. The term "Kubernetes cloud" therefore covers two related realities: running Kubernetes on cloud infrastructure, and relying on a managed Kubernetes service operated by a provider.

Kubernetes Is Not a Cloud

Kubernetes is an open source container orchestrator. How Kubernetes works comes down to orchestrating containers spread across a set of machines: it schedules their placement, deploys them, supervises their lifecycle, and manages their scaling and network exposure. These containers are often built with Docker, and the distinction between Kubernetes and Docker is itself a common source of confusion.

What Kubernetes does not do is provide the underlying machines, storage, and network. It needs infrastructure to run on, and that infrastructure can take several forms: physical servers (bare metal), virtual machines, a private cloud, or a public cloud. This is the layer a cloud provider supplies.

Hence a frequent confusion: comparing "Kubernetes" with "AWS", or Kubernetes with a cloud provider in general. The two sit at different layers. A cloud provider sells infrastructure and often offers a managed Kubernetes on top of it. Kubernetes orchestrates the containers running on that infrastructure. You do not choose between Kubernetes and the cloud: you can run Kubernetes on a cloud, or use the managed Kubernetes that cloud offers.

In other words, choosing an infrastructure and choosing who operates the cluster are two separate decisions. That is what shapes the types of offerings described below.

Running Kubernetes in the Cloud: Managed or Self-Managed

Once that relationship is clear, two operating models appear. Either you install and operate Kubernetes yourself on machines rented from a cloud provider, or you use a managed service where the provider operates the control plane for you.

The control plane is the dividing line between the two. It groups the components that drive the cluster: the apiserver, etcd (the datastore that holds the cluster state), the scheduler, and the controller-manager. Operating it yourself means handling version upgrades, which the Kubernetes project requires you to keep up with since it only supports its three most recent minor versions, internal TLS certificate rotation, high availability of these components across several nodes, etcd backup and consistency, and security patches under time pressure. A managed service takes this layer off your hands: you keep control of your workloads, your node pools, and their security, but no longer administer the cluster's critical infrastructure.

Not every need calls for a full cluster. Lighter distributions, such as K3s, exist and are worth evaluating depending on the workload and the context. And Kubernetes, managed or not, is one operating model among others. A PaaS follows a different one: you ship code, and the platform handles the build, execution, and scaling, without you having to operate an orchestrator. PaaS and Kubernetes meet different, complementary needs, and a single organization can use both.

The Three Types of Offerings for Running Kubernetes in the Cloud

Offerings fall into three types, depending on whether you operate the cluster yourself or a provider does, and, in the latter case, on whether that provider is a global hyperscaler or a European player.

Self-Managed on Cloud Infrastructure

You rent compute, storage, and network from a provider, then install and operate Kubernetes yourself. This approach gives the most complete control over the cluster and the underlying infrastructure, at the cost of the operational burden described above. It makes sense when specific infrastructure, network, or compliance constraints are not covered by the managed offerings available. It is also the approach of teams that want to keep a hand on every component of the cluster, from the container runtime to the scheduling and internal network configuration.

Managed by a Hyperscaler

The large global cloud providers offer managed Kubernetes services: Amazon EKS, Google GKE, Microsoft AKS. The provider operates the control plane, and you deploy your workloads with the standard Kubernetes tooling. These offerings are tightly integrated with each provider's ecosystem, which is their strength when your other services already run there, and the point to watch if you ever consider moving away. Their operators, however, fall under non-European jurisdictions, including for the regions they run in Europe. These offerings therefore do not meet a European sovereignty requirement, a decisive criterion for certain sectors and certain types of data.

Managed by a European Provider

Several European providers offer managed Kubernetes on infrastructure located within the European Union. Location matters, but it does not make an offering sovereign. A datacenter sitting in Europe remains within reach of the US CLOUD Act if the company operating it answers to a foreign jurisdiction. What determines sovereignty is the legal and capital control of the operator, not where the servers sit.

On this ground, several players offer managed Kubernetes: OVHcloud (Managed Kubernetes Service) and Scaleway (Kubernetes Kapsule). Clever Cloud offers Clever Kubernetes Engine, a managed Kubernetes operated by a European company based in France. Beyond location, these offerings differ in their real level of sovereignty, which depends on the operator and its subcontracting chain, and in how well they fit the tools you already use. For a closer look, French managed Kubernetes offerings are covered in a dedicated article.

Kubernetes Cloud: Key Takeaways

"Kubernetes cloud" refers to running Kubernetes on cloud infrastructure, along with the managed services providers offer so you do not have to operate the cluster yourself. The line between self-managed and managed runs through the control plane, the layer a provider either takes on or does not. Three types of offerings then appear: self-managed on cloud infrastructure, managed by a hyperscaler, and managed by a European provider, bearing in mind that a European location alone is not enough to make an offering sovereign. Which one fits depends on your infrastructure constraints, the tooling already in place, and your requirements around data and sovereignty. It all comes down to one distinction: the cloud supplies the infrastructure, Kubernetes orchestrates what runs on it, and the managed model determines who, the provider or you, operates the cluster in between.

What remains is to work out when a managed Kubernetes makes sense and how to choose one, and to clarify what a sovereign Kubernetes really means.

FAQ

Is Kubernetes a cloud?

No. Kubernetes is a container orchestrator, not an infrastructure provider. A cloud supplies the servers, storage, and network; Kubernetes orchestrates the containers running on top of them. You can run it on a cloud, or use the managed Kubernetes service a cloud offers.

Can you run Kubernetes outside the cloud, on bare metal or on-premises?

Yes. Kubernetes is infrastructure-agnostic: it runs on physical servers, virtual machines, a private or public cloud, and on hybrid environments combining several of these. The cloud is the most common setting, not a requirement.

Are "Kubernetes cloud" and "managed Kubernetes" the same thing?

Not exactly. "Kubernetes cloud" broadly means running Kubernetes on cloud infrastructure, which covers both a cluster you operate yourself and a managed service. "Managed Kubernetes" specifically refers to the offering where a provider operates the control plane for you. Every managed Kubernetes is Kubernetes in the cloud, but the reverse is not always true.

What is the difference between Kubernetes and a cloud provider like AWS?

They operate at different layers. AWS is a cloud provider: it sells infrastructure and offers, on top of it, a managed Kubernetes (Amazon EKS). Kubernetes is the orchestrator that drives the containers on that infrastructure. Setting them against each other is like confusing the warehouse with the system that organizes what goes into it.

Gravitee™, the AI agent management platform, today announced a strategic partnership with Clever Cloud, the French cloud provider, to deliver a sovereign control plane for AI running entirely on European infrastructure.

The partnership pairs Gravitee's AI Gateway and Authorization Management with Clever Cloud's France-based platform. This combination provides European public-sector bodies and regulated enterprises with a secure framework to govern AI consumption and production without binding their architecture to a single AI model or jurisdiction.

The timing is critical. On 12 June 2026, a US government export control directive ordered the suspension of two frontier AI models for foreign nationals worldwide. The models were available in the morning and gone by the evening, for every customer, with no transition window. This marks the first time a government has pulled a live commercial frontier model at scale, fundamentally rewriting the definition of AI sovereignty: a model can run in an approved region on compliant infrastructure, yet still be instantly disabled based on user access restrictions. 

This is not an isolated case. In 2024, OpenAI cut off ChatGPT and API access for users in China, Russia, and Iran in response to US export restrictions, with roughly two weeks' notice. The Anthropic suspension in June 2026 removed that notice period entirely: models were live in the morning and gone by evening, for every affected user, worldwide.

"When the suspension order came, the most safety-focused AI lab in the world had only one lever: shut the model off for everyone, everywhere. No targeting, no transition, no warning. Your architecture needs to be more resilient than the model it depends on," said Rory Blundell, CEO of Gravitee. "Most sovereign AI conversations stop at where the data or model runs, but that misses the point. The true sovereign asset is the control plane sitting in front of those models; managing who can call it, what data leaves, and how fast you can reroute traffic when a model suddenly disappears. Together with Clever Cloud, we are putting that control plane on European infrastructure, with an open-source core that organizations can inspect and run themselves."

One Stable Endpoint. Any Model. 100% Sovereign Infrastructure

Standardising on a single frontier model seems like a logical engineering choice, until sudden regulatory changes turn that model into a single point of failure. Gravitee introduces a governed abstraction layer between applications and LLM providers. If a model is abruptly withdrawn, swapping it out becomes a simple configuration rather than a catastrophic outage.

The partnership delivers four capabilities:

• Unified, multi-provider governance: Gravitee's AI Gateway exposes a single, governed endpoint across all major providers (Anthropic, AWS Bedrock, OpenAI, Google Gemini, and Vertex AI). Virtual models and automated fallback routes let teams instantly reroute traffic when a provider fails, without rewriting application code.
• True open-source independence: Open-source is the ultimate prerequisite for technical sovereignty. Gravitee provides a fully transparent, open-source platform that you can operate independently of any vendor lock-in. You cannot have sovereignty over a black box.
• Deploy anywhere, including fully air-gapped: Run your control plane exactly where you need it. The architecture is fully deployable across Clever Cloud, alternative cloud providers, on-premise infrastructure, or completely disconnected, air-gapped environments. 
• Boundary-level data control: True sovereignty is about what data crosses your perimeter, not just where it rests. Gravitee Authorization Management enforces fine-grained, identity-aware access controls right at the gateway, dictating exactly which users and AI agents can query specific models, and what data is permitted to leave.

Delivered as SaaS on Clever Cloud, the platform is being architected towards SEAL-3 (technological autonomy) under the European Union's sovereign cloud framework.

"Europe will not industrialise AI by relying on isolated technologies, but by assembling a complete industrial ecosystem. This partnership gives Gravitee customers the ability to run their AI control plane on a European cloud platform designed for production, while preserving the freedom to deploy the same architecture on partner infrastructures, on-premises or in fully air-gapped environments. That versatility is essential to building AI systems that remain resilient in the face of geopolitical events, supplier decisions or technological change, while keeping organisations in full control of their infrastructure.” says Quentin Adam, Clever Cloud CEO.

Gravitee on Clever Cloud is being validated for production use, with availability details to follow. Organisations evaluating their exposure to model concentration risk can request a model resilience review with the Gravitee team at Gravitee.io.

About Gravitee

Gravitee is the unified platform for API, event, and AI agent management. Founded in 2015 in Lille, France, Gravitee gives organisations one control plane to secure, govern, and observe agents, APIs, and event streams. The company operates an open-core model, with a free, open-source Community edition and paid Enterprise editions. Gravitee serves more than 350 enterprise customers across more than 30 countries and is recognised as a Leader in the 2025 Gartner® Magic Quadrant™ for API Management and as a Representative Vendor in the Gartner® Market Guide for AI Gateways. Learn more at https://www.gravitee.io.

It is a function distinct from containerization itself, which packages an application and its dependencies into a standard format. The differences between Docker and Kubernetes rest precisely on that distinction: Docker builds and runs containers, Kubernetes orchestrates them. Today Kubernetes is the reference orchestrator, but orchestration as a concept exists independently of the tool that implements it.

Why orchestration exists

Running three containers on a single server does not call for orchestration. You start them, you watch them by eye, you restart one by hand if something crashes. The nature of the problem changes the moment an application becomes a distributed system: several services, several machines, variable traffic, frequent deployments. The operational questions that appear then are concrete. Which machine should this new container run on? What happens if a node goes down in the middle of the night? How do you move from version 1.4 to 1.5 with no visible interruption? How does one internal service find another when IP addresses change on every restart?

Each of these questions has a possible manual answer, one you can even script. Orchestration is about automating them coherently, under a single model.

The five core functions of orchestration

Kubernetes handles these questions through a declarative model built on reconciliation loops: you describe the desired state of the system, and the orchestrator constantly compares that desired state to the actual state to bring them together. The five functions that follow are instances of this general mechanism.

Scheduling: placing containers on the right machines

Scheduling answers one question: when a new container needs to start, which machine in the cluster should run it? On a cluster of a few nodes with identical profiles, the decision is trivial. On a real cluster, it is not: some machines have GPUs and others do not, some are already loaded, some applications must be isolated while others must instead be co-located for latency reasons.

The kube-scheduler component makes this choice in two steps: filtering, which rules out the nodes that cannot host the pod (insufficient capacity, affinity constraints, taints and tolerations), and scoring, which ranks the remaining nodes against several criteria. The pod is then assigned to the chosen node through a binding operation with the API server. The quality of the decision depends on the information given to the scheduler. It is the resource requests declared on the pods that drive placement: the scheduler looks for a node whose available capacity covers those requests. The limits, on the other hand, play no part in placement; they cap a container’s consumption once it is running.

Scaling: matching capacity to real traffic

Scaling automates a decision that is simple to state: how many copies of a service should run at a given moment? Too many copies cost money. Too few cause incidents at the first spike.

Scaling is a function common to every orchestrator; the mechanisms vary by implementation. In Kubernetes, it rests on three distinct building blocks. The Horizontal Pod Autoscaler (HPA), part of core Kubernetes, adjusts the number of pods in a deployment based on a metric. To do so it relies on the Metrics Server, a component you install separately, because metric collection is not provided by default. The Vertical Pod Autoscaler (VPA), also shipped as a separate project, adjusts the resources allocated to each pod. The Cluster Autoscaler, finally, adds or removes whole nodes according to aggregate needs. These mechanisms assume reliable metrics: an HPA driven by CPU, when the service is actually constrained by disk I/O, will not produce the expected result.

Self-healing: replacing what fails

Past a certain number of machines, failures stop being exceptional events and become background noise. A disk fails, a kernel panic happens, a container leaks memory and ends up OOM-killed. Without orchestration, every failure triggers human intervention, more or less urgent. With orchestration, these events are absorbed without intervention.

Within Kubernetes, the mechanism rests on two elements. First, probes (liveness, readiness, startup) that let it know whether a container is actually working, and not merely whether it has started. Second, the principle that any object managed by a controller (Deployment, StatefulSet, DaemonSet) is constantly compared against the desired state: if a pod disappears, the controller requests a new one. The accuracy of the probes determines the quality of self-healing: probes that are too strict cause needless restarts, probes that are too lax let broken containers through.

Service discovery and internal load balancing

In a moving fleet of containers, where each pod has an ephemeral IP address, two services that need to communicate cannot rely on static IP configurations. Service discovery solves this through a layer of indirection. In Kubernetes, a Service object groups a set of pods (selected by labels) under a stable DNS name and a virtual IP. CoreDNS, the cluster’s internal DNS server, resolves these names. Traffic sent to the Service IP is distributed across the ready pods via kube-proxy. This principle is not specific to Kubernetes: other orchestrators meet the same need differently. On Clever Cloud, for instance, services find each other through configuration injection between applications and through Network Groups, an encrypted private network with internal DNS resolution.

Several types of Services exist (ClusterIP for internal traffic, NodePort and LoadBalancer for external traffic), alongside the notion of Ingress for application-level HTTP routing. This network layer, simple in appearance, holds a substantial share of the operational complexity of Kubernetes: CNI plugin choice, network policies, east-west traffic observability.

Rolling updates and rollbacks

Shipping a new version to production without interrupting the service is a risky operation when done by hand. Kubernetes treats it as a state transition: you change the Deployment manifest to point to the new image version, and the controller applies the configured rollout strategy.

The RollingUpdate strategy (the default) progressively replaces old pods with new ones, guaranteeing that a minimum number stays available at all times. The Recreate strategy stops everything and then restarts, useful for incompatible schema migrations. In case of failure, the rollout does not revert on its own to the previous state: it stops, the new pods that fail their probes do not replace the old ones, and it is an operator who triggers the return to the previous version with kubectl rollout undo. For this to work, the versions must be compatible with each other during the transition, which implies discipline on API contracts and database migrations.

Beyond the five core functions

Kubernetes orchestration does not stop at these five functions. In practice, a production Kubernetes cluster also manages application configuration (ConfigMaps), secrets (with or without encryption at rest), persistent storage through PersistentVolumeClaims, authorization (RBAC), network isolation (NetworkPolicies), observability (logs, metrics, traces), and certificate lifecycle management. Each of these is itself an operational responsibility that adds to the base.

Without an orchestrator vs with Kubernetes: a function-by-function comparison

The table does not rank the two columns. It shows that Kubernetes provides a unified model for these five functions, where an approach without an orchestrator handles them separately with different tools. For a system that does not need this unification, the left-hand column remains perfectly valid.

Common practices worth knowing

Choose the tool based on the need, not by default. Not every application needs scheduling, automatic scaling or service discovery at the level Kubernetes offers. A PaaS, a VM deployment, or a systemd binary meet many needs with a different operational model.

Think about observability from the start. A Kubernetes cluster without centralized logs, aggregated metrics and traces quickly becomes hard to operate beyond a handful of services. Observability is an integral part of orchestration, not an optional add-on.

Define requests and limits before enabling autoscaling. The HPA and the Cluster Autoscaler rely on the pods’ declared resources to decide on scaling. Without declarations, their decisions rest on partial information.

Get probe configuration right. Liveness and readiness probes govern both self-healing and traffic routing. A rough configuration degrades both functions at once.

When Kubernetes orchestration becomes relevant

No single one of the five functions, taken in isolation, justifies bringing Kubernetes into a system. A deployment script, a properly configured load balancer, a monitoring tool with automatic restart can each cover one of them individually. What justifies adopting an orchestrator is the point where the five functions all become necessary at once, on an infrastructure distributed enough to make ad hoc solutions expensive to maintain.

Concretely, that corresponds to architectures with a dozen services or more, deployed across several machines, with frequent deployment cycles, significant load variations and resilience requirements that no longer tolerate manual intervention. For contexts more constrained in resources (edge, IoT, development machines, small clusters), a lightweight Kubernetes distribution such as K3s can be a good fit. A PaaS also meets these needs, as it does many other application profiles (industrialized deployment, automatic scaling, resilience, updates), with an operational model distinct from Kubernetes.

When Kubernetes does become relevant, the next question rarely concerns installation and more often day-to-day operations: control plane updates, etcd management, certificate rotation, observability, backups. That observation is what explains the growing adoption of managed Kubernetes services. At Clever Cloud, Clever Kubernetes Engine addresses this need with Materia etcd, a serverless implementation of the etcd API built on FoundationDB that takes over from standard etcd, a known bottleneck at scale, on sovereign infrastructure spread across our three Paris datacenters.

Container orchestration in summary

Container orchestration automates several categories of operational decisions, chief among them five main classes: where to place a container, when to start more of them, what to do when one of them fails, how they find one another, and how to move from one version to the next without interruption. Kubernetes brings these functions together under a unified model, which makes it the reference tool for distributed systems that need them all at once. The useful question, faced with a project, is not whether you should do orchestration, but which of these functions are actually needed, and at what level of automation.

FAQ - Kubernetes orchestration

What is the difference between containerization and orchestration?

Containerization packages an application and its dependencies into a standardized format that runs identically on any compatible host. Orchestration automates the management of a fleet of containers in production: placement, scaling, self-healing, service discovery, updates. Docker is the reference tool for the former, Kubernetes for the latter.

Do you necessarily need Kubernetes to orchestrate containers?

No. Kubernetes is the most widely adopted orchestrator, but others exist: HashiCorp’s Nomad, which orchestrates containers, VMs and binaries in a single cluster, or Docker Swarm, still maintained but with declining adoption. Apache Mesos, long cited as an alternative, was retired to the Apache Attic in October 2025 and is no longer in active development. Beyond that, a PaaS like Clever Cloud covers the full set of these orchestration functions (placement, automatic scaling, self-healing, rolling updates, service discovery) with its own control plane, independent of Kubernetes. It is that control plane that orchestrates both the applications running in VMs and the containers of the platform’s Docker runtime.

Is container orchestration necessary for CI/CD?

No, but the two are often used together. Modern CI/CD pipelines produce container images as their final artifact, and the orchestrator (Kubernetes or another) takes over to deploy and operate those images. CI/CD and orchestration are two complementary stages of the application lifecycle.

Does K3s allow orchestration in constrained environments?

Yes. K3s is a CNCF-certified Kubernetes distribution designed for resource-limited environments (edge, IoT, development machines, small clusters). It keeps the standard Kubernetes APIs while reducing the resource footprint and deployment complexity.

Does managed Kubernetes change the orchestration functions available?

No. Managed Kubernetes provides the same set of orchestration functions as a self-hosted cluster, since it is the same Kubernetes. The difference lies in how operational responsibilities are split: the provider takes on control plane management, updates, and the underlying monitoring. Users then focus on their application workloads.

Which orchestration function is the hardest to master?

Networking is frequently cited as the most complex. Service discovery, internal load balancing, NetworkPolicies, Ingress, CNI plugin, east-west traffic observability: the Kubernetes network layer concentrates a significant share of advanced operational topics and remains a frequent source of production incidents.

Since its launch, the UP Program has supported tech startups at different stages of maturity, with one simple goal: helping them build, deploy and scale their product on a robust cloud foundation, without turning infrastructure into an operational bottleneck.

Cybersecurity, health, legaltech, agriculture: this fifth selection once again reflects the diversity of the use cases supported by Clever Cloud. It brings together projects operating in demanding environments, where reliability, security, data control and the ability to scale quickly become decisive factors.

UP Program: the startups selected for this fifth edition

Sentibee — Simplifying vulnerability intelligence

Sentibee develops a vulnerability intelligence solution designed to help organisations better prioritise cyber risks.

Its goal is to reduce noise, contextualise alerts and turn complex data into truly actionable insights. The platform combines data collection, AI-powered qualification and human expertise to help teams understand what really matters: exploitability, real-world impact, priority level and the actions to take.

With VulnPilot, Sentibee also enables organisations to build watchlists, monitor critical assets or technologies, and generate prioritised action plans. A pragmatic approach to cybersecurity, designed to make vulnerability intelligence clearer, more useful and more accessible.

Pictaderm — Dermatological expertise in pharmacies

Pictaderm makes it easier to access dermatological advice through partner pharmacies, without an appointment.

The solution allows a patient to visit a pharmacy for a skin condition or a lesion that needs monitoring, and receive the opinion of a medical expert within 48 hours. Pictaderm addresses a concrete challenge: bringing medical expertise closer to the field, in a context where access to dermatology appointments can involve long waiting times.

The platform relies on a network of registered pharmacies and has already supported several tens of thousands of patients. For pharmacists, it provides a tele-expertise tool that helps guide patients more quickly and strengthens their role in the care pathway.

Legaia — An AI legal assistant designed by lawyers

Legaia develops Gaia, an AI legal assistant available directly by email and designed for lawyers.

The promise is simple: enabling law firms to use AI without changing their working habits. No new platform to open, no additional tool to learn: the lawyer simply forwards an email to Gaia and receives an initial analysis, search, draft or translation.

The solution covers several day-to-day use cases: drafting letters, searching case law, numbering and stamping exhibits, retrieving official documents or translating attachments. Legaia also places strong emphasis on security, confidentiality and compliance, which are essential requirements for professionals handling sensitive documents.

Cockpit Agriculture — Managing agricultural performance

Cockpit Agriculture develops an intelligent performance management solution for farmers and their value chains.

The startup is part of an augmented agriculture approach: helping agricultural stakeholders gain greater control, better monitor their activity and make more reliable decisions. In a sector facing strong economic, environmental and operational constraints, the ability to manage performance and make decisions with confidence is a key issue.

With this approach, Cockpit Agriculture addresses a central need: giving farmers and agricultural value chains tools designed to fit the realities of the field.

A batch that reflects the challenges faced by tech startups

The four startups in this new selection operate in very different sectors, but share several common points.

They all develop products where technology is not just a support function, but a central part of the value proposition. They also address use cases where trust is central: cyber vulnerabilities, care pathways, legal documents and agricultural management.

In these contexts, cloud infrastructure must remain reliable, scalable and under control. It must allow teams to iterate quickly, secure data, absorb growth and maintain a high level of availability, without diverting them from their core business.

This is precisely the role of the UP Program: supporting startups at the stage where infrastructure becomes a strategic topic.

The UP Program: a support framework designed for the long term

The UP Program was designed to support startups beyond their first cloud credits.

Selected startups benefit from a set of resources to help them structure their technical trajectory:

— up to €10,000 in cloud credits for the first year;
— onboarding on the Clever Cloud platform;
— training with Clever Cloud engineers;
— monthly coaching;
— access to support;
— workshops and masterclasses for technical teams;
— mentoring for founders and product teams;
— visibility through Clever Cloud media, social networks and events;
— access to financial planning and structuring tools.

The goal is to allow startups to focus on their product, their users and their market, while building on an automated, robust infrastructure capable of scaling with them.

Are you a startup looking to join the UP Program?

The next UP Program selection will take place on 16 September 2026.

Startups wishing to apply can submit their application now and discuss their project, technical needs and growth challenges with the Clever Cloud teams.

Following its first certification Cloud Concepts 101, Advanced Deployments is aimed at developers, technical partners and DevOps teams who want to go further in their use of Clever Cloud: understanding the build / run cycle, configuring their environments, managing persistence, and making deployments more reproducible with Terraform.

With this second certification, Clever Cloud continues its educational path around cloud computing and its platform, with a concrete, progressive and directly applicable approach.

Understanding advanced deployments on Clever Cloud

The Advanced Deployments certification is built around five main modules:

1. Systems integrated into deployments: understand the full deployment cycle, from build to run, including logs, isolation, immutability, scaling, and the differences between build flavour and run flavour.
2. Advanced configuration through environment variables: learn how to interact properly with the platform, contextualise instances, organise environments, and use variables as a central configuration mechanism.
3. Language-specific environment variables: understand how Clever Cloud configures runtimes across ecosystems such as Node.js, PHP, Python, Java or Docker, and how to adjust versions, build behaviour, execution, memory and performance.
4. Storage and persistence management: distinguish between stateless and stateful approaches, choose the right storage add-ons, manage persistence in a distributed environment, and anticipate concurrency, backup and high-availability challenges.
5. Deploying with Terraform: discover Infrastructure as Code in a PaaS context, configure the Clever Cloud provider, describe applications, databases and storage in HCL files, and build reproducible, versionable environments.

A certification designed for real-world environments

In the life of a project, needs evolve quickly. One application becomes several environments. A simple configuration becomes a set of variables to organise. A database, a cache or object storage may become part of the architecture. And when infrastructure needs to be reproduced, audited or shared, Terraform becomes a valuable ally.

Advanced Deployments supports this gradual increase in complexity. It helps users better understand the platform’s mechanisms, diagnose build or runtime errors more quickly, configure environments properly, and manage deployments in a more reliable and reproducible way.

Showcasing your progress

As with Cloud Concepts 101, people who validate the Advanced Deployments certification can showcase this new step in their learning path.

They receive a digital badge, which they can add to their LinkedIn profile to highlight their growing expertise on Clever Cloud and advanced deployments.

Take Advanced Deployments now

The Advanced Deployments certification is now available on the Clever Cloud Academy.

Already validated Cloud Concepts 101? Now is the right time to move to the next level.

Discovering the Clever Cloud certification path for the first time? Start with the basics, then take on this new challenge.

Several recent Linux kernel vulnerabilities have required a swift response from infrastructure operators.

Among them, Copy Fail and Dirty Frag drew attention because they involve local privilege escalation scenarios. Copy Fail is tracked as CVE-2026-31431.

Dirty Frag covers two distinct vulnerabilities, CVE-2026-43284 and CVE-2026-43500, tied to Linux kernel components.

At Clever Cloud, we treated these vulnerabilities as critical infrastructure matters. Our goal was twofold: quickly shrink the exposure window, then sustainably improve our kernel selection and deployment process.

This article reviews our approach, the decisions made, and the changes brought to our operations pipeline

Why these vulnerabilities called for a fast response

Copy Fail and Dirty Frag belong to the family of local privilege escalation vulnerabilities. In this type of scenario, an attacker must already be able to execute code locally, but can then attempt to gain higher privileges on the affected machine.

Dirty Frag rests on two Linux kernel flaws.

They notably affect modules related to ESP, used by IPsec, and to RxRPC. On a cloud platform, this type of vulnerability calls for a rapid analysis. The risk is not limited to a single isolated machine.

Scenarios tied to shared environments, containerized workloads, and isolation mechanisms must also be assessed.

What we verified

We analyzed the potential impact of these vulnerabilities on our environments. This step is not just about reading security advisories. It also involves verifying whether a theoretical scenario can become relevant in our operating context.

In the case of Copy Fail, the flaw came under embargo together with its patch. We published a new system image with the patch applied in the days that followed.

Our customers' applications were redeployed shortly after.

In the case of Dirty Frag, our internal analyses confirmed that these vulnerabilities had to be taken seriously. ESP modules are enabled in our kernels to support some specific customer needs. Fortunately, RxRPC-related modules are not present in our environment, as they serve no purpose for our usage.

We do not detail the technical steps of the exploitation here, since the purpose of this article is to inform our customers, not to publish a reproducible procedure.

This validation confirmed the operational decision: handle the matter immediately, reduce the exposed surface, then force the necessary redeployments.

Our operational response

Rolling out immediate measures

We first applied quick measures on the affected kernels. In the case of Dirty Frag, the publicly recommended measures focus in particular on the kernel components related to ESP and RxRPC.

On Clever Cloud's side, the goal was clear: reduce the identified exposed surfaces and shrink the exposure window without waiting for a standard maintenance cycle.

Redeploying the affected workloads

A kernel update only matters if the affected systems actually restart on a patched environment. We therefore launched a progressive redeployment of applications, then handled the cases that blocked this redeployment.

This phase matters. On a managed platform, the fix is not limited to producing an image or compiling a kernel. The execution chain must also actually use the expected version.

Improving the process along the way

We also took advantage of this sequence to replace a temporary mechanism with a cleaner integration into our orchestration pipeline.

Concretely, the kernel choice is now passed more explicitly through our internal pipeline, all the way to Supernova, our hypervisor agent. This evolution replaces the stiffer workaround put in place in the heat of the moment.

That is the central point of this intervention: fix fast, then make the fix more reliable for future operations.

What this changes for Clever Cloud customers

For customers, the expected effect is simple: reduce exposure without any manual action on their part whenever the platform can handle the redeployment.

Clever Cloud runs an architecture that relies in particular on isolation through virtualization. This approach is documented on our security pages and in our technical content on running containers inside virtual machines. It does not eliminate every risk, but it limits certain lateral movement scenarios compared to models where multiple workloads share the same execution environment directly.

We avoid, however, presenting this isolation as an absolute guarantee. A kernel vulnerability must always be taken seriously.

That is why we combined mitigation, redeployment, and improvement of our operations pipeline.

What we take away

This sequence confirms three principles.

First, a kernel vulnerability must be analyzed in its actual operating context. A public alert is not enough. We need to understand whether the conditions required for exploitation can exist on the platform.

Second, reaction speed matters. The Copy Fail and Dirty Frag vulnerabilities were disclosed publicly within a few days of each other, with analyses published by several players in the Linux and cloud ecosystem.

Finally, a useful security response must not only fix the problem of the moment. It must also improve the system that will handle the next incident.

That is what we did here: handled the vulnerabilities, shrank the exposure window, and strengthened our kernel management process.

Q&A

What is a local kernel vulnerability?

A local kernel vulnerability is a flaw that already requires execution capability on the affected machine. It can then allow gaining higher privileges, such as root, if the kernel is vulnerable.

Why do these flaws concern cloud platforms?

Cloud platforms run many workloads with isolation mechanisms. A kernel flaw can become critical if it allows crossing certain boundaries between processes, containers, or execution environments.

Are Dirty Frag and Copy Fail the same vulnerability?

No. Copy Fail is tracked as CVE-2026-31431. Dirty Frag covers CVE-2026-43284 and CVE-2026-43500. These vulnerabilities are close in impact, but they are distinct.

What action is required from Clever Cloud customers?

No general action is required from customers for environments handled by the platform. The automation brought by Clever Cloud allowed everything to be updated without action needed. Specific cases are tracked individually.

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.

But in production, the topic quickly goes beyond simply deploying containers. A Kubernetes cluster also means managing a control plane, updates, security patches, networking, storage, observability, costs, and coherent integration with the rest of the information system.

The question is no longer only whether you should use Kubernetes, but how to run it without rebuilding an entire operational platform around the cluster.

On Thursday 21 May at 11:30, Clever Cloud is hosting a webinar dedicated to Clever Kubernetes Engine (CKE), our managed Kubernetes service, to discuss these challenges with you.

Kubernetes: a standard, but not just an orchestrator

Kubernetes provides a common foundation for deploying, scaling and operating containerised workloads. It integrates with tools widely adopted by technical teams: kubectl, Helm, Terraform, GitOps…

That is also why many organisations have adopted it. Some solutions are already designed to be installed on Kubernetes. Some vendors distribute their solutions through Helm charts or manifests. Some teams have built their practices, workflows and architectures around this ecosystem.

But standardisation does not remove the operational workload. It shifts it. As soon as a cluster needs to be used in production, other topics appear: control plane availability, updates, monitoring, security, resilience, dependency management and integration with existing services.

This is precisely where architecture choices become important.

CKE: keep Kubernetes, reduce what needs to be operated

With Clever Kubernetes Engine, the goal is to offer another way to run Kubernetes: keep the standards, tools and practices your teams already use, while reducing the amount of infrastructure you need to manage day to day.

CKE lets you create and operate Kubernetes clusters on Clever Cloud infrastructure. The control plane is operated by Clever Cloud, nodes are provisioned on demand, and updates can be applied on request or in the event of a critical vulnerability.

For technical teams, the principle remains the same: you use Kubernetes with your usual tools. You retrieve your kubeconfig, use kubectl, Helm, Terraform or your GitOps workflows, without having to adopt a proprietary tool or completely rethink your practices.

CKE does not force you to change your Kubernetes tools. It mainly reduces what you need to manage around the cluster.

PaaS and Kubernetes: two complementary approaches

At Clever Cloud, PaaS remains at the heart of our approach. For a large number of applications, it enables fast deployment, reduces infrastructure workload and helps teams focus on code. But not all use cases are the same.

Some teams already use Kubernetes. Some architectures require more control over orchestration. In these cases, Kubernetes is not just a technical choice: it is already the team’s working framework.

CKE complements Clever Cloud’s PaaS to address these needs, without opposing the two models. The point is to use the right tool in the right place: PaaS when it helps teams move faster, Kubernetes when it naturally fits the architecture and the team’s practices.

A webinar to see how it works in practice

On Thursday 21 May at 11:30, Florent Perreux, CSO at Clever Cloud, and Gilles Biannic, SRE Engineer at Clever Cloud, will show you how CKE integrates into existing architectures and what it changes in the day-to-day operation of a Kubernetes cluster.

The goal: understand how to use Kubernetes with your usual tools, while reducing the operational workload around the cluster.

On the agenda

During this 30-minute webinar, we will cover:

• why Kubernetes remains demanding to operate in production;
• when Kubernetes makes sense as a complement to a PaaS;
• what CKE handles: control plane, updates, critical patches, platform integration;
• how to keep your usual tools: kubectl, Helm, Terraform, GitOps;
• a demo: creating a cluster, retrieving the kubeconfig, deploying an application and exposing a service;
• concrete use cases: migration from an existing cluster, PaaS complement, reduced operational workload;
• a Q&A session to ask your questions live.

Why attend?

This webinar is for teams already using Kubernetes, operating clusters in self-managed environments or with a hyperscaler, or looking for a European alternative to clusters operated by hyperscalers or self-managed setups.

You will be able to:

• understand what really creates complexity around Kubernetes;
• identify whether CKE fits your context: hyperscaler, self-managed, PaaS or hybrid architecture;
• see how to use Kubernetes without changing your tools or workflows;
• discover how CKE integrates with the Clever Cloud ecosystem;
• ask your questions directly to our teams.

CKE is currently available in public beta. During this period, you will also be able to talk to our teams to learn more about access conditions and available discount vouchers.

Register now

The webinar will take place on Thursday 21 May 2026 at 11:30, online on Livestorm.

You already use Kubernetes, operate your own clusters, or are looking for an integrated alternative to reduce your operational workload? Join us on 21 May.

A concrete response to sovereignty challenges and a new benchmark for European cloud

In a context of increasing reliance on non-European technologies, this decision highlights the ability of these three players to deliver concrete, competitive solutions aligned with European values.

Through this selection, the Commission demonstrates that technological performance can be combined with strategic control. It also confirms a multi-vendor approach, aimed at strengthening resilience and avoiding dependency on a single provider.

A European consortium serving the EU’s strategic autonomy

The selected consortium brings together leading and complementary European players, meeting the highest standards in terms of sovereignty, security and performance.

OVHcloud provides, through its OPCP platform, a standardized, scalable and operational cloud solution designed to deliver massive compute resources and enable rapid large-scale deployment via OPCP Core.

Clever Cloud contributes an advanced orchestration layer — including PaaS, containerization and managed services — enabling the management, automation and unification of complex environments. This approach supports hybrid architectures combining public cloud, private cloud and dedicated infrastructures with a high level of flexibility.

DEEP contributes both its hosting capabilities and its expertise in cloud, cybersecurity and artificial intelligence.

A strong signal for Europe’s digital future

This framework raises the bar for sovereignty requirements, encourages the adoption of European standards, and paves the way for more balanced competition in cloud and AI.

It also reflects strict alignment with the European Commission’s Cloud Sovereignty Framework, which sets high standards in terms of strategic and legal control, security and European compliance, dependency transparency, technological openness and environmental performance.

Octave Klaba, CEO of OVHcloud, said:“We are very pleased with the trust placed by the European Commission in our consortium. This project proves that strong alternatives exist in Europe, capable of meeting the highest standards. It also shows that when European players join forces, they make a difference.”

Quentin Adam, CEO of Clever Cloud, added:“We are very proud to have been selected. This is the result of significant collective work carried out with OVHcloud and DEEP. We have built a robust response capable of meeting the requirements of European institutions. What is interesting here is that technological sovereignty is no longer just a concept: it takes shape through infrastructures, platforms and players capable of operating together in production. It also proves that European players can cooperate effectively and strengthen the entire ecosystem.”

Sébastien Genesca, Managing Director of DEEP by POST Group, concluded:“We thank the European Commission for the trust placed in our consortium. Together with OVHcloud and Clever Cloud, we have carried out demanding and exciting work with a shared objective: to build a sovereign cloud offering by combining the best of our technological expertise, while sharing common European values.”

About OVHcloud

OVHcloud is a global player and the leading European cloud provider, operating more than 500,000 servers across 46 data centers on 4 continents, serving 1.6 million customers in over 140 countries. A pioneer of trusted and sustainable cloud with a competitive performance-to-price ratio, the Group has relied for over 20 years on an integrated model that ensures full control over its value chain — from server design to data center construction and operation, including the orchestration of its fiber optic network. This unique approach enables OVHcloud to independently cover all customer use cases, while promoting a responsible model with efficient resource usage and one of the lowest carbon footprints in the industry. Today, OVHcloud delivers next-generation solutions combining performance, price predictability, and full data sovereignty to support customers’ growth with complete freedom.

About DEEP by POST Luxembourg Group

DEEP by POST Luxembourg Group is an entity of POST Telecom S.A., a subsidiary of POST Luxembourg, bringing together all the Group’s telecom and ICT expertise to support the digital transformation of businesses and organizations. With more than 750 employees, DEEP is a leading partner for professional digital services in Luxembourg, the Greater Region, and internationally.

DEEP offers a comprehensive portfolio of services and solutions across seven technological domains, with Cloud, Cybersecurity, and Artificial Intelligence playing a key role. As both a Luxembourg-based player and a provider of critical services for the national economy, DEEP delivers solutions designed and operated by its own teams.

DEEP relies on some of the most advanced and resilient telecom and data center infrastructures in the country, recognized among the most robust in Europe. The convergence of telecom and ICT expertise enables DEEP to cover the entire value chain, from connectivity needs to data valorization.

More information: www.deep.eu – www.postgroup.lu

About Clever Cloud

Clever Cloud was founded in 2010 in Nantes, France, and specializes in cloud hosting and automation. Its platform enables applications to be deployed in just a few clicks, on public cloud environments as well as on customer infrastructures, without having to manage scaling or maintenance. At the same time, it ensures a high level of security and data control, in line with sovereignty requirements. Its customers include Airbus, Great Place to Work, MAIF, Docaposte, Fairphone, Solocal, and Limagrain.

This is precisely the role of observability. It is also why Elasticsearch has gradually established itself as an analytical foundation for logs, metrics, and traces.

In this article, we will look at how Elasticsearch fits into an observability approach beyond simple logging, and how it enables technical signals to be correlated in order to better understand application behaviour.

What is observability, and why Elasticsearch is involved

Observability refers to the ability to understand the internal state of a system based on its external signals. Unlike traditional monitoring, it is not limited to predefined metrics or fixed thresholds.

Observability relies on collecting rich, contextual data, analysing it across multiple dimensions, and exploring situations that were not anticipated in advance. In this context, Elasticsearch plays a key role. Its indexing and search engine can analyse large volumes of heterogeneous data, structured or unstructured, in near real time, which aligns precisely with the needs of a modern observability approach.

The three pillars of observability: logs, metrics, and traces

An observability strategy is built on three complementary types of signals. Each addresses a different question and provides a specific perspective on system behaviour.

Logs: understanding what happened

Logs are events produced by applications and infrastructure components. In Elasticsearch, they are associated with a timestamp, either derived from the log event itself or from the ingestion time. They provide a high level of detail and make it possible to understand the precise context of an error, unexpected behaviour, or incident.

Elasticsearch has historically been well suited to this use case:

• ingesting large volumes of data,
• fast full-text search,
• fine-grained event exploration.

Logs provide valuable context, but they become difficult to exploit on their own as architectures become more distributed and data volumes grow significantly.

Metrics: measuring system state

Metrics are numerical data aggregated over time. They describe the overall state of a system and make it possible to track its evolution. Latency, error rates, and resource consumption provide a high-level view of application or infrastructure health.

In Elasticsearch, these data are stored as time-series. This enables aggregations, long-term trend analysis, and anomaly detection, while still allowing metrics to be linked to other technical signals.

Traces: following a request end to end

Traces describe the full journey of a request through a distributed system. They are essential for understanding dependencies between services and for pinpointing the exact source of latency or errors.

Each trace is composed of multiple segments representing different execution steps. Once indexed in Elasticsearch, these traces can be correlated with associated logs and metrics, making it easier to analyse complex behaviours in microservices environments.

How Elasticsearch correlates logs, metrics, and traces

The value of observability does not lie in individual signals taken in isolation, but in their correlation. Elasticsearch facilitates this correlation through several structural mechanisms:

• a shared indexing engine,
• common schemas such as ECS (Elastic Common Schema), which provides a shared structure for logs, metrics, and traces,
• cross-signal search capabilities.

In practice, this approach makes it possible to navigate naturally between signals. An alert triggered by a metric can lead to the analysis of related traces, followed by the exploration of logs associated with a specific request. Kibana plays a central role by making these correlations visible and actionable, through visualisations, dashboards, and exploration tools designed for cross-signal analysis.

Historically, Elasticsearch is best known for powering application search engines, particularly for indexing and querying website content. The same principles of fast, contextual search apply to observability data: logs, metrics, and traces are also indexed and queried as datasets, which makes large-scale exploration and correlation possible.

OpenTelemetry: a key standard for observability with Elasticsearch

In modern architectures, data collection is just as important as data analysis. OpenTelemetry has emerged as an open standard for application instrumentation, covering traces, metrics, and logs.

Elasticsearch natively supports OpenTelemetry, enabling signal collection to be standardised without relying on proprietary formats. This compatibility improves interoperability, reduces technological lock-in, and allows observability tooling to evolve without requiring changes to existing application instrumentation.

Observing your applications with Elastic on Clever Cloud

In a PaaS hosting context, observability must remain easy to enable and simple to operate. On Clever Cloud, Elasticsearch is available as a managed add-on. Applications can send their logs using Elasticsearch drains, enabling automatic centralisation of application logs. Several components can then be enabled depending on requirements:

• a managed Elasticsearch cluster,
• Kibana for exploration and visualisation,
• Elastic APM for application performance analysis.

This approach makes it possible to centralise application logs, collect relevant metrics, and trace requests without having to manage the underlying infrastructure. The goal is not to multiply tools, but to provide a coherent observability foundation integrated into the application lifecycle.

Conclusion

Observability is not about stacking monitoring tools. It is about correlating logs, metrics, and traces in order to understand increasingly complex systems.

Thanks to its indexing, search, and analysis capabilities, Elasticsearch provides a solid technical foundation for this approach. Combined with open standards and interfaces such as Kibana, it enables teams to move from fragmented visibility to a comprehensive understanding of application behaviour.

In modern cloud environments, this correlation is no longer a luxury. It is a necessary condition for operating production systems reliably.