Introduction

As part of a project of mutual interest between OVHcloud and Sopra Steria, the technical teams of each company joined forces to design the deployment of a Landing Zone. Initially, the project was designed and adapted to the needs of the public sector, to be later expanded to other markets and use cases.

Why a Landing Zone?

Compliance and regulatory requirements

The starting point of the project was very specific: from day one, the Canadian government required a cloud environment that meets very strict sovereignty and security standards. Without a ready-to-use solution, each public client had to spend weeks, if not months, setting up their architecture, drafting procedures, and validating each component with the authorities. This created a bottleneck when projects were initiated.

“The lack of a process to deploy a Landing Zone that was compliant with the requirements of the Canadian public sector was a real roadblock.”

The Landing Zone was designed as a deployment that complies with a regulatory framework: the created infrastructure automatically meets the segmentation, encryption, logging, and access control requirements imposed by authorities. Clients no longer have to worry about how to prove that their environment is compliant; the compliance report is generated simultaneously with the deployment. In fact, this is the whole idea behind the solution.

Accelerating cloud adoption

Once the compliance issue is resolved, the Landing Zone proves to be a true adoption accelerator for all types of clients: startups, SMEs, large accounts, and, of course, governments.

• Automation of best practices: the tools automatically deploy private networks, subnets, firewalls, service accounts, and IAM policies.
• Standardisation: each environment follows the same architectural model, which facilitates maintenance, monitoring, and upgrades.
• Time-to-market: where a manual deployment could take several weeks of work (reading documentation, manually creating resources, compliance testing), the Landing Zone allows for an operational (and compliant) environment in less than an hour.

“In half an hour, you have something ready to use: 30 to 40% of security requirements are already automatically deployed.”

The concrete benefits for technical teams

Time saving and reproducibility

At the core of automating a Landing Zone is Infrastructure as Code (IaC). Terraform (or its fork OpenTofu) orchestrates all OVHcloud services.
Thanks to this model:

• a single script can be executed multiple times, across different accounts or regions, without changing the outcome
• human errors that occur when manually creating resources (typographical errors, configuration oversights, incorrect role assignments) are nearly eliminated
• teams move from tedious configuration to deployment validation, freeing up several days of work for each project

Governance and access management

In addition to the infrastructure, the Landing Zone incorporates a governance model: roles, policies, and safeguards are preconfigured, simplifying access management and revoking rights when someone leaves the company. This layer of abstraction addresses one of the main challenges for IT departments: visibility and control over cloud resources.

Modularity and adaptability to different profiles

The code has been designed to be modular. Three basic profiles are available: “small business”, “medium” and “government”. Each profile activates a tailored set of services in terms of cost, scalability, and compliance requirements. 

The same code base can be extended: if a client from the financial sector requires an HSM encryption module or a certified payment gateway, it is simply a matter of adding the corresponding module and rerunning the script. This flexibility allows you to reuse the same foundation for very different projects, while ensuring compliance and performance guarantees.

A solution that makes a difference

Landing Zone is more than just scripts that create networks and accounts.

It is a comprehensive set of services that covers the entire lifecycle of a cloud project: from strategic reflection to production deployment, and then to daily management administered by the client.

This dual expertise provides coverage for the entire lifecycle: strategy → deployment → operation.

Conclusion

The Landing Zone deployed on OVHcloud infrastructures addresses two major challenges: compliance  for many regulated sectors (particularly public, finance and health) and speed of adoption  for all cloud customers. By automating part of the security requirements, offering ready-to-use governance, and remaining highly modular, it frees up technical teams to focus on their business value.

Are you responsible for a cloud project and looking to reduce your production timelines while ensuring compliance? Contact OVHcloud to find out how a Landing Zone can become the foundation of your digital transformation.

Introduction

Dans le cadre d’un projet d’intérêt commun entre OVHcloud et Sopra Steria, les équipes techniques ont réuni leurs expertises pour concevoir le déploiement d’une Landing Zone (ou « zone d’accueil »). Dans un premier temps, le projet a été conçu et adapté aux exigences du secteur public et pourra ensuite être étendu à d’autres marchés/cas d’usage.

Pourquoi une Landing Zone ?

Conformité et exigences réglementaires

Le point de départ du projet était très concret : le gouvernement canadien exigeait, dès le premier jour, un environnement cloud qui respecte des standards de souveraineté et de sécurité très stricts.

Sans une solution prête à l’emploi, chaque cliente ou client public devait passer des semaines, voire des mois, à mettre en place son architecture, à rédiger des procédures et à valider chaque composant auprès des autorités. Cela engendrait un goulot d’étranglement lors de l’initialisation de projets.

« Le fait de ne pas disposer d’un processus pour déployer une Landing Zone conforme aux exigences du secteur public du Canada était un véritable bloqueur. »

La Landing Zone a été conçue comme un déploiement respectant le cadre réglementaire : l’infrastructure créée répond automatiquement aux exigences de segmentation, de chiffrement, de journalisation et de contrôle d’accès imposées par les autorités. La clientèle n’a donc plus à se soucier de la façon de prouver que son environnement est conforme. Le rapport de conformité est en effet généré en même temps que le déploiement. C’est d’ailleurs là tout l’intérêt de cette solution.

Accélération de l’adoption du cloud

Une fois le problème de conformité résolu, la Landing Zone se révèle un véritable accélérateur d’adoption pour tous types de clientes et clients : startups, PME, grands comptes et, bien sûr, les administrations.

• Automatisation des bonnes pratiques : les outils déploient automatiquement les réseaux privés, les sous-réseaux, les pare-feux, les comptes de service et les politiques IAM.
• Standardisation : chaque environnement suit le même modèle d’architecture, ce qui facilite la maintenance, le monitoring et la montée en charge.
• Time-to-market  : là où un déploiement manuel pouvait prendre plusieurs semaines de travail (lecture de la documentation, création manuelle des ressources, tests de conformité), la Landing Zone permet d’obtenir un environnement opérationnel (et conforme) en moins d’une heure.

« En une demi-heure, vous avez quelque chose de prêt à l’emploi : 30 à 40 % des exigences de sécurité sont déjà déployées automatiquement. »

Les bénéfices concrets pour les équipes techniques

Gain de temps et reproductibilité

Le cœur de l’automatisation d’une Landing Zone repose sur de l’Infrastructure as Code (IaC). Terraform (ou son fork OpenTofu) orchestre l’ensemble des services OVHcloud.
Grâce à ce modèle :

• un même script peut être exécuté plusieurs fois, dans différents comptes ou régions, sans que le résultat change ;
• les erreurs humaines liées à la création manuelle de ressources (erreurs de typographie, oublis de configuration, mauvaise attribution de rôle) sont quasiment éliminées ;
• les équipes passent de la configuration fastidieuse à la validation du déploiement, libérant ainsi plusieurs jours de travail par projet.

Gouvernance et gestion des accès

Outre l’infrastructure, la Landing Zone intègre un modèle de gouvernance : rôles, politiques et garde-fous sont préconfigurés, ce qui simplifie la gestion des accès et la révocation des droits lorsqu’une personne quitte l’entreprise. Cette couche d’abstraction répond à l’une des principales difficultés des DSI : la visibilité et le contrôle sur les ressources cloud.

Modularité et adaptabilité aux différents profils

Le code a été pensé pour être modulaire. Trois profils de base sont proposés : « small business », « medium »et « government ». Chaque profil active un jeu de services adapté (coût, évolutivité, exigences de conformité). 

Le même socle de code peut être étendu : si un client ou une cliente du secteur financier a besoin d’un module de chiffrement HSM ou d’une passerelle de paiement certifiée, il suffit d’ajouter le module correspondant et de relancer le script. Cette flexibilité permet de réutiliser la même base pour des projets très différents, tout en conservant la garantie de conformité et de performance.

Une solution qui fait la différence

Lorsque l’on parle de Landing Zone, on ne parle pas seulement de scripts qui créent des réseaux et des comptes.

Il s’agit d’un ensemble complet de services qui couvre tout le cycle de vie d’un projet cloud : de la réflexion stratégique à la mise en production, puis à la gestion quotidienne opérée par le ou la cliente.

Cette double expertise permet de couvrir l’ensemble du cycle de vie : stratégie → déploiement → exploitation.

Conclusion

La Landing Zone déployée sur les infrastructures OVHcloud répond à deux enjeux majeurs : la conformité pour de nombreux secteurs réglementés (notamment public, financier et de santé) et la rapidité d’adoption pour l’ensemble des clientes et clients du cloud. En automatisant une partie des exigences de sécurité, en offrant une gouvernance prête à l’emploi et en restant hautement modulaire, elle libère les équipes techniques pour leur permettre de se concentrer sur leur valeur métier.

Vous êtes responsable d’un projet cloud et vous cherchez à réduire vos délais de mise en production tout en garantissant la conformité ? Contactez OVHcloud pour découvrir comment la Landing Zone peut devenir le socle de votre transformation numérique.

Building a real-time data pipeline used to mean months of infrastructure work. Here is what the modern stack looks like in 2026.

Your database is doing its job. It records every transaction, every event, every state change your application produces. The data is reliable, consistent, and safely stored.

But a database is a starting point, not a destination. The question is what happens after the write. Does that data stay in storage, answering application queries, while the insights it could generate stay locked in place? Or does it flow downstream, in real time, to the systems built to make sense of it?

Building that downstream pipeline used to be a serious infrastructure project. Kafka clusters to provision and tune, ZooKeeper ensembles to manage, connectors to configure, sinks to wire up, and a schema registry to operate. A team could spend weeks on the scaffolding before the first event reached an analytics engine.

In 2026, the pipeline architecture has not changed. But the operational weight has. Managed services handle provisioning, replication, failover, and upgrades. What used to take a dedicated platform team now takes an afternoon. This article walks through what a complete real-time data pipeline looks like, how each layer connects, and what it takes to build one without building the infrastructure underneath it.

The four layers

A modern real-time data pipeline has four layers. Each has a distinct job, and none of them are optional if you want data to move continuously from storage to insight.

Storage

Where your data originates. A relational database like PostgreSQL handles transactions, enforces consistency, and serves your application. It is your source of truth. Every insert, update, and delete is recorded with precision. That write log is also the starting point for everything downstream.

Streaming

How data moves. Apache Kafka captures changes from your database the moment they happen and distributes them to downstream consumers as events. Every row-level modification becomes a structured message that other systems can act on in real time. Kafka’s core design principle is decoupling: producers write events without knowing who will consume them, and consumers read events without touching the source system. This means you can add new downstream use cases – a new analytics engine, a new alerting system, a new data warehouse – without modifying the database or the application above it.

Analytics

Where data becomes answers. Two distinct engines cover the two main post-storage use cases. ClickHouse handles OLAP workloads: fast columnar queries, real-time aggregations, time-series analysis, and dashboards over millions of rows per second. OpenSearch handles full-text search, log analytics, and observability: complex queries across weeks of event data, anomaly detection, distributed tracing, and alert rules over live event streams. Both engines are designed for reads at scale, not for transactional consistency: this is exactly the trade-off you want after Kafka.

Visualisation

How the answers reach people. Grafana connects to both ClickHouse and OpenSearch, pulling from live data to power dashboards, alert panels, and operational monitors. It is the layer that makes the pipeline visible across the organisation – to the product team checking feature adoption, to the security team watching for anomalies, and the platform team tracking infrastructure health.

Two paths through the same architecture

The topology is consistent regardless of your use case: source database, Kafka as the streaming backbone, one or both analytics engines, and Grafana on top. How you build it depends on what your team needs first.

The real-time analytics path

PostgreSQL + Kafka + ClickHouse + Grafana is the right starting point when the primary need is fast, flexible querying. Product analytics, business intelligence, time-series reporting, funnel analysis, A/B test results in real time: these all call for ClickHouse. It ingests directly from Kafka topics, materialises views that dashboards query in milliseconds, and handles aggregations over hundreds of millions of rows without breaking a sweat. The SaaS company that needs to see feature adoption as it happens, the fintech tracking transaction volumes by the minute, the e-commerce platform running live inventory analytics – these all follow this same path.

The search and observability path

PostgreSQL + Kafka + OpenSearch + Grafana is the right starting point when the primary need is full-text search, log aggregation, or system-wide observability. OpenSearch indexes events as they arrive, enabling complex searches across months of structured and semi-structured data with sub-second response times. The security team correlating events across distributed services, the platform team centralising logs from dozens of microservices, the SRE team building alerts on top of live event streams – these all follow this path.

How the data moves

The connection between your database and Kafka starts with change data capture. CDC is the mechanism that reads your database’s internal write log and turns each modification into a stream of structured events.

In PostgreSQL, this works through logical replication. The write-ahead log records every change made to the database, at the row level. With logical replication enabled, a connector can read that log and emit each change as a structured event with the full before and after state of the row. Kafka Connect is the integration layer that runs these connectors. Debezium, configured as a source connector within Kafka Connect, reads the PostgreSQL WAL and publishes each change to a dedicated Kafka topic. From there, sink connectors route events to ClickHouse, OpenSearch, or both.

One technical development worth understanding for anyone building on Kafka in 2026: Kafka 4.0 removes ZooKeeper entirely. ZooKeeper was the external service Kafka relied on to manage cluster metadata, leader election, and coordination. It was a separate system to deploy, configure, monitor, and upgrade alongside the Kafka brokers. Kafka 4.0 replaces it with KRaft, Kafka’s native Raft-based consensus protocol. Cluster metadata is now managed internally by Kafka itself. The result is a single, self-contained system with fewer components, fewer failure modes, and faster recovery. For anyone who operated a Kafka cluster under the ZooKeeper model, this is a material simplification. For anyone running Kafka as a managed service, the transition is mostly invisible: what you get is a faster, more resilient cluster with one less operational surface.

OpenSearch 3.0 is also a meaningful release for anyone building observability pipelines. The upgrade to Apache Lucene 10 delivers up to 60 per cent lower search latency, with the largest gains on vector search, KNN, and neural search workloads. Star-tree indexing reduces query work for heavy aggregations by up to 100 times. And OpenSearch 3.0 adds native MCP protocol support, which means it integrates directly with AI agents and LLM-based tooling. For teams building observability pipelines that feed into AI-driven incident investigation or alerting workflows, this is a capability that was unavailable even twelve months ago.

Why managed matters

The first thing most teams underestimate about this stack is not the initial setup: it is the ongoing operational surface.

On Kafka, the harder work starts after launch. Partition leader rebalancing when a broker restarts under load. KRaft controller quorum recovery after a node failure. Consumer group offset management when a sink connector falls behind and you need to replay events without duplicating records downstream. JVM heap tuning as throughput grows. Connector worker restart policies that do not lose in-flight events. On OpenSearch, add shard allocation decisions during cluster scaling, index lifecycle management policies to control storage costs as event volumes grow, and JVM tuning for the ML nodes that power vector and neural search. On ClickHouse, merge tree settings and partition pruning strategy matter from day one: getting these wrong early means rewriting table schemas under load.

Managed services absorb this operational surface. Rolling upgrades run without downtime because the service handles leader migration before taking a node offline. Connector workers are monitored and restarted automatically. Failover is handled at the infrastructure level across availability zones. Index lifecycle policies are configurable through the console rather than through manually applied configuration files. Analytics engineers already spend up to 40 per cent of their time on infrastructure maintenance rather than delivering insights. The managed services model moves that complexity to a layer you do not have to own.

For teams in Europe, there is a second dimension. Hyperscaler deployments in EU regions run on infrastructure governed by U.S. law, which means the legal framework around who can access your data, and under what circumstances, is not straightforward. Running on OVHcloud means the infrastructure is European, operational control is European, and the jurisdiction governing data access is unambiguous. For teams in regulated industries, or for any team that fields GDPR compliance questions from customers or auditors, that is a material difference from a cloud region that happens to be located in Europe.

Pricing is the third dimension. Hyperscaler bills can be opaque: data transfer costs between services, storage billed separately from compute, egress fees that compound as event volumes grow. OVHcloud pricing includes IOPS, traffic, and backups. You see the cost before you provision. There are no surprises when your Kafka throughput increases.

Building it on OVHcloud

OVHcloud runs all four layers as managed services, deployed and monitored from a single console.

Provision Managed Kafka, pick your region, and your cluster is ready in minutes. Kafka 4.0 with KRaft means no ZooKeeper to configure or monitor. Add Managed Kafka Connect and configure your PostgreSQL source connector, with optional Debezium CDC for full row-level change capture. Then provision Managed ClickHouse and add a sink connector to start routing events from your Kafka topics into ClickHouse tables, or provision Managed OpenSearch and route events there instead. Add Managed Grafana to connect to both engines and begin building dashboards on live data.

The full stack is five managed services on one platform: PostgreSQL, Kafka, ClickHouse or OpenSearch (or both), and Grafana. One console for provisioning and monitoring. One bill. One support team that understands the full pipeline, not just individual components in isolation.

Start with one layer

You do not have to build the whole pipeline on day one. The most common starting point is Kafka: get your data flowing before you decide where it is going. Once events are moving through Kafka topics, adding ClickHouse or OpenSearch is a connector configuration, not a re-architecture.

The pipeline you build this way is modular by design. Each layer adds independent value. The team that starts with Kafka and adds ClickHouse six months later has not wasted anything in between. The Kafka layer was already doing its job. The pipeline grew without disrupting what was already working.

The infrastructure is managed. The data stays in your hands. The pricing is transparent. The pipeline you need already exists on one stack.

Explore the OVHcloud managed data pipeline

Software supply chains have become more complex and increasingly targeted, making container image security a fundamental requirement for building trust in modern delivery pipelines.

By signing images with Cosign and protecting signing keys in OVHcloud KMS, teams can keep cryptographic material out of local environments and CI/CD variables, all while making image signing easier to control, audit and integrate into delivery pipelines.

In this blog post, you will learn how to use the OVHcloud KMS plugin for Cosign to generate a key, sign a container image with this key and verify that the OCI image has been correctly signed.

Cosign

Cosign is a tool from the Sigstore project used to sign, verify, and attest OCI container images and software artifacts.

Cosign supports several signing modes, including keyless signing through Sigstore, where short-lived certificates are generated at signing time based on your identity (via GitHub, Google or another OIDC provider), as well as ephemeral key generation, hardware and KMS-backed signing and custom PKI integration.

Cosign supports multiple KMS providers to generate and sign keys. Several external KMS providers are supported, including HashiCorp Vault, AWS KMS, GCP KMS and Azure Key Vault.
Cosign can now also be integrated with OVHcloud KMS through the Sigstore Cosign OVHcloud KMS plugin 💪.

OVHcloud Key Management Service (KMS)

OVHcloud KMS, often called OKMS, is a managed service that centralizes the creation, storage, and management of encryption keys. Its main goal is to help businesses secure data and control cryptographic operations from a single platform.

Each KMS is associated with a region, so the keys stored in that region are guaranteed to stay in that region. You can order multiple KMSs, either in different regions or in the same region.

Prerequisites

To be able to use the Sigstore KMS OVHcloud provider, you need to follow some prerequisites:

• Have an OVHcloud account
• Have created an OKMS domain (“305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have created an IAM local user (“cosign-305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have installed the OVHcloud CLI
• Have uuidgen CLI installed

💡The cosign OVHcloud plugin supports both token and mTLS authentication. For the purposes of this blog post, we will use the token authentication mode. Please follow the Sigstore Cosign KMS plugin for OVHcloud guide if you wish to use mTLS authentication mode.

Generate a PAT token (for token authentication only)

List the OKMS domains:

$ ovhcloud okms list
┌──────────────────────────────────────┬─────────────┐
│                  id                  │   region    │
├──────────────────────────────────────┼─────────────┤
│ 305db938-1234-5678-9012-3a0a29291661 │ eu-west-par │
│ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │ eu-west-par │
└──────────────────────────────────────┴─────────────┘

Save the OKMS ID in an environment variable:

export KMS_RESTAPI_OKMSID="305db938-1234-5678-9012-3a0a29291661"

The cosign OVHcloud plugin needs the permission to create and fetch keys from the OVHcloud KMS.

If you want to use token autentication, you’ll need a token (PAT). You can use the ovhcloud CLI to do that:

PAT_TOKEN=$(ovhcloud iam user token create <iam-local-user-name> --name pat-<iam-local-user-name> --description "PAT cosign for domain $KMS_RESTAPI_OKMSID" -o json  | jq .details.token |  tr -d '"')

echo $PAT_TOKEN

You should have a result like this:

$ PAT_TOKEN=$(ovhcloud iam user token create cosign-305db938-1234-5678-9012-3a0a29291661 --name pat-cosign-305db938-1234-5678-9012-3a0a29291661 --description "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661" -o json  | jq .details.token |  tr -d '"')
2026/05/07 08:48:34 Final parameters:
{
 "description": "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661",
 "name": "pat-cosign-305db938-1234-5678-9012-3a0a29291661"
}

$ echo $PAT_TOKEN
eyJhbGciOiJFZE...ASgXy55_DDFHdy4Z5uSq8lww-Bw

Save the KMS information

Save the KMS information in environment variables. For example:

export KMS_RESTAPI_ENDPOINT=$(ovhcloud okms get $KMS_RESTAPI_OKMSID -o json | jq .restEndpoint | xargs)
export KMS_RESTAPI_TYPE="token"
export KMS_RESTAPI_TOKEN=$PAT_TOKEN

Display the saved information:

$ echo $KMS_RESTAPI_ENDPOINT
https://eu-west-par.okms.ovh.net

$ echo $KMS_RESTAPI_OKMSID
305db938-1234-5678-9012-3a0a29291661

$ echo $KMS_RESTAPI_TYPE
token

$ echo $KMS_RESTAPI_TOKEN
eyJ...BIoHCA

Cosign KMS plugin installation

Install the plugin locally:

curl -fsSL https://raw.githubusercontent.com/ovh/sigstore-kms-ovhcloud/main/install.sh | sh

⚠️ The binary is installed in $HOME/.local/bin by default (created if it does not exist). Make sure this directory is in your PATH.

Or follow the other installation methods.

Now you can use the OVHcloud KMS plugin directly in the cosign command 🎉.

Let’s use Cosign with the OVHcloud KMS!

Generate a key

First, to sign an image, we need to generate a key pair. To do that we need to generate a UUID and use it in the cosign generate-key-pair command.

export KEY_ID=$(uuidgen)
cosign generate-key-pair --kms ovhcloud://$KEY_ID

The signing key is created in OVHcloud KMS, and the public key is written locally.

You should see an output like this:

$ export KEY_ID=$(uuidgen)
$ cosign generate-key-pair --kms ovhcloud://$KEY_ID

Public key written to cosign.pub

The command generates a key pair using the ECDSA algorithm and writes the public key to cosign.pub.

Check the keys have been created:

$ ls -l cosign.pub
-rw-------  1 avache  staff  178 18 juin  16:06 cosign.pub

$ cat cosign.pub

-----BEGIN PUBLIC KEY-----
MFkw...QgwA==
-----END PUBLIC KEY-----

Once the key pair has been generated, use the corresponding OVHcloud KMS key ID in the ovhcloud://$KEY_ID URI when signing and verifying images.

Or get an existing public key (optional)

Instead of creating a new public key, you can retrieve an existing one with the following command:

cosign public-key --key ovhcloud://$KEY_ID --outfile cosign-ovhcloud.pub

Sign an image

Replace the $IMAGE@sha256:$HASH parameter with the URI to your image and the hash to your image and execute this command:

cosign sign --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign sign --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verify the image has been signed

cosign verify --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign verify --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verification for 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},"image":{"docker-manifest-digest":"sha256:b1202...2334e2"},"type":"https://sigstore.dev/cosign/sign/v1"},"optional":{}}]

Conclusion

In this blog post, we have shown how to use Cosign with the OVHcloud KMS plugin to generate a key pair, sign a container image and verify its signature.

By keeping signing keys in a managed KMS, teams can reduce secret sprawl, protect sensitive cryptographic material and make image signing easier to integrate into secure CI/CD workflows.

Feel free to take a look at our Cloud Roadmap & Changelog to follow the latest features coming to OVHcloud Public Cloud products.

Most managed database users stop at storage. Here’s how to complete the pipeline with streaming and analytics, all from one console.

You picked a managed database for the right reasons. No patching, no replication headaches, no 3 a.m. pages about a failed backup. Your PostgreSQL, MySQL or MongoDB cluster runs, stores, and serves. It does exactly what you asked.

But here is the thing: storing data and understanding data are two different jobs. And right now, roughly nine out of ten managed database customers at OVHcloud stop at storage. They run rock-solid operational databases yet never connect them to a streaming or analytics layer. The data sits there, doing its job, answering application queries, serving the API, while the insights it could generate stay locked inside. No streaming. No real-time analytics. No search across logs or events. Just storage.

That is the missing half.

The gap between storage and insight

Most teams hit this wall at some point. The application database handles transactions, serves the API, keeps the frontend alive. Then someone asks a question the database was never designed to answer. “What are customers doing right now?” “Which features are driving retention this week?” “Can we detect anomalies before they become incidents?”

The reflex is to run analytical queries directly on the production database. It works, briefly, until those queries start competing with the application for resources. Response times creep up, the ops team starts throttling reports, and the data team ends up with a spreadsheet export and a frustrated expression.

The real problem is not the database. It is the absence of everything after it: a streaming layer to move data in real time, and an analytical engine purpose-built for fast, flexible queries. Without those two pieces, the pipeline stops at storage.

What a complete pipeline looks like

A modern data pipeline has three layers, each doing what it does best.

Storage

What you already have. Your managed PostgreSQL, MySQL, or MongoDB handles transactions, enforces consistency, and serves your application. It is your source of truth.

Streaming

The bridge. Apache Kafka captures changes from your database the moment they happen and distributes them to downstream consumers. For teams that need a full change data capture, Debezium can be configured through Kafka Connect, a process we will cover later. Instead of batch exports or nightly ETL jobs, your data flows continuously. Every insert, update, and delete becomes an event that other systems can act on in real time. Kafka is not just a transport layer: it decouples your producers from your consumers, which means you can add new downstream use cases without touching anything upstream.

Analytics

Where data becomes answers. ClickHouse processes millions of rows per second for OLAP workloads: dashboards, aggregations, time-series analysis. OpenSearch handles full-text search, log analytics, and observability. Together, they cover the two big post-storage use cases: structured analytics and unstructured search.

Each layer is independent but connected. Your production database stays lean because it is not fielding analytical queries. The analytics engines are optimised for reads at scale, not for transactional consistency, which is exactly the trade-off you want.

This architecture scales in stages. You do not have to build the entire pipeline on day one. Start with Kafka to get your data flowing, then add ClickHouse or OpenSearch when the use case demands it. Each layer adds value without disrupting what came before. That modularity matters, because most teams do not need everything at once. They need the next piece.

How the pieces connect on OVHcloud

OVHcloud offers all three layers as managed services, deployed and operated from the same console.

Start with your existing managed database. Connect Managed Kafka through the OVHcloud console in a few clicks, then add Managed Kafka Connect as the integration layer. Kafka Connect handles the mechanics of pulling change events out of your database and pushing them into Kafka topics. From there, you route events to Managed ClickHouse for analytical queries, Managed OpenSearch for search and observability, or both.

For teams that want to go further, Debezium can be configured on top of Kafka Connect to implement full change data capture (CDC). This means every row-level change in your database is captured as a structured event, preserving the complete history of modifications. Debezium runs as a connector within Kafka Connect, so the infrastructure is already in place.

What you get at the end is a complete pipeline: source of truth, real-time streaming, and fast analytics. All managed. One console for provisioning and monitoring. One bill. One support team that understands the full stack.

When your database, streaming layer, and analytics engines are scattered across different providers, debugging a broken pipeline means opening three dashboards, contacting three support teams, and reconciling three billing cycles. With OVHcloud, the whole chain lives in one place.

What this looks like in practice

Product analytics at a SaaS scaleup

A B2B SaaS company needs to understand how customers use their product in real time. Their managed PostgreSQL database records every user action, but running analytical queries on it directly means competing with the application for resources. Whenever the data team runs a report, response times start spiking.

They add Managed Kafka to capture database change events as they happen, then configure Kafka Connect to route them to Managed ClickHouse. ClickHouse ingests the stream and pre-aggregates it into the materialised views their dashboards need. The product team now sees feature adoption, session lengths, and funnel conversions updated in seconds, not hours, without any additional load on the production database.

New analytical use cases – such as cohort analysis or A/B test reporting – are added as new Kafka consumers without any changes to the application or the source database. The implemented architecture enables the pipeline to grow without touching what already works.

Observability at a cybersecurity scaleup

A cybersecurity company analyses millions of events per day across its platform. Detecting anomalies means searching across weeks of structured and semi-structured data with sub-second response times. Their PostgreSQL operational database stores event metadata reliably, but it was never designed for full-text search at this volume.

Managed Kafka streams event data as it is written to the database, routing it to Managed OpenSearch. OpenSearch indexes everything in real time. The security team can now run complex searches across months of data in milliseconds, set alerts on anomaly patterns, and correlate events across distributed services from a single dashboard.

No separate log management vendor. No data egress fees between services. And because the data never leaves OVHcloud infrastructure, there is no question about where it sits or who can access it.

Why it matters that it is managed (and European)

You chose a managed database because you did not want to babysit infrastructure. The same logic applies to streaming and analytics. Self-hosting Kafka is notoriously complex: broker management, partition rebalancing, schema registries, monitoring, upgrades. ClickHouse and OpenSearch have their own operational weight.

Analytics engineers already spend up to 40% of their time maintaining infrastructure[1] instead of delivering insights. Managed services flip that ratio. With OVHcloud, rolling upgrades run with zero downtime. Automated failover covers availability zones. End-to-end encryption, ISO 27001 and SOC 2 compliance, and a 99.99% SLA are included, not extras.

And because this is OVHcloud, your data remains your data. No extraterritorial exposure, no ambiguity about which jurisdiction governs your data. For teams operating under GDPR or working in regulated industries, this is not a nice-to-have. It is a requirement.

Pricing is transparent and predictable. No data-transfer surcharges between services, no opaque consumption-based billing that spikes when your analytics workload grows. IOPS, traffic and backups are included.

There is also the question of open-source compatibility. Every engine in the OVHcloud managed pipeline runs the real open-source project: Apache Kafka, ClickHouse, OpenSearch. No proprietary forks, no API incompatibilities, no vendor lock-in. Your code, your connectors, and your tooling all work the same way they would against a self-hosted cluster.

Getting started

If you already have a managed database on OVHcloud, the fastest path to a complete pipeline is:

1. Provision Managed Kafka from the OVHcloud console. Choose your plan, pick your region, and your cluster is ready in minutes.
2. Add Managed Kafka Connect and configure a source connector pointing to your database. This is where your change events start flowing.
3. Spin up Managed ClickHouse (for analytics) or Managed OpenSearch (for search and observability), or both, depending on your use case.
4. Configure sink connectors in Kafka Connect to route events from your Kafka topics into your analytics engines.
5. Query your data. ClickHouse speaks SQL, so your existing BI tools and dashboards plug right in. OpenSearch provides its own dashboards for log exploration and search.

The entire setup can be done from the console, with each service connected through the same management interface. No VPN tunnels to configure between providers, no credential juggling across platforms. For teams comfortable with infrastructure as code, Terraform and the OVHcloud API cover the same ground programmatically.

If you want to explore CDC with Debezium, the Kafka Connect foundation is already there. You configure Debezium as a source connector, and it starts capturing row-level changes from your database into Kafka topics. The managed Kafka Connect infrastructure handles running and scaling the connector itself.

Your database is doing its job. Now to complete the picture.

Nine out of ten managed database customers have not connected their data to streaming or analytics. The operational half works. The insight half is waiting.

The tools are managed, the console is unified, and the pipeline pattern is proven. If you are ready to see what your data can tell you, the missing half is a few clicks away.

Get started with Managed Kafka on OVHcloud

[1] Source: McKinsey: https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity

If you find yourself in need of shared persistent storage for applications running on OVHcloud Managed Kubernetes Service (MKS), then OVHcloud Enterprise File Storage (EFS) with Trident CSI offers you a practical way to provision and manage it.

This blog post explains how to create and connect OVHcloud EFS to your MKS cluster using Trident CSI, so you can dynamically provision persistent storage for Kubernetes workloads.

OVHcloud Enterprise File System (EFS)

EFS is a high-performance, fully managed file storage solution powered by NetApp ONTAP in an active-active architecture. It is designed for enterprise workloads requiring high availability, predictable performance, and seamless integration with cloud-native environments.

The service is available in multiple regions, including Roubaix, Gravelines, Strasbourg, Limbourg, and Beauharnois, with a strong SLA of 99.99% uptime. Storage capacity ranges from 50 GB up to 29 TB.

EFS delivers guaranteed performance with 4,000 IOPS and 64 MB/s throughput per TiB, scaling linearly with volume size thanks to NVMe SSD infrastructure.

Built for modern infrastructures, EFS integrates natively with Kubernetes via Trident CSI (compatible with MKS) and supports ReadWriteMany (RWX) access. It operates within a single availability zone (1AZ) and provides low-latency NFS storage over OVHcloud’s secure vRack network, ensuring strong security and compliance.

NetApp Trident CSI

Trident is an open-source, fully supported storage orchestration project maintained by NetApp. It is designed to help Kubernetes applications consume persistent storage using standard interfaces such as the Container Storage Interface (CSI).

Trident runs directly inside Kubernetes clusters as a set of Pods and enables dynamic provisioning and management of storage for containerized workloads. It allows applications to easily access persistent storage from NetApp’s ecosystem, including ONTAP systems (like the OVHcloud EFS).

Let’s do it!

EFS creation

We already have a MKS cluster, in GRA11 region, running inside a private network and a subnet, with a gateway.
We also already have a vRack and our Public Cloud Project attached to this vRack.
So in this blog post we will only create a new EFS in eu-west-rbx region, attached to a vRackServices, inside the same subnet that our existing MKS cluster.

Here you can see the architecture of all the services:

⚠️ EFS and MKS regions may differ; be aware that latency between different regions may impact your storage workloads performance. It’s highly recommended to keep your storage and compute as close as possible.

We will deploy the EFS in eu-west-rbx instead of in eu-west-gra region to show you that it is possible.

To deploy the EFS, we will use the Terraform OVHcloud EFS module.

The module we will use can deploy all the components necessary to use EFS with a MKS cluster (like you can see in the schema).

But in this blog post we will assume that we already deployed:

• a vRack
• a Private Network
• a Private Subnet
• a Gateway
• a MKS cluster

So using the Terraform module we will fill the existing resources information and ask Terraform to create:

• an OAuth2 credential
• an IAM policy
• an EFS
• a vRack Services

Let’s deploy our components with Terraform!

Create a provider.tf file and fill it with the information:

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = ">= 2.12.0"
    }
    null = {
      source  = "hashicorp/null"
      version = ">= 3.0.0"
    }
  }

  required_version = ">= 1.7.0"
}

provider "ovh" {
}

If you don’t define the provider information inside this file, as was shown in this example, you can instead set the environment variables with your credentials:

# OVHcloud provider needed keys
export OVH_ENDPOINT="ovh-eu"
export OVH_APPLICATION_KEY="xxx"
export OVH_APPLICATION_SECRET="xxx"
export OVH_CONSUMER_KEY="xxx"
export OVH_CLOUD_PROJECT_SERVICE="xxx"

Create a variable.tf.template file and fill it with these information:

# Existing services
variable "service_name" {
  default = "$OVH_CLOUD_PROJECT_SERVICE"
}

variable "vrack_id" {
  default = "pn-1234567" #ID of your existing vRack
}

variable "vlan_id" {
  default = "666" #ID of your VLAN
}

variable "private_network_id" {
  default = "d111cb65-1234-5678-9012-dac2e93b8944" #ID of your private network
}

variable "private_subnet_id" {
  default = "d8dc2469-1234-5678-9012-1f86551d3466" #ID of your subnet
}

variable "vrackservices_subnet_service_range_cidr" {
  default = "192.168.168.248/29" #CIDR of your private network
}

variable "private_subnet_cidr" {
  default = "192.168.168.0/24" #CIDR of your subnet
} 

variable "mks_region" {
  default = "GRA11" #Region of your existing MKS cluster
}

variable "mks_cluster_id" {
  default = "7c3e1e6e-1234-5678-9012-4fb5a5b145e7" #ID of your existing MKS cluster
}

# Services to create

variable "oauth2_client_name" {
  default = "efs-trident-client-example"
}

variable "oauth2_client_description" {
  default = "OAuth2 client for EFS Trident integration"
}

variable "iam_policy_name" {
  default = "efs-trident-policy-example"
}

variable "iam_policy_description" {
  default = "IAM policy for EFS Trident access"
}

variable "vrackservices_attach_to_efs" {
  description = "Whether to attach the EFS service endpoint to vRack Services. Set to false before destroying."
  type        = bool
  default     = true
}

variable "efs_region" {
  default = "eu-west-rbx"
}

variable "efs_name" {
  default = "my-efs-storage"
}

variable "efs_plan" {
  default = "enterprise-file-storage-premium-1tb"
}

⚠️ In the file, replace the IDs, CIDR & MKS region with your existing resources information.

Replace the value of the OVH_CLOUD_PROJECT_SERVICE environment variable in the variables.tf file:

envsubst < variables.tf.template > variables.tf

Create a efs.tf file and fill it with the information:

module "ovh_efs_trident" {
  source = "ovh/efs/ovh//modules/efs-trident"

  # OVH region for EFS and vRack Services
  region = var.efs_region

  # Public Cloud region for MKS and private network
  public_cloud_region = var.mks_region

  # VLAN ID must be the same for vRack Services and Public Cloud private network
  vlan_id = var.vlan_id

  # Set to false before destroying to detach endpoint first
  vrackservices_attach_to_efs = var.vrackservices_attach_to_efs

  # EFS creation
  storage_efs_name      = var.efs_name
  storage_efs_plan_code = var.efs_plan

  # --- vRack ---
  create_vrack       = false
  vrack_service_name = var.vrack_id

  # --- Cloud Project ---
  create_cloud_project        = false
  cloud_project_id            = var.service_name
  bind_vrack_to_cloud_project = false # Set to false if already bound

  # --- Private Network ---
  create_private_network      = false
  private_network_id = var.private_network_id

  # --- Private Subnet ---
  create_private_subnet      = false
  private_subnet_id = var.private_subnet_id

  # --- Gateway ---
  create_gateway = false  # Set to false only if existing network has gateway

  # --- MKS Cluster ---
  create_mks_cluster = false
  mks_cluster_id     = var.mks_cluster_id # mks-priv-gra11
  create_node_pool   = false # Set to false if using existing node pool

  # OAuth2 and IAM
  oauth2_client_name        = var.oauth2_client_name
  oauth2_client_description = var.oauth2_client_description
  iam_policy_name           = var.iam_policy_name
  iam_policy_description    = var.iam_policy_description

  # Network (shared between vRack Services and Public Cloud)
  private_network_subnet_cidr             = var.private_subnet_cidr
  vrackservices_subnet_service_range_cidr = var.vrackservices_subnet_service_range_cidr # EFS gets IPs here
}

Create an output.tf file with the following content:

output "client_id" {
    value = module.ovh_efs_trident.client_id
}

output "client_secret" {
    value = module.ovh_efs_trident.client_secret
    sensitive = true
}

output "efs_id" {
  value       = module.ovh_efs_trident.efs_id
}

The Terraform configuration is ready. Let’s init it:

terraform init

The output should be like this:

$ terraform init

Initializing the backend...
Initializing modules...
Initializing provider plugins...
- Reusing previous version of hashicorp/null from the dependency lock file
- Reusing previous version of ovh/ovh from the dependency lock file
- Using previously-installed hashicorp/null v3.2.4
- Using previously-installed ovh/ovh v2.13.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Apply it:

terraform apply

The output should be like this:

$ terraform apply

module.ovh_efs_trident.data.ovh_me.my_account: Reading...
module.ovh_efs_trident.data.ovh_cloud_project_kube.existing[0]: Reading...
module.ovh_efs_trident.data.ovh_cloud_project.existing[0]: Reading...
module.ovh_efs_trident.data.ovh_me.my_account: Read complete after 1s [id=xx12345-ovh]
module.ovh_efs_trident.data.ovh_cloud_project.existing[0]: Read complete after 0s
module.ovh_efs_trident.data.ovh_order_cart.cart: Reading...
module.ovh_efs_trident.data.ovh_order_cart.cart: Read complete after 0s [id=d582ab7c-1234-5678-9012-4a6e702ea4c5]
module.ovh_efs_trident.data.ovh_cloud_project_kube.existing[0]: Read complete after 5s [id=7c3e1e6e-1234-5678-9012-4fb5a5b145e7]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # module.ovh_efs_trident.null_resource.config_validation will be created
  + resource "null_resource" "config_validation" {
      + id = (known after apply)
    }

  # module.ovh_efs_trident.ovh_iam_policy.iam_policy will be created
  + resource "ovh_iam_policy" "iam_policy" {
      + allow       = [
          + "storageNetApp:apiovh:get",
          + "storageNetApp:apiovh:serviceInfos/get",
          + "storageNetApp:apiovh:share/accessPath/get",
          + "storageNetApp:apiovh:share/acl/create",
          + "storageNetApp:apiovh:share/acl/delete",
          + "storageNetApp:apiovh:share/acl/get",
          + "storageNetApp:apiovh:share/create",
          + "storageNetApp:apiovh:share/delete",
          + "storageNetApp:apiovh:share/edit",
          + "storageNetApp:apiovh:share/extend",
          + "storageNetApp:apiovh:share/get",
          + "storageNetApp:apiovh:share/revertToSnapshot",
          + "storageNetApp:apiovh:share/snapshot/create",
          + "storageNetApp:apiovh:share/snapshot/delete",
          + "storageNetApp:apiovh:share/snapshot/edit",
          + "storageNetApp:apiovh:share/snapshot/get",
        ]
      + created_at  = (known after apply)
      + description = "IAM policy for EFS Trident access"
      + id          = (known after apply)
      + identities  = (known after apply)
      + name        = "efs-trident-policy-example"
      + owner       = (known after apply)
      + read_only   = (known after apply)
      + resources   = (known after apply)
      + updated_at  = (known after apply)
    }

  # module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client will be created
  + resource "ovh_me_api_oauth2_client" "api_oauth2_client" {
      + client_id     = (known after apply)
      + client_secret = (sensitive value)
      + description   = "OAuth2 client for EFS Trident integration"
      + flow          = "CLIENT_CREDENTIALS"
      + id            = (known after apply)
      + identity      = (known after apply)
      + name          = "efs-trident-client-example"
    }

  # module.ovh_efs_trident.ovh_storage_efs.efs[0] will be created
  + resource "ovh_storage_efs" "efs" {
      + created_at        = (known after apply)
      + iam               = (known after apply)
      + id                = (known after apply)
      + name              = "my-efs-storage"
      + order             = (known after apply)
      + ovh_subsidiary    = "FR"
      + performance_level = (known after apply)
      + plan              = [
          + {
              + configuration = [
                  + {
                      + label = "region"
                      + value = "eu-west-rbx"
                    },
                  + {
                      + label = "network"
                      + value = "vrack"
                    },
                ]
              + duration      = "P1M"
              + plan_code     = "enterprise-file-storage-premium-1tb"
              + pricing_mode  = "default"
            },
        ]
      + product           = (known after apply)
      + quota             = (known after apply)
      + region            = (known after apply)
      + service_name      = (known after apply)
      + status            = (known after apply)
    }

  # module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0] will be created
  + resource "ovh_vrack_vrackservices" "vrack-vrackservices-binding" {
      + id             = (known after apply)
      + service_name   = "pn-1234567"
      + vrack_services = (known after apply)
    }

  # module.ovh_efs_trident.ovh_vrackservices.vrackservices[0] will be created
  + resource "ovh_vrackservices" "vrackservices" {
      + checksum        = (known after apply)
      + created_at      = (known after apply)
      + current_state   = (known after apply)
      + current_tasks   = (known after apply)
      + iam             = (known after apply)
      + id              = (known after apply)
      + order           = (known after apply)
      + ovh_subsidiary  = "FR"
      + plan            = [
          + {
              + configuration = [
                  + {
                      + label = "region_name"
                      + value = "eu-west-rbx"
                    },
                ]
              + duration      = "P1M"
              + plan_code     = "vrack-services"
              + pricing_mode  = "default"
            },
        ]
      + resource_status = (known after apply)
      + target_spec     = {
          + subnets = [
              + {
                  + cidr              = "192.168.168.0/24"
                  + service_endpoints = [
                      + {
                          + managed_service_urn = (known after apply)
                        },
                    ]
                  + service_range     = {
                      + cidr = "192.168.168.248/29"
                    }
                  + vlan              = 666
                    # (1 unchanged attribute hidden)
                },
            ]
        }
      + updated_at      = (known after apply)
    }

Plan: 6 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + client_id     = (known after apply)
  + client_secret = (sensitive value)
  + efs_id        = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.ovh_efs_trident.null_resource.config_validation: Creating...
module.ovh_efs_trident.null_resource.config_validation: Creation complete after 0s [id=8553589333890826101]
module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client: Creating...
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Creating...
module.ovh_efs_trident.ovh_me_api_oauth2_client.api_oauth2_client: Creation complete after 0s [id=EU.xxxxxxxxxxxxx]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m20s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [00m30s elapsed]
...
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [03m40s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Still creating... [03m50s elapsed]
module.ovh_efs_trident.ovh_storage_efs.efs[0]: Creation complete after 3m52s [id=c2d759de-cd63-4e28-aaab-a7599aad2ca8]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Creating...
module.ovh_efs_trident.ovh_iam_policy.iam_policy: Creating...
module.ovh_efs_trident.ovh_iam_policy.iam_policy: Creation complete after 0s [id=a434d1a4-1234-5678-9012-cf54251eee52]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [00m20s elapsed]
...
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Still creating... [01m20s elapsed]
module.ovh_efs_trident.ovh_vrackservices.vrackservices[0]: Creation complete after 1m30s [id=vrs-a00-b11-c22-d33]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Creating...
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [00m10s elapsed]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [00m20s elapsed]
...
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Still creating... [01m40s elapsed]
module.ovh_efs_trident.ovh_vrack_vrackservices.vrack-vrackservices-binding[0]: Creation complete after 1m43s [id=vrack_pn-1234567-vrackServices_vrs-a00-b11-c22-d33]

Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

Outputs:

client_id = "EU.xxxxxxxxxxxxx"
client_secret = <sensitive>
efs_id = "c2d759de-cd63-4e28-aaab-a7599aad2ca8"

Save the OAuth2 credentials in environment variables:

export EFS_CLIENT_ID=$(terraform output -raw client_id)
export EFS_CLIENT_SECRET=$(terraform output -raw client_secret)

Trident CSI Installation

Install the Trident operator in your MKS cluster:

helm repo add netapp-trident https://netapp.github.io/trident-helm-chart

helm install trident-operator netapp-trident/trident-operator \
  --version 100.2502.1 \
  --create-namespace \
  --namespace trident \
  --set tridentSilenceAutosupport=true \
  --set operatorImage="ovhcom/trident-operator:25.02.1-linux-amd64" \
  --set tridentImage="ovhcom/trident:25.02.1-linux-amd64"

You should have a result like this:

$ helm install trident-operator netapp-trident/trident-operator \
  --version 100.2502.1 \
  --create-namespace \
  --namespace trident \
  --set tridentSilenceAutosupport=true \
  --set operatorImage="ovhcom/trident-operator:25.02.1-linux-amd64" \
  --set tridentImage="ovhcom/trident:25.02.1-linux-amd64"

NAME: trident-operator
LAST DEPLOYED: Tue Apr 28 14:01:19 2026
NAMESPACE: trident
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing trident-operator, which will deploy and manage NetApp's Trident CSI
storage provisioner for Kubernetes.

Your release is named 'trident-operator' and is installed into the 'trident' namespace.
Please note that there must be only one instance of Trident (and trident-operator) in a Kubernetes cluster.

To configure Trident to manage storage resources, you will need a copy of tridentctl, which is
available in pre-packaged Trident releases.  You may find all Trident releases and source code
online at https://github.com/NetApp/trident.

To learn more about the release, try:

  $ helm status trident-operator
  $ helm get all trident-operator

Once the installation is complete, verify that all Trident pods are in Running state in the trident namespace before proceeding:

$ kubectl get pods -n trident

NAME                                  READY   STATUS    RESTARTS      AGE
trident-controller-5bf6c8d6f6-g95jq   6/6     Running   0             119s
trident-node-linux-4xtjr              2/2     Running   1 (82s ago)   119s
trident-node-linux-6w5ff              2/2     Running   1 (82s ago)   119s
trident-node-linux-r7hxp              2/2     Running   0             119s
trident-operator-859f59c58b-2z2ts     1/1     Running   0             2m31s

Trident Backend Creation

The Trident backend connects NetApp Trident to the OVHcloud EFS service using the IAM credentials previously created.

1. Secret Creation

Create a Kubernetes Secret containing the connection information that allows Trident to access the OVHcloud API. Create a trident-secret.yaml.template file with the following content:

apiVersion: v1
kind: Secret
metadata:
  name: ovh-efs-secret
type: Opaque
stringData:
  clientID: "$EFS_CLIENT_ID"         # your clientId
  clientSecret: "$EFS_CLIENT_SECRET" # your clientSecret

Replace the clientID and clientSecret values by the OAuth2 client we created with Terraform:

envsubst < trident-secret.yaml.template > trident-secret.yaml

Apply the secret in your cluster:

kubectl apply -f trident-secret.yaml -n trident

Check that the secret has been correctly created:

$ kubectl get secret ovh-efs-secret -n trident

NAME             TYPE     DATA   AGE
ovh-efs-secret   Opaque   2      3s

2. Trident Backend Creation

Create your backend with the command below:

cat <<EOF | kubectl create -n trident -f -
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ovh-efs-rbx
spec:
  version: 1
  backendName: backend-ovh-efs
  defaults:
    exportRule: "192.168.168.0/24"    # CIDR of your network for NFS ACLs
  storageDriverName: ovh-efs
  clientLocation: ovh-eu
  location: eu-west-rbx         # Location of your EFS service
  serviceLevel: premium
  nfsMountOptions: rw,hard,rsize=65536,wsize=65536,nfsvers=3,tcp
  credentials:
    name: ovh-efs-secret
  volumeCreateTimeout: "60" 
EOF

⚠️ The ovh-efs storage driver must be used. Replace exportRule, location, and other parameters with values matching your environment.

Verify that the backend has been created correctly with the command below:

$ kubectl get TridentBackendConfig -n trident

NAME          BACKEND NAME      BACKEND UUID                           PHASE   STATUS
ovh-efs-rbx   backend-ovh-efs   ace12d67-70ea-44e1-abd8-20d016f7f030   Bound   Success

Use EFS in your MKS cluster

This section describes how to expose Enterprise File Storage to Kubernetes workloads using Trident.

1. StorageClass

In a sc_efs.yaml file, define a StorageClass to enable dynamic provisioning via the Trident CSI driver:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ovh-efs-premium
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ovh-efs"
  fsType: "nfs"
allowVolumeExpansion: true

Apply the StorageClass:

kubectl apply -f sc_efs.yaml

Check that the StorageClass has been created:

$ kubectl get sc ovh-efs-premium

NAME              PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ovh-efs-premium   csi.trident.netapp.io   Delete          Immediate           true                   3h13m

This StorageClass allows volumes to be provisioned on demand and expanded dynamically.

2. Volume Creation (PVC)

Create a PersistentVolumeClaim with ReadWriteMany (RWX) access mode. Create a pvc_efs.yaml file with this content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: premium-pvc-efs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: ovh-efs-premium

Apply it:

kubectl apply -f pvc_efs.yaml

Verify that the PVC has been created with the command below:

kubectl get pvc premium-pvc-efs

At this point, the EFS is creating a volume, attach the correct ACL to it and mount it in the PVC

After a little time, the output should show the PVC in Bound state:

$ kubectl get pvc

NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
premium-pvc-efs   Bound    pvc-faca364d-ad76-44ec-9bc9-959c0d33c515   100Gi      RWX            ovh-efs-premium   <unset>                 3m43s

The volume has been created through the PVC and you can now mount it in a Pod 🎉.

Conclusion

In this blog, we’ve explained how to create an EFS and use it in a MKS cluster through Trident CSI. This will give you a flexible, production-ready approach to persistent shared storage in Kubernetes.

We recommend you also take a look at our Cloud Roadmap & Changelog for an overview of all the coming features for OVHcloud Public Cloud products.

With the OVHcloud Startup Program, you can enhance your cloud expertise and accelerate your growth. How?

The Startup Program provides you with access to dedicated cloud resources, including technical consultation sessions with our engineers. These sessions can help you navigate the complexities of cloud infrastructure and optimize your cloud strategy.

Now you can also get access to dedicated cloud training. As a Startup Program member, you can obtain cloud solutions certifications which will make you stand out from the crowd and, also, be better prepared to navigate your cloud strategy.

We’ve opted for a flexible training model because we trust our customers. This means that you can train independently through e-learning, whenever you want, choosing the courses that are relevant to your business and the people who need to be trained, according to their role. This saves you time and money and, thanks to the expertise you’ll gain through training, you’ll be able to deploy more cost-effective and efficient cloud solutions.

Our training courses and certifications give you a more qualified workforce.

In addition to validating your technical skills, our certifications can help you develop your expertise. Plus, you can demonstrate this with our certification badges, which help you gain recognition.

Finally, OVHcloud offers a wide range of solutions. Our training courses will help you discover the scope of these solutions and when and how to use them. Each course is designed to help you deliver a great experience for your customers. Simply by having the right knowledge to effectively identify the best solution to meet their needs.

Once trained, you are also likely to have ideas for new projects.

Get certified and give your expertise a headstart.

Discover our Training Portal’s catalog to boost your expertise.

https://startup.ovhcloud.com/Get started with the OVHcloud Startup Program and accelerate your growth today. Apply now and discover how our program can help you achieve your goals: https://startup.ovhcloud.com/

Mia Experts is a new generation medical software platform designed by a physician, for physicians. From the very beginning, the product was built to integrate artificial intelligence in a way that is useful, secure, and aligned with the realities of medical practice.

Today, many doctors spend a significant part of their day dealing with administrative tasks rather than focusing on patient care and clinical decision-making. Existing medical software is often outdated, poorly designed, and disconnected from how physicians actually work.

Mia Experts aims to change that. By leveraging artificial intelligence, the platform automates repetitive tasks and structures medical data in a meaningful and usable way. The goal is simple: give physicians back their time.

The solution primarily targets private practitioners, particularly in general medicine and surgical specialties, where efficient data management, reliability, and time savings are critical.

Built from Real Medical Experience

The idea behind Mia Experts originated from the daily experience of Vincent Salabi, a surgeon who repeatedly encountered the same issue: medical software that was slow, repetitive, and time-consuming.

Instead of helping doctors, these tools often added friction to their workflow.

At the same time, a major technological shift was occurring: artificial intelligence was becoming accessible in a way that could be deployed securely and within a sovereign regulatory framework.

Mia Experts was born from the collaboration of three co-founders with complementary expertise — medical, technical, and entrepreneurial — united by a shared ambition: to fundamentally rethink the physician’s digital workspace.

Early Milestones and Key Achievements

From the earliest stages, several key milestones helped shape the development of Mia Experts.

One of the first successes was designing the software architecture. The team built a simple, modular, and scalable architecture capable of intelligently interacting with both patient and physician data.

The objective was clear: eliminate unnecessary repetition, ensure every piece of data has meaning, and enable reliable data usage — whether for prescription generation or reducing medical errors.

Operating in the highly regulated healthcare sector also required building an infrastructure compliant with Health Data Hosting (HDS) regulations. Mia Experts chose OVHcloud, ensuring health data sovereignty and providing a robust and secure cloud foundation.

Infrastructure management is handled in partnership with Lecpac Consulting, allowing the team to meet regulatory requirements while focusing on product development and innovation.

Another major milestone came through early presentations at medical conferences, particularly in orthopedic and urological surgery. The response from physicians was extremely positive. The software’s usability and clinical logic quickly generated word-of-mouth interest — even among doctors who had not been directly approached.

Mia Experts also achieved several regulatory and technological milestones:

• LAP certification for prescription software, obtained in collaboration with healthtech company Posos
• INSi compliance, enabling integration with national health identity standards

Even before official product launch, the startup received around 50 pre-orders purely through demonstrations and conference discussions.

The platform is now entering its beta testing phase, with the first deployments planned soon.

Core Values Driving the Product

The development of Mia Experts is guided by a set of strong principles:

• Simplicity – intuitive interfaces designed for real medical workflows
• Pragmatism – AI must deliver measurable time savings
• Data sovereignty – full control over hosting and infrastructure
• Health data security – non-negotiable protection standards
• Intelligent data structuring – ensuring reliable and actionable medical information

Business, Technical and Regulatory Complexity

Building a medical software platform involves navigating a unique combination of business, technological, and regulatory challenges.

From a business perspective, the first hurdle was securing funding while preserving technological independence. Mia Experts achieved this through an initial funding round involving physician investors, complemented by support from Bpifrance and the French Tech Grant program.

On the technical side, the strict healthcare regulatory environment posed significant challenges. Compliance with HDS standards required implementing strong guarantees around security, traceability, service availability, and access governance from the very beginning.

Another critical challenge involved health data interoperability. Medical data must follow standardized national frameworks and coding systems. Mia Experts needed to structure and transform this data so it could interact seamlessly with national health services such as secure messaging systems and health data platforms.

Yet the biggest challenge was balancing all these constraints with a smooth user experience.

The ambition was never to create software that was simply compliant but difficult to use. Instead, the goal was to design a platform that remains intuitive, efficient, and truly supportive of physicians’ daily work.

Why Mia Experts Chose the Cloud

Cloud infrastructure quickly became a natural choice for the project.

First, artificial intelligence requires scalable computing resources. Running AI endpoints, fine-tuning models, and processing medical voice data demand infrastructure that can scale dynamically while protecting sensitive data.

Second, the cloud offers strong advantages for security and regulatory compliance. As a medical software publisher, Mia Experts needed an infrastructure capable of guaranteeing both data sovereignty and regulatory compliance within the European framework.

Finally, the cloud enables a much more agile product strategy. Unlike traditional locally installed medical software, cloud-based architecture allows centralized updates and continuous product improvement without disrupting physicians’ workflows.

For a fast-growing startup, this flexibility is essential.

Leveraging OVHcloud to Build a Sovereign Health Infrastructure

Choosing OVHcloud was a strategic decision for Mia Experts, especially in a context where health data sovereignty is a critical issue.

Many solutions rely on non-European cloud providers. OVHcloud allowed the startup to build its infrastructure on a secure, sovereign European cloud, fully compliant with French and EU regulations.

This has become a strong differentiator — both from a regulatory standpoint and in terms of trust with physicians.

The OVHcloud Startup Program also played a key role during the early development phase by helping offset the high technical costs associated with innovation.

Mia Experts relies heavily on speech-to-text and AI models for generating medical reports. Fine-tuning these models to understand medical vocabulary requires substantial computing power. The program allowed the team to train and test these models without immediate financial pressure.

The Infrastructure Behind Mia Experts

Today, the platform runs on a robust cloud architecture built on OVHcloud services, including:

• Managed Kubernetes for Dev, Pre-production, and Production environments
• S3-compatible object storage for medical documents and AI models
• GPU instances supporting real-time medical speech transcription
• AI Endpoints for LLMs such as Mistral, Llama, and GPT-OSS
• Dedicated Public Cloud instances hosting GitHub CI/CD runners

All infrastructure is hosted in France, ensuring compliance with GDPR and HDS requirements.

One major advantage of OVHcloud AI endpoints is transparency: customer data is not used to train external models, a key concern in healthcare environments.

Tangible Results and Impact

The collaboration with OVHcloud has enabled several concrete achievements.

First, Mia Experts successfully deployed an infrastructure fully compliant with HDS health data hosting standards, guaranteeing high levels of security, availability, and traceability.

Second, the startup has been able to build and control its own AI capabilities, particularly around speech recognition and medical text generation. The voice recognition system has already been adapted to medical vocabulary, delivering strong accuracy in clinical contexts.

Another key outcome is AI sovereignty. By hosting AI inference within a controlled European environment, Mia Experts retains full control over its data, models, and algorithms.

Finally, the cloud infrastructure provides significant operational agility. The team can deploy updates quickly, iterate on AI models, and continuously improve application performance.

Accelerating Product Adoption

These technological choices have significantly strengthened Mia Experts’ positioning within the medical software ecosystem.

The cloud infrastructure makes the solution eligible for Ségur V2 standards, a key regulatory benchmark for healthcare software interoperability in France.

This strengthens credibility with physicians and facilitates integration into the national digital health ecosystem.

By maintaining full control over its AI pipeline — from hosting to model fine-tuning — Mia Experts can guarantee both data confidentiality and high-quality performance tailored to medical language.

What’s Next for Mia Experts

The next step is the progressive onboarding of the first users, with around 50 pre-registrations already secured before the official launch.

In the medium term, the startup aims to reach:

• 300 users within two years
• 500 users within three years

At the same time, Mia Experts plans to expand beyond surgical specialties with the launch of Mia Experts for General Practice, followed by extensions into additional medical disciplines.

The long-term vision is to build a modular medical platform adaptable to multiple specialties while sharing a unified technological foundation.

Advice for Other Startups

For startups building AI-driven products, the Mia Experts team highlights three key lessons.

First, anticipate your data strategy early. AI models are only as good as the data used to train them. Structuring and preparing datasets before accessing cloud resources can provide a major competitive advantage.

Second, do not underestimate regulatory complexity, especially in sectors like healthcare. Partnering with an experienced infrastructure manager can significantly accelerate deployment.

Finally, think of the cloud not only as hosting infrastructure but as a strategic platform for innovation and scalability.

Conclusion

The journey of Mia Experts shows that innovation in healthcare requires a careful balance between technological ambition, regulatory rigor, and practical usability.

By building on a sovereign and compliant cloud infrastructure from the outset, the startup has laid strong foundations for developing a medical platform that genuinely supports physicians.

The collaboration with OVHcloud has enabled Mia Experts to deploy a secure, scalable, and AI-ready infrastructure, ensuring full control over both health data and AI models.

For startups operating in highly regulated sectors, choosing the right cloud ecosystem can make all the difference — enabling innovation, accelerating growth, and building trust from day one.

Don’t let infrastructure costs limit your growth. We strongly urge other startups to join the OVHcloud Startup Program. Contact their team to build your own foundation for sustainable success.

If you’re a startup looking to transform your business, we encourage you to join the OVHcloud Startup Program or contact OVHcloud to discover how our solutions can support your journey!

This reference architecture demonstrates how to deploy a Large Language Model (LLM) inference system using vLLM on OVHcloud Managed Kubernetes Service (MKS). The solution leverages NVIDIA L40S GPUs to serve the Qwen3-VL-8B-Instruct multimodal model (vision + text) with OpenAI-compatible API endpoints.

This comprehensive guide shows you how to deploy, to scale automatically, and how to monitor vLLM-based LLM workloads on the OVHcloud infrastructure.

What are the key benefits?

• Cost-effectiveness: Leverage managed services to minimise operational overhead
• Real-time observability: Track Time-to-First-Token (TTFT), throughput, and resource utilisation
• Sovereign infrastructure: Keep all metrics and data within European datacentres
• Scalable by design: Automatically scale GPU inference replicas based on real workload demand

Context

Managed Kubernetes Service

OVHcloud MKS is a fully managed Kubernetes platform designed to help you deploy, operate, and scale containerised applications in production. It provides a secure and reliable Kubernetes environment without the operational overhead of managing the control plane.

How does this benefit you?

• Cost-efficient: Pay only for worker nodes and consumed resources, with no additional charge for the Kubernetes control plane
• Fully managed Kubernetes: Certified upstream Kubernetes with automated control plane management, provided upgrades and high availability
• Production-ready by design: Built-in integrations with OVHcloud Load Balancers, networking, and persistent storage
• Scalable and flexible: Scale workloads easily, node pools to match application demand
• Open and portable: Based on standard Kubernetes APIs, enable seamless integration with open-source ecosystems and avoid vendor lock-in

In the following guide, all services are deployed within the OVHcloud Public Cloud.

Architecture overview

This reference architecture demonstrates a basic deployment of vLLM for vision-language model inference on OVHcloud Managed Kubernetes Service, featuring:

• High-availability deployment with 2 GPU nodes (NVIDIA L40S)
• Optimised GPU utilisation with proper driver configuration
• Scalable infrastructure supporting vision-language models
• Comprehensive monitoring using Prometheus, Grafana, and DCGM
• Full observability for both application and hardware metrics

Data flow:

1. Inference request:
   • User → LoadBalancer → Gateway → NGINX Ingress → “Qwen3 VL” Service → vLLM Pod → GPU
   • Response follows reverse path with streaming support
2. Metrics collection:
   • vLLM Pods expose /metrics endpoint (port 8000)
   • DCGM Exporters expose GPU metrics (port 9400)
   • Prometheus scrapes both endpoints every 30 seconds
   • Grafana queries Prometheus for visualization
3. Load distribution
   • NGINX Ingress uses cookie-based session affinity
   • vLLM Service uses ClientIP session affinity
   • Anti-affinity ensures 1 pod per GPU node

Prerequisites

Before you begin, ensure you have:

• An OVHcloud Public Cloud account
• An OpenStack user with the Administrator role
• Hugging Face access – create a Hugging Face account and generate an access token
• kubectl already installed and helm installed (at least version 3.x)

🚀 Now you have all the ingredients, it’s time to deploy the recipe for Qwen/Qwen3-VL-8B-Instruct using vLLM and MKS!

Architecture guide: Native GPU deployment of vLLM on MKS with full stack observability

This reference architecture describes a Large Language Model deployment using vLLM inference server and Kubernetes, to enjoy the benefits of a service that’s both highly available and monitorable in real time.

Step 1 – Create MKS cluster and Node pools

From OVHcloud Control Panel, create a Kubernetes cluster using the MKS.

Navigate to: Public Cloud → Managed Kubernetes Service → Create a cluster

1. Configure cluster

Consider using the following configuration for the current use case:

• Name: vllm-deployment-l40s-qwen3-8b
• Location: 1-AZ Region – Gravelines (GRA11)
• Plan: Free (or Standard)
• Network: attach a Private network (e.g. 0000 - AI Private Network)
• Version: Latest stable (e.g. 1.34)

2. Create GPU Node pool

During the cluster creation, configure the vLLM Node pool for GPUs:

• Node pool name: vllm
• Flavor: L40S-90
• Number of nodes: 2
• Autoscaling: Disabled (OFF)

Why L40S-90?

• Cost-effective for single-model deployment (1 GPU per node)
• Sufficient RAM (90GB) for Qwen3-VL-8B model

You should see your cluster (e.g. vllm-deployment-l40s-qwen3-8b) in the list, along with the following information:

You can now set up the node pool dedicated to monitoring.

3. Create CPU Node pool

From your cluster, click on Add a node pool and configure it as follow:

• Node pool name: monitoring
• Flavor: B2-15
• Number of nodes: 1
• Autoscaling: Disabled (OFF)

✅ Note

Monitoring stack can run on GPU nodes if cost is a concern. Dedicated CPU node provides better isolation and resource management.

If the status is green with the OK label, you can proceed to the next step.

4. Configure Kubernetes access

Once your nodes have been provisioned, you can download the Kubeconfig file and configure kubectl with your MKS cluster.

# configure kubectl with your MKS cluster
export KUBECONFIG=/path/to/your/kubeconfig-xxxxxx.yml

# verify cluster connectivity
kubectl cluster-info
kubectl get nodes

Returning:

NAME                     STATUS   ROLES    AGE   VERSION
monitoring-node-xxxxxx   Ready    <none>   1d   v1.34.2
vllm-node-yyyyyy         Ready    <none>   1d   v1.34.2
vllm-node-zzzzzz         Ready    <none>   1d   v1.34.2

Before going further, add a label to the CPU node for monitoring workloads.

CPU_NODE=$(kubectl get nodes -o json | \
  jq -r '.items[] | select(.status.allocatable."nvidia.com/gpu" == null) | .metadata.name')
kubectl label node $CPU_NODE node-role=monitoring

Finally, check with the following command:

NAME                     GPU      ROLE
monitoring-node-xxxxxx   <none>   monitoring
vllm-node-yyyyyy         1        <none>
vllm-node-zzzzzz         1        <none>

Once both nodes are in Ready status, you can proceed to the next step.

Step 2 – Install GPU operator

To start, consider setting up the GPU operator.

✅ Note

This step is based on this OVHcloud documentation: Deploying a GPU application on OVHcloud Managed Kubernetes Service

1. Add NVIDIA helm repository and create namespace

Add NVIDIA helm repo:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

And create Namespace as follow.

kubectl create namespace gpu-operator

2. Install GPU operator with correct configuration

The GPU Operator must be configured with specific driver versions to ensure compatibility with vLLM containers.

However, the default installation uses recent drivers (580.x with CUDA 13.x) which are incompatible with vLLM containers (CUDA 12.x).

Solution: Force driver version 535.183.01 (CUDA 12.2).

helm install gpu-operator nvidia/gpu-operator \
  -n gpu-operator \
  --set driver.enabled=true \
  --set driver.version="535.183.01" \
  --set toolkit.enabled=true \
  --set operator.defaultRuntime=containerd \
  --set devicePlugin.enabled=true \
  --set dcgmExporter.enabled=true \
  --set dcgmExporter.image="dcgm-exporter" \
  --set dcgmExporter.version="3.1.7-3.1.4-ubuntu20.04" \
  --set gfd.enabled=true \
  --set migManager.enabled=false \
  --set nodeStatusExporter.enabled=true \
  --set validator.driver.enable=false \
  --set validator.toolkit.enable=false \
  --set validator.plugin.enable=false \
  --timeout 20m

✅ Note

Specifying the DCGM version may only be necessary if you encounter problems with the default image (e.g. ‘ImagePullBackOff’). If this is the case, add the following parameters:
--set dcgmExporter.repository="nvcr.io/nvidia/k8s"
--set dcgmExporter.image="dcgm-exporter"
--set dcgmExporter.version="3.1.7-3.1.4-ubuntu20.04"

kubectl get pods -n gpu-operator

Note that all pods should reach Running state in 5-10 minutes.

You can also check the GPU availability:

kubectl get nodes -o json | jq -r '.items[] | select(.status.allocatable."nvidia.com/gpu" != null) | "\(.metadata.name): \(.status.allocatable."nvidia.com/gpu") GPU(s)"'

Returning:

vllm-node-yyyyyy: 1 GPU(s)
vllm-node-zzzzzz: 1 GPU(s)

And you can test to run nvidia-smi:

DRIVER_POD=$(kubectl get pods -n gpu-operator -l app=nvidia-driver-daemonset -o name | head -1)
kubectl exec -n gpu-operator $DRIVER_POD -- nvidia-smi

If GPU tests are working properly, you can move on DCGM service configuration.

3. Configure DCGM service

Why is DCGM Exporter required?

DCGM (Data Centre GPU Manager) is NVIDIA’s official tool for monitoring GPUs in production. The goal is to be able to collect and display metrics from both GPU nodes.

The metrics provided are:

• DCGM_FI_DEV_GPU_UTIL – GPU utilisation (%)
• DCGM_FI_DEV_GPU_TEMP – GPU temperature (°C)
• DCGM_FI_DEV_FB_USED – VRAM used (MB)
• DCGM_FI_DEV_FB_FREE – Free VRAM (MB)
• DCGM_FI_DEV_POWER_USAGE – Power consumption (W)
• And 50+ other GPU metrics

Next, ensure DCGM service has the correct labels and port configuration:

kubectl patch svc nvidia-dcgm-exporter -n gpu-operator --type merge -p '{
  "metadata": {
    "labels": {
      "app": "nvidia-dcgm-exporter"
    }
  },
  "spec": {
    "ports": [
      {
        "name": "metrics",
        "port": 9400,
        "targetPort": 9400,
        "protocol": "TCP"
      }
    ]
  }
}'

Verify the endpoints (should show 2 IPs, one per GPU node).

kubectl get endpoints nvidia-dcgm-exporter -n gpu-operator

NAME                   ENDPOINTS                       AGE
nvidia-dcgm-exporter   x.x.x.x:9400,x.x.x.x:9400   17d

Step 3 – Deploy Qwen3 VL 8B with vLLM inference server

The deployment of the Qwen 3 VL 8B model on two L40S GPU nodes is carried out in several stages.

1. Create namespace and Hugging Face secret

Start by creating Namespace:

kubectl create namespace vllm

Next, you must retrieve your Hugging Face token and replace the HF_TOKEN value by your own:

export HF_TOKEN="hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Create your secret as follow:

kubectl create secret generic huggingface-secret \
  --from-literal=token=$HF_TOKEN \
  --namespace=vllm

Verify you obtain the following output by launching:

kubectl get secret huggingface-secret -n vllm

NAME                 TYPE     DATA   AGE
huggingface-secret   Opaque   1      14d

2. Create vLLM deployment configuration

First, you can create vllm-deployment-2nodes.yaml file.

Deploy vLLM:

kubectl apply -f vllm-deployment-2nodes.yaml

You can monitor the deployment (it should take 8-10 minutes for model download and loading).

kubectl get pods -n vllm -o wide -w

Expected output after 10 minutes:

NAME               READY  STATUS   RESTARTS  AGE  IP       NODE  
qwen3-vl-xxxx-yyy  1/1    Running  0         1d   X.X.X.X  vllm-node-yyyyyy
qwen3-vl-xxxx-zzz  1/1    Running  0         1d   X.X.X.X  vllm-node-zzzzzz

You can also check the container logs:

kubectl logs -f -n vllm <pod-name>

You should find in the logs: “Uvicorn running on http://0.0.0.0:8000“

Is everything installed correctly? Then let’s move on to the next step.

3. Add service label

Ensure service has the correct label for ServiceMonitor discovery.

kubectl label svc qwen3-vl-service -n vllm app=qwen3-vl --overwrite

You can now verify by launching the following command.

kubectl get svc qwen3-vl-service -n vllm --show-labels | grep "app=qwen3-vl"

Returning:

qwen3-vl-service  ClusterIP  X.X.X.X  <none> 8000/TCP 1d  app=qwen3-vl

Step 4 – Install NGINX ingress controller

⚠️ Moving beyond Ingress

Follow this tutorial if you want to use Gateway instead of Ingress.

1. Add helm repository and configure Ingress

First of all, add helm repository:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

Create configuration file with ingress-nginx-values.yaml.

Then, install NGINX Ingress:

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  -f ingress-nginx-values.yaml \
  --wait

Wait for LoadBalancer IP. The external IP assignment should take 1-2 minutes.

kubectl get svc -n ingress-nginx ingress-nginx-controller -w

Once <EXTERNAL-IP> is no longer , Ctrl+C and export it:

export EXTERNAL_IP=<EXTERNAL-IP>
echo "API URL: http://$EXTERNAL_IP"

2. Create vLLM Ingress resource

Next, create vLLM Ingress using vllm-ingress.yaml.

Apply it as follow:

kubectl apply -f vllm-ingress.yaml

You can now test different API calls to verify that your deployment is functional.

3. Test API

Firstly, check if the model is available:

curl http://$EXTERNAL_IP/v1/models | jq

{
  "object": "list",
  "data": [
    {
      "id": "qwen3-vl-8b",
      "object": "model",
      "created": 1772472143,
      "owned_by": "vllm",
      "root": "Qwen/Qwen3-VL-8B-Instruct",
      "parent": null,
      "max_model_len": 8192,
      "permission": [
        {
          "id": "modelperm-8fb35cdd3208b068",
          "object": "model_permission",
          "created": 1772472143,
          "allow_create_engine": false,
          "allow_sampling": true,
          "allow_logprobs": true,
          "allow_search_indices": false,
          "allow_view": true,
          "allow_fine_tuning": false,
          "organization": "*",
          "group": null,
          "is_blocking": false
        }
      ]
    }
  ]
}

Next, test inference using the following request:

curl http://$EXTERNAL_IP/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-vl-8b",
    "messages": [{"role": "user", "content": "Count from 1 to 10."}],
    "max_tokens": 100
  }' | jq '.choices[0].message.content'

"1, 2, 3, 4, 5, 6, 7, 8, 9, 10"

Great! You’re almost there…

Step 5 – Install Prometheus stack

Now, set up the monitoring stack that provides complete observability for application-level (vLLM) and hardware-level (GPU) metrics:

1. Add helm repository and create namespace

Add Prometheus helm repo:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Then, create the monitoring Namespace.

kubectl create namespace monitoring

2. Create Prometheus deployment configuration and installation

First, create prometheus.yaml file.

Install Prometheus stack:

helm install prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring \
  -f prometheus.yaml \
  --timeout 10m \
  --wait

Now, monitor its installation and wait until the pods are ready:

kubectl get pods -n monitoring -w

If all pods are running successfully, you can proceed to the next step.

3. Check that the installation is operational

First access Grafana in background:

kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80 &

Test Grafana health:

curl -s http://localhost:3000/api/health | jq

{
  "database": "ok",
  "version": "12.3.3",
  "commit": "2a14494b2d6ab60f860d8b27603d0ccb264336f6"
}

You can now access to Grafana locally via http://localhost:3000. You will have to use:

• Login: admin
• Password: Admin123!vLLM

Well done! You can now proceed to the configuration step.

Step 6 – Configure ServiceMonitors

The ServiceMonitors is used to tell Prometheus which endpoints to scrape for metrics.

1. Create vLLM ServiceMonitor

Retrieve the file from the GitHub repository: vllm-servicemonitor.yaml.

Next, apply and check that the ServiceMonitor vllm-metrics exists:

kubectl apply -f vllm-servicemonitor.yaml
kubectl get servicemonitor -n vllm

2. Create DCGM ServiceMonitor

First, create the dcgm-servicemonitor.yaml file.

Once again, apply and verify:

kubectl apply -f dcgm-servicemonitor.yaml
kubectl get servicemonitor -n gpu-operator

gpu-operator                  1d
nvidia-dcgm-exporter          1d
nvidia-node-status-exporter   1d

3. Configure Prometheus for Cross-Namespace discovery

Apply a patch to allow Prometheus to discover ServiceMonitors in all namespaces.

kubectl patch prometheus prometheus-kube-prometheus-prometheus -n monitoring --type merge -p '{
  "spec": {
    "serviceMonitorNamespaceSelector": {},
    "podMonitorNamespaceSelector": {}
  }
}'

Now you have to restart Prometheus.

1. Delete Prometheus pod to force configuration reload
2. Wait for Prometheus to restart

kubectl delete pod prometheus-prometheus-kube-prometheus-prometheus-0 -n monitoring

kubectl wait --for=condition=Ready \
  pod/prometheus-prometheus-kube-prometheus-prometheus-0 \
  -n monitoring \
  --timeout=180s

Wait about 2 minutes for discovery and finally, verify targets:

kubectl port-forward -n monitoring \
  prometheus-prometheus-kube-prometheus-prometheus-0 9090:9090 &

You can open in browser: http://localhost:9090/targets and search for:

• vllm
• dcgm

Note that the expected targets are:

• serviceMonitor/vllm/vllm-metrics/0 (2/2 UP)
• serviceMonitor/gpu-operator/nvidia-dcgm-exporter/0 (2/2 UP)

Step 7 – Create Grafana dashboards

In this final step, the goal is to create two Grafana dashboards to track both the software side with vLLM metrics and the hardware metrics that will monitor the GPU consumption and system.

1. vLLM application metrics

The dashboard provides insights into vLLM application performance, request handling, and resource utilization based on the following metrics:

This vLLM Grafana dashboard is composed of 23 panels:

The dashboard provides insights into LLM application performance, request handling, and resource utilisation based on the previous metrics.

Now create the dashboard using vllm-app-dashboard.json. Then, launch:

echo "Importing vLLM application dashboard..."
curl -X POST \
  'http://localhost:3000/api/dashboards/db' \
  -H 'Content-Type: application/json' \
  -u 'admin:Admin123!vLLM' \
  -d @vllm-app-dashboard.json | jq '.status, .url'

Next, you an access the vLLM dashboard and follow metrics in real time:

This dashboard is also essential to track hardware consumption for comprehensive monitoring.

2. GPU hardware metrics

Take advantage of the most useful DCGM metrics to check both the functioning and consumption of your hardware resources:

This hardware Grafana dashboard is composed of 13 panels with GPU hardware and system metrics. A detailed view is also available GPU util (%), temperature (°C), vRAM (GB) and power (Watt).

Please refer to hardware-dashboard.json by loading it as follows:

echo "Importing hardware dashboard..."
curl -X POST \
  'http://localhost:3000/api/dashboards/db' \
  -H 'Content-Type: application/json' \
  -u 'admin:Admin123!vLLM' \
  -d @hardware-dashboard.json | jq '.status, .url'

Finally, track resource consumption using this hardware dashboard:

Congratulations! Everything is working. You can now test your model and track the various metrics in real time.

Step 8 – LLM testing and performance tracking

Start by installing Python dependencies:

pip3 install openai tqdm

Replace the <EXTERNAL_IP> by the vLLM service external IP and launch the performance test thanks to the following Python code:

import time
import threading
import random
from statistics import mean
from openai import OpenAI
from tqdm import tqdm

APP_URL = "http://94.23.185.22/v1"
MODEL = "qwen3-vl-8b"

CONCURRENT_WORKERS = 500          # concurrency
REQUESTS_PER_WORKER = 10
MAX_TOKENS = 200                  # generation pressure

# some random prompts
SHORT_PROMPTS = [
    "Summarize the theory of relativity.",
    "Explain what a transformer model is.",
    "What is Kubernetes autoscaling?"
]

MEDIUM_PROMPTS = [
    "Explain how attention mechanisms work in transformer-based models, including self-attention and multi-head attention.",
    "Describe how vLLM manages KV cache and why it impacts inference performance."
]

LONG_PROMPTS = [
    "Write a very detailed technical explanation of how large language models perform inference, "
    "including tokenization, embedding lookup, transformer layers, attention computation, KV cache usage, "
    "GPU memory management, and how batching affects latency and throughput. Use examples.",
]

PROMPT_POOL = (
    SHORT_PROMPTS * 2 +
    MEDIUM_PROMPTS * 4 +
    LONG_PROMPTS * 6    # bias toward long prompts
)

# openai compliance
client = OpenAI(
    base_url=APP_URL,
    api_key="foo"
)

# basic metrics
latencies = []
errors = 0
lock = threading.Lock()

# worker
def worker(worker_id):
    global errors
    for _ in range(REQUESTS_PER_WORKER):
        prompt = random.choice(PROMPT_POOL)

        start = time.time()
        try:
            client.chat.completions.create(
                model=MODEL,
                messages=[{"role": "user", "content": prompt}],
                max_tokens=MAX_TOKENS,
                temperature=0.7,
            )
            elapsed = time.time() - start

            with lock:
                latencies.append(elapsed)

        except Exception as e:
            with lock:
                errors += 1

# run
threads = []
start_time = time.time()

print("\n-> STARTING PERFORMANCE TEST:")
print(f"Concurrency: {CONCURRENT_WORKERS}")
print(f"Total requests: {CONCURRENT_WORKERS * REQUESTS_PER_WORKER}")

for i in range(CONCURRENT_WORKERS):
    t = threading.Thread(target=worker, args=(i,))
    t.start()
    threads.append(t)

for t in threads:
    t.join()

total_time = time.time() - start_time

# results
print("\n-> BENCH RESULTS:")
print(f"Total requests sent: {len(latencies) + errors}")
print(f"Successful requests: {len(latencies)}")
print(f"Errors: {errors}")
print(f"Total wall time: {total_time:.2f}s")

if latencies:
    print(f"Avg latency: {mean(latencies):.2f}s")
    print(f"Min latency: {min(latencies):.2f}s")
    print(f"Max latency: {max(latencies):.2f}s")
    print(f"Throughput: {len(latencies)/total_time:.2f} req/s")

Returning:

-> STARTING PERFORMANCE TEST:
Concurrency: 500
Total requests: 5000

-> BENCH RESULTS:
Total requests sent: 5000
Successful requests: 5000
Errors: 0
Total wall time: 225.54s
Avg latency: 21.45s
Min latency: 6.06s
Max latency: 25.19s
Throughput: 22.17 req/s

Don’t forget to track GPU and vLLM metrics in your Grafana dashboards!

Conslusion

This reference architecture demonstrates a vLLM deployment on OVHcloud Managed Kubernetes Service (MKS) with comprehensive GPU monitoring. Benefits include:

• High Performance: GPU-accelerated inference with L40S
• Scalability: Kubernetes-native, horizontal scaling-ready
• Reliability: Health checks, auto-restart, monitoring
• API Compatibility: OpenAI-compatible endpoints
• Multimodality: Vision & text capabilities
• Full stack monitoring: Complete vLLM application and hardware dashboards

Going Further

Your current architecture is functional. However, if desired, it could be improved into a full production-ready solution.

Wish to take production hardening a step further?

Go further with the following enhancements:

1. Authentication & authorization
   • vLLM API authentication
   • Grafana authentication
   • Prometheus security
2. High availability & load balancing
   • Grafana high availability with multiple replicas and shared storage
   • Prometheus high availability
   • vLLM Horizontal Pod Autoscaling (HPA) based on custom metrics
3. Data persistence & backup
   • Prometheus long-term storage with persistent storage
   • Grafana Dashboard Backup
4. Observability enhancements
   • Distributed tracing by adding OpenTelemetry for request tracing
   • Alerting rules with production-ready alert rules