Four startups, four products and very different use cases: telemedicine, AI agents, interactive learning and hotel performance management. Yet behind that diversity lies the same challenge: turning a technology product into a service that people genuinely use.

Once the first users arrive, it is no longer enough for a product simply to work. It needs to be deployed, operated and secured reliably, while being able to support new use cases without its cloud infrastructure becoming a barrier to growth.

This is precisely the stage at which the UP Programme supports selected startups.

The four startups joining the sixth UP Programme cohort

Kernel: simplifying access to online care pathways

Kernel is a telemedicine platform providing access to personalised online care pathways, particularly for dermatology and hair loss.

The process starts with a structured medical questionnaire. A doctor registered with the French Ordre des médecins then reviews the case, establishes a diagnosis and, where necessary, issues an appropriate prescription. The treatment can then be prepared by an authorised pharmacy and delivered to the patient.

Kernel also provides a follow-up area that allows patients to stay in contact with their doctor. In a context where the data involved is particularly sensitive, the platform states that medical data is encrypted and hosted in France on HDS-certified servers.

With Kernel, technology supports an end-to-end care pathway, from the initial consultation through to patient follow-up.

Nijal AI: deploying AI agents without giving up autonomy

Nijal AI develops artificial intelligence agents for businesses, institutions and local authorities.

Its approach is built around three principles: providing solutions that are ready to deploy, allowing them to run either in the cloud or on-premises, and avoiding technological dependencies that can become difficult to control.

Nijal AI also places a strong emphasis on transferring skills to the teams using its solutions. The objective is not simply to design an AI agent, but to enable organisations to integrate it into their processes, maintain it themselves and retain control over how it evolves.

This approach reflects an increasingly practical challenge in AI: moving beyond experimentation towards services that can genuinely be operated, maintained and integrated into an organisation’s information systems.

Qiplim: turning content into interactive learning experiences

Qiplim develops a platform combining interactive live sessions with artificial intelligence.

From a document, presentation, web page or video, the platform can generate interactive activities that can then be used during a live session. Participants join via a QR code without having to create an account.

Qiplim is also developing an AI Studio designed to extend the experience beyond the live session, allowing participants to interact with the source material made available to them and transform it into different learning formats.

Data sovereignty is an integral part of its positioning: Qiplim processes its data in France on Clever Cloud, while the artificial intelligence models it uses are served from within the European Union by Mistral AI.

The platform already reports more than 210 beta testers and positions itself as a sovereign alternative to tools such as Kahoot and NotebookLM.

Arkan: from developing AI solutions to building its own products

Arkan supports businesses in designing, developing and deploying solutions based on artificial intelligence.

Alongside bespoke AI projects for companies across different sectors, Arkan is also developing its own products.

Among them, its Hotel Performance Platform centralises data from the tools already used by hospitality businesses, including property management systems (PMS), channel managers and extranets. This data is brought together in a dashboard designed to make it easier to monitor metrics such as occupancy, average room rate, RevPAR and booking trends. An AI assistant also allows users to query the data using natural language.

The platform is already used by two hotel groups representing thirteen properties.

At the same time, Arkan is developing Covera, a solution designed to automate the verification of suppliers’ insurance certificates using artificial intelligence.

Combining bespoke AI development with the development and operation of its own products also illustrates the scaling challenges technology companies can face as they grow.

When a product meets its users, infrastructure becomes part of the product

Kernel, Nijal AI, Qiplim and Arkan address very different needs and are not necessarily at the same stage of development. Their journeys nevertheless illustrate different aspects of the same transition: turning technology into a service that people genuinely use.

As a product finds its users, new constraints emerge. Applications need to remain available, deployments need to be reproducible, data needs to be protected, resources need to scale with usage and teams need to be able to keep shipping quickly.

Infrastructure gradually stops being just a technical concern in the background. It directly contributes to a company’s ability to develop and grow its product.

The challenge is not to spend ever more time operating that infrastructure, but precisely to ensure that it can support growth without distracting teams from their core business.

The UP Programme: turning cloud infrastructure into a growth enabler

This is the stage that Clever Cloud’s UP Programme is designed to support.

Launched in 2024, the programme was created to support technology startups beyond simply providing cloud credits. Its purpose is to give them access to the technical, human and financial resources they need to build their products on cloud infrastructure that can evolve with them.

Selected startups can benefit from:

• up to €10,000 in cloud credits during their first year;
• onboarding onto the Clever Cloud platform and training with our engineers;
• monthly coaching;
• access to Clever Cloud support;
• workshops and masterclasses for technical teams;
• mentoring for founders and their teams;
• visibility through Clever Cloud media, social channels and events;
• tools and resources to support the structuring of their business.

The objective remains the same: enabling teams to focus their energy on their product, users and market rather than on the day-to-day operation of their infrastructure.

Kernel, Nijal AI, Qiplim and Arkan are therefore joining a programme designed to support this pivotal stage: when usage grows, technical requirements evolve and infrastructure needs to keep pace with the product over the long term.

Want to join the next UP Programme cohort?

The next UP Programme selection will take place on 7 January 2027.

Are you building a technology startup and looking for cloud infrastructure that can scale with your product, while benefiting from regular support from Clever Cloud teams?

Discover the UP Programme and apply to join the next cohort.

The episode, titled “We no longer pay developers to write code”, is available on the Underscore_ YouTube channel.

From AI experimentation to industrialization

About 18 months ago, Quentin started seriously experimenting with AI agents for software development. Initially skeptical, he gradually found that they could deliver certain developments faster, sometimes with a better implementation than the one he would have written himself.

But one of the main lessons from Clever Cloud’s experience is precisely that simply giving developers access to an AI tool is not enough. Adoption required changing practices, supporting teams, and even giving up on the idea of imposing a single tool: in a market evolving extremely quickly, developers experiment with different solutions and share what they learn.

When AI also transforms software quality

The focus then shifts from simply generating code to everything required to verify, test, and secure it. Unit and integration tests, distributed systems simulation, automated security audits: AI makes it possible to apply much more systematically practices that already existed but whose time cost sometimes limited their use.

At Clever Cloud, every commit in GitLab can be sent through simulation to look for failures, generate a report, and open an issue when a problem is detected. The question is therefore no longer simply, “How much code can AI produce?” but rather, “What organization and engineering pipeline do we need to build to use this capability in production?”

That is precisely what separates one-off experimentation from industrialization.

Rust, legacy, and new software development practices

The episode also explores Rust’s role in this transformation. Quentin explains why the language’s constraints and the precise feedback provided by its compiler create a particularly effective feedback loop with AI agents.

This approach is now part of a much broader project at Clever Cloud: reducing and ultimately eliminating the legacy accumulated since the company was founded more than 15 years ago, progressively rewriting components while preserving architectural decisions and strengthening their validation.

At the time of recording, Quentin still described eliminating legacy as a work in progress. Since then, this Rust rewrite is now nearly complete.

For a tech company of more than 100 people operating critical infrastructure, this goes far beyond a POC: it means fundamentally changing how software is designed, built, tested, and maintained.

What role is left for developers and CIOs?

This transformation ultimately raises a broader question: what happens to the developer’s role when producing code becomes significantly cheaper?

Quentin argues that value is shifting towards specifications, architecture, testing, and the environment in which software is produced. As a developer himself, he explains that it took him several months to come to terms with this shift.

For CIOs, this experience therefore raises the question of how to integrate AI without simply adding another tool to the stack, by rethinking the processes required to capture its benefits without sacrificing quality or security. This is precisely where Quentin believes companies focusing solely on code generation risk missing a large part of the potential gains.

Ultimately, this may be the main takeaway: the most structural gains emerge when AI leads us to fundamentally rethink how software is designed, built, and evolved. For European companies, the challenge is therefore no longer simply to adopt these tools, but to turn them into a genuine industrial capability.

To watch the full conversation between Quentin Adam, Micode, and Matthieu Lambda:

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 service 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. This approach also suits teams that want to retain direct control over every component of the cluster, from the container runtime to 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 operator’s ownership structure and the legal jurisdictions that apply to it, not simply where the servers are located.

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 service operated by a European company based in France. Beyond location, these offerings differ in their actual degree of sovereignty, which depends on the operator and its subcontracting chain, as well as in how well they integrate with 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. Ultimately, the cloud supplies the infrastructure, Kubernetes orchestrates the workloads running on it, and the managed model determines whether you or the provider operates the cluster.

What remains is to work out when a managed Kubernetes service 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, private or public clouds, and in 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 service (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 de facto standard for container orchestration, 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, monitor them manually, and restart one yourself if it 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 effectiveness of self-healing depends on how well the probes are configured: probes that are too strict cause unnecessary restarts, while probes that are too lenient allow unhealthy containers to remain running.

Service discovery and internal load balancing

In a dynamic container environment, 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. Although it may appear simple, this network layer accounts for much of Kubernetes’ operational complexity, including CNI plugin selection, network policies and 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 introduces an additional operational responsibility beyond the core orchestration functions.

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-based deployment or an application managed by systemd can meet many needs through 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. Poorly configured liveness and readiness probes can undermine both self-healing and traffic routing.

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 or a monitoring tool with automatic restart capabilities can each cover one of these functions 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, making it the de facto standard for distributed systems that require all of them. 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 makes deployment configurations reproducible, easy to version-control in Git and resilient to failures. Second, portability allows the same manifest to work on a development machine, an on-premises cluster or a public cloud. Third, extensibility: the Kubernetes API accepts Custom Resource Definitions (CRDs) and custom controllers (Operators), turning it into a platform for building platforms.This led to the rapid growth of the Kubernetes ecosystem.

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, being hosted by the Linux Foundation rather than controlled by a cloud provider, proved decisive. Competitors risked being marginalised from the emerging cloud-native ecosystem if they did not adopt Kubernetes. 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, Kubernetes had become the established standard.

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. Kubernetes expertise has become highly sought after across DevOps and SRE roles, creating a virtuous cycle: more trained engineers, more companies adopting Kubernetes and more opportunities for engineers to develop these skills.

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 across multi-cloud or hybrid environments combining on-premises infrastructure with public cloud services;
• 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 customer and partner requirements that mandate Kubernetes;
• 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 complex distributed architectures, Kubernetes remains a leading platform, provided that teams account for its operational overhead and decide whether to operate it themselves or use 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.