• 👤 Invitée : Ane Diaz
  • X: @ane_naiz
  • Bluesky : @ane-naiz
  • LinkedIn : https://www.linkedin.com/in/ane-diaz-de-tuesta-37785252
• 🗓️ Date d’enregistrement : 29 mai 2026
• 🎧 Lien vers l’épisode

👤 Présentation d’Ane – ⏱️ 1″

• https://www.zdnet.fr/pratique/jai-utilise-gemini-nano-banana-2-pour-creer-des-sketchnotes-voici-ce-qui-a-bien-fonctionne-et-ce-qui-a-tourne-au-comique-491797.htm
• https://www.linkedin.com/posts/katcosgrove_pull-request-process-share-7448418176419250176-k9Gh
• https://www.ifttd.io/episodes/azure-et-ia

📰 News Techs 

🤖 Intelligence Artificielle – ⏱️ 55″30

Batch mode pour AI Endpoints

• https://labs.ovhcloud.com/en/ai-endpoint-batch-api/
• https://docs.ovhcloud.com/en/guides/public-cloud/ai-machine-learning/ai-endpoints-batch-mode
• https://blog.ovhcloud.com/ovhcloud-ai-endpoints-batch-mode/

Dispo du Qwen3.5-397B-A17B dans AI Endpoints

• https://www.ovhcloud.com/en/public-cloud/ai-endpoints/catalog/qwen-3-5-397b/
• https://blog.ovhcloud.com/extract-text-from-images-with-ocr-using-python-and-ovhcloud-ai-endpoints/

Claude Code found a 23-year-old Linux kernel bug in a bash for loop

https://edera.dev/stories/the-price-of-a-zero-day-vulnerability-is-an-api-call

👩‍💻 Développement – ⏱️ 1h06″46

Ghostty is leaving GitHub

• https://x.com/mitchellh/status/2049213597419774026
• http://updog.ai/

☁️ Cloud – ⏱️ 1h12″46

Navigating OVHcloud Enterprise File Storage (EFS) with Trident CSI On Kubernetes clusters (MKS)

https://dev.to/aurelievache/understanhttps://blog.ovhcloud.com/navigating-ovhcloud-enterprise-file-storage-efs-with-trident-csi-on-kubernetes-clusters-mks/ding-kubernetes-part-61-kubernetes-136-changelog-3cak

Kubernetes 1.36 – changelog in a visual way

https://dev.to/aurelievache/understanding-kubernetes-part-61-kubernetes-136-changelog-3cak

🔐 Sécurité – ⏱️ 1h16″

Copy.fail

https://blog.ovhcloud.com/copy-fail-cve-2026-31431-how-to-rapidly-protect-ovhcloud-mks-clusters-from-the-linux-kernel-zero-day

http://updog.ai

🎤 Conférences / meetup – ⏱️ 1h22″50

• http://anediaz.com
• https://developers.events/

Why there won’t be a devopsdays Amsterdam this year

https://www.linkedin.com/pulse/why-wont-devopsdays-amsterdam-year-devopsams-43wle

Pas d’Agile Tour Toulouse cette année – Annulation

https://www.linkedin.com/posts/apr%C3%A8s-plusieurs-%C3%A9changes-nous-avons-d%C3%A9cid%C3%A9-share-7457517909318430720-6AdX

💡 Retrouvez l’ensemble des autres épisodes ici : https://smartlink.ausha.co/tranches-de-tech 💡

Batch Mode is designed to help in exactly this type of scenario.

What is Batch Mode?

When working with LLMs, you often send requests one by one through synchronous endpoints like /v1/chat/completions or /v1/responses. This works fine for real-time use cases, but what can you do if you need to process hundreds or thousands of prompts? Sending them individually is slow, and you’re limited by rate limits.

Batch mode solves this problem. Instead of sending requests one at a time, you upload a file containing all your requests, submit a batch job, and get the results back asynchronously, within a maximum of 24 hours. And here’s the cherry on top: batch mode is 50% cheaper than synchronous requests. Since the platform can schedule your workload more efficiently, you benefit from a significant cost reduction.

This is ideal for:

• 📊 Bulk classification or summarization tasks
• 🌍 Large-scale translation jobs
• 📝 Generating descriptions for a product catalog
• 🧪 Evaluating model outputs on a test dataset

ℹ️ The Batch API is compatible with the OpenAI Batch API format, so you can use the official OpenAI SDK to interact with it.

When not to use Batch Mode!

Batch Mode is designed for large workloads that do not need an immediate response. This being said, it is not the right choice for real-time use cases such as chatbots, live customer support, interactive assistants or applications where users expect an answer within seconds. For those scenarios, synchronous endpoints remain more appropriate. Use Batch Mode when your requests can be processed asynchronously and retrieved later.

ℹ️ The Batch API is currently in beta. You can find more information about the beta on the dedicated page.

Prerequisites for using Batch Mode

Before getting started, you’ll need:

• An AI Endpoints API key
• Python 3.10+ installed
• The openai Python package

⚠️ You can generate your API key from the AI Endpoints console.

Install the dependency:

pip install openai

Set up your environment variables:

export OVH_AI_ENDPOINTS_ACCESS_TOKEN='your_api_key'
export OVH_AI_ENDPOINTS_BASE_URL='https://oai.endpoints.kepler.ai.cloud.ovh.net/v1'

Step 1: Prepare the Input File

The input file uses the JSON Lines format (.jsonl). Each line is a self-contained request with a unique custom_id that lets you match results to their original requests.

Here’s an example requests.jsonl:

{"custom_id": "request-1", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-oss-20b", "messages": [{"role": "user", "content": "Summarise the plot of Hamlet in two sentences."}]}}
{"custom_id": "request-2", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-oss-20b", "messages": [{"role": "user", "content": "Translate 'Good morning' into French, Spanish and German."}]}}

Key points:

• Each custom_id must be unique within a batch
• The model field must reference a model available in the AI Endpoints catalog
• The url field indicates which endpoint to call

Step 2: Upload the File and Create the Batch

Here’s the complete Python code that handles the full workflow: upload, create, poll, and download:

import os
import time

from openai import OpenAI

# Load environment variables
_OVH_AI_ENDPOINTS_ACCESS_TOKEN = os.environ["OVH_AI_ENDPOINTS_ACCESS_TOKEN"]
_OVH_AI_ENDPOINTS_BASE_URL = os.environ["OVH_AI_ENDPOINTS_BASE_URL"]

# Initialize the OpenAI-compatible client targeting OVHcloud AI Endpoints
client = OpenAI(
    base_url=_OVH_AI_ENDPOINTS_BASE_URL,
    api_key=_OVH_AI_ENDPOINTS_ACCESS_TOKEN,
)

# 1. Upload the input JSONL file with purpose="batch"
print("📤 Uploading input file...")
batch_input_file = client.files.create(
    file=open("requests.jsonl", "rb"),
    purpose="batch",
)
print(f"✅ Uploaded file id: {batch_input_file.id}")

# 2. Create the batch referencing the uploaded file
print("🚀 Creating batch...")
batch = client.batches.create(
    input_file_id=batch_input_file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h",
    metadata={"description": "Batch mode example - OVHcloud AI Endpoints"},
)
print(f"✅ Batch created: {batch.id} (status: {batch.status})")

# 3. Poll the batch status until it reaches a terminal state
print("⏳ Polling batch status...")
while True:
    current = client.batches.retrieve(batch.id)
    print(f"   status={current.status} counts={current.request_counts}")
    if current.status in ("completed", "failed", "expired", "cancelled"):
        break
    time.sleep(30)

# 4. Download the results (and errors if any)
final = client.batches.retrieve(batch.id)

if final.output_file_id:
    print("📥 Downloading results.jsonl...")
    output = client.files.content(final.output_file_id)
    with open("results.jsonl", "wb") as f:
        f.write(output.read())
    print("✅ Results written to results.jsonl")

if final.error_file_id:
    print("🐛 Downloading errors.jsonl...")
    errors = client.files.content(final.error_file_id)
    with open("errors.jsonl", "wb") as f:
        f.write(errors.read())
    print("🐛 Errors written to errors.jsonl")

print(f"🏁 Final batch status: {final.status}")

Let’s break down the key steps:

Upload the input file

batch_input_file = client.files.create(
    file=open("requests.jsonl", "rb"),
    purpose="batch",
)

The purpose=”batch” parameter tells the API that this file will be used as batch input.

Create the batch

batch = client.batches.create(
    input_file_id=batch_input_file.id,
    endpoint="/v1/chat/completions",
    completion_window="24h",
)

The completion_window=”24h” means the batch will be stopped after 24 hours if not completed.

Poll the batch status

while True:
    current = client.batches.retrieve(batch.id)
    print(f"   status={current.status} counts={current.request_counts}")
    if current.status in ("completed", "failed", "expired", "cancelled"):
        break
    time.sleep(30)

The client.batches.retrieve(batch.id) call returns the current state of the batch. The request_counts field gives you a breakdown of how many requests are completed, failed, or still in progress, useful for monitoring large batches.

The possible terminal states are:

• completed: all requests have been processed successfully
• failed: the batch encountered a fatal error
• expired: the batch exceeded the completion_window duration
• cancelled: the batch was manually cancelled via the API

We poll every 30 seconds here, but you can adjust this interval depending on your use case. For very large batches, a longer interval (e.g., 60–120 seconds) is more appropriate.

Download the results

final = client.batches.retrieve(batch.id)

if final.output_file_id:
    output = client.files.content(final.output_file_id)
    with open("results.jsonl", "wb") as f:
        f.write(output.read())

Once the batch is complete, the output_file_id field contains the ID of the results file. You download it using client.files.content() which returns the raw file content.

Download the errors (if any)

if final.error_file_id:
    errors = client.files.content(final.error_file_id)
    with open("errors.jsonl", "wb") as f:
        f.write(errors.read())

If some requests in your batch failed (e.g., invalid model name, malformed input, token limit exceeded), their details will be available in a separate error file. The error_file_id will be None if all requests succeeded. Each line in errors.jsonl contains the custom_id of the failed request along with the error details, making it easy to identify and retry only the failed ones.

Step 3: Read the Results

The output file (results.jsonl) contains one JSON object per line. Each object includes:

• The custom_id matching your original request
• The full response body (same format as a synchronous /v1/chat/completions responses)

Here’s what a result looks like:

{
  "id": "964e007472a557240221910ba143bb03",
  "custom_id": "request-1",
  "response": {
    "status_code": 200,
    "body": {
      "id": "chatcmpl-9879ebff777795a3",
      "choices": [
        {
          "index": 0,
          "message": {
            "role": "assistant",
            "content": "Hamlet, the Prince of Denmark, is driven to madness and vengeance after learning that his father was murdered by his uncle Claudius..."
          },
          "finish_reason": "stop"
        }
      ],
      "model": "gpt-oss-20b",
      "usage": {
        "prompt_tokens": 78,
        "completion_tokens": 297,
        "total_tokens": 375
      }
    }
  },
  "error": null
}

If some requests fail, the errors.jsonl file will contain details about what went wrong for each failed request.

Other Examples Available

The AI Endpoints – Batch mode guide also contains examples in:

• JavaScript: using the OpenAI Node.js SDK
• Pure HTTP requests: using curl without any framework, if you prefer a language-agnostic approach

These examples demonstrate that you can use the Batch API from any language or tool that can make HTTP requests, since it follows the standard OpenAI-compatible API format.

Conclusion

Batch mode is a powerful feature when you need to process large volumes of repetitive, non time-sensitive inference requests, without worrying about rate limits or timeout issues. Upload your file, submit the batch, and come back later for the results, it’s as simple a solution as that.

The OpenAI-compatible API makes it straightforward to integrate into existing workflows, and with examples available in Python, JavaScript, and raw HTTP, you can use whichever approach fits your stack best.

You have a dedicated Discord channel (#ai-endpoints) on our Discord server, see you there!

For more info on AI Endpoints, find our previous blog posts.

Find the full code example in the GitHub repository: public-cloud-examples/ai/ai-endpoints/batch-mode.

Every month, the OVHcloud Developer Advocate team creates content, shares knowledge, and connects with the tech community. Here’s a look at what we did in May 2026. 🚀

🎙️ “Tranches de Tech” – Our monthly podcast

A new episode of our French-language podcast Tranches de Tech 🥑 just dropped!

🎧 Episode 28: La dream team au complet

In this episode of Tranche de Tech, Stephane and Aurelie welcome former team member Thierry for a wide-ranging conversation on tech, conferences, and community.
They reflect on recent events like Devoxx France and MiXiT, sharing highlights from talks, trends, and the growing role of AI in today’s software landscape.
The discussion explores how AI is evolving from pure model innovation toward software patterns, developer tooling, and more practical, structured usage.
Thierry also introduces CALM, his weekly Twitch show, and revisits the inspiring story behind Mixtine, a kids’ tech initiative that brings programming and digital culture to younger generations.
More than a tech recap, this episode is a celebration of curiosity, knowledge sharing, and the importance of building inclusive communities around technology.

See episode shownotes

📺 Live on Twitch

We streamed live on Twitch this month! Here’s what we covered:
🎥 Rémy Vandepoel discussed with Magali De Labareyre about ou human resource management and the OVHcloud culture.
Catch the replay on YouTube ▶️.

🎤 Conference Talks

The team hit the road (and the stage) at several conferences this month:

🏴󠁧󠁢󠁥󠁮󠁧󠁿 Devoxx UK, Londres 🏴󠁧󠁢󠁥󠁮󠁧󠁿

Stéphane gave a talk: 🧰 Dev Containers: the ultimate toolbox for developers?

🇫🇮 KCD Helsinki, Helsinki 🏴󠁧󠁢󠁥󠁮󠁧󠁿

Aurélie Vache gave a talk: The Ultimate Kubernetes Challenge: An Interactive Trivia Game on concepts, components, usage…

🇨🇭 Devopsdays Geneva, Geneva 🇫🇷

Stéphane Philippart gave a workshop Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

📝 Our latest blog posts

Here are the articles our team published on the OVHcloud Blog this month.

📝 Devoxx France 2026: feedback and highlights – by Aurélie Vache

This blog post explains what stood out at Devoxx France 2026, from major conference highlights to the key technology trends shaping the developer ecosystem.
It shows how AI dominated the event, with strong attention on agentic systems, governance, production use cases, and the broader impact of AI on software engineering.
The article also highlights OVHcloud’s strong presence through its booth, community engagement, and a large number of accepted talks and speakers.
Beyond AI, it captures wider themes such as platform engineering, security, cloud resilience, developer experience, open source, and digital sovereignty.
Overall, it offers both a conference recap and a clear snapshot of where the industry is heading in 2026.

📝 Navigating OVHcloud Enterprise File Storage (EFS) with Trident CSI On Kubernetes clusters (MKS) – by Aurélie Vache

This blog post explains how to connect OVHcloud Enterprise File Storage (EFS) to Managed Kubernetes Service (MKS) clusters using NetApp Trident CSI.
It walks readers through provisioning the required OVHcloud resources with Terraform, including EFS, OAuth2 credentials, IAM policies, and vRack Services networking.
The article then shows how to install Trident, configure the backend securely, and integrate EFS as dynamic shared storage for Kubernetes workloads.
It highlights key capabilities such as high availability, predictable performance, and ReadWriteMany access for production-ready persistent storage.
Overall, it serves as a practical step-by-step guide for teams that need scalable shared file storage in OVHcloud Kubernetes environments.

📝 Copy.Fail (CVE-2026-31431): How to Rapidly Protect OVHcloud MKS Clusters from the Linux Kernel Zero-Day – by Aurélie Vache

This blog post explains how the Copy.Fail (CVE-2026-31431) Linux kernel zero-day can rapidly compromise systems through reliable privilege escalation.
It shows how the flaw abuses the algif_aead crypto module to hijack trusted binaries in memory without changing files on disk, making detection harder.
The article highlights the risks for Kubernetes clusters, CI/CD runners, shared environments, and multi-tenant infrastructure.
It also provides an immediate DaemonSet-based mitigation that OVHcloud MKS users can deploy while waiting for patched cluster versions.
Overall, it serves as a practical guide to reducing exposure quickly, while reminding readers that the official security patch is the proper long-term fix.

🎙️ Podcasts / Videos 📺

Aurélie was invited in the podcast “Biztrot Café #2 – IA Gen or not IA Gen ?“.
During this second episode of the podcast, Marian, Julien, Jean-Phi and Aurélie discussed about a recurring question: “AI Gen or not AI Gen?” and the growing use of generative AI in the tech community. Together, they discuss how AI is being used to create conference talks, presentation slides, blog posts, and even sketchnotes. They share both the benefits and the limitations of these tools, highlighting how generative AI can accelerate content creation while still requiring careful review, creativity, and significant iteration to achieve high-quality results.
Watch the replay on YouTube ▶️.

🗓️ Coming up next

Here’s a sneak peek at what’s coming next.

🗓️ – June, 3 – 1h PM CET – Very Tech Talk Twitch about Quantum

📺 OVHcloud Twitch channel

🗓️ – June, 11 & 12 Dev Quest Niort (Niort, France)

🎤 Aurélie Vache is giving one talk (Thursday the 11th at 2h30 PM): Comprendre Kubernetes de manière visuelle

🎤 Stéphane Philippart is giving one workshop (Friday the 12th at 10h AM): Ajouter de l’IA à nos applications : et si c’était aussi simple qu’ajouter une librairie ?

🗓️ – June, 24, 25 & 26 – BreizhCamp (Rennes, France)

🎤 Stéphane Philippart is giving two talks:
– JBang, un fichier Java pour les gouverner tous ? 💍 (Thurdsay the 25th at 5h PM)
– 🧰 Les dev containers, la boîte à outils ultime pour les devs ? (Friday the 26th at 4h PM)

🗓️ New “Tranches de Tech” podcast episode

🎧 All episodes are available on Ausha and all your favorite podcast applications!

💬 Stay in Touch

Want to chat with us, share your thoughts, or just say hi? Here’s how to get in touch with the Developer Advocate team:

• 🟣 Discord: OVHcloud Discord server
• 🐦 X / Twitter: @OVHcloud
• 💼 LinkedIn: OVHcloud LinkedIn
• 🐙 GitHub: github.com/ovh

See you next month! 👋

At OVHcloud, we are proud to continuously evolve our infrastructure to help customers run their virtualized workloads with greater efficiency, flexibility and performance.

Today, we announce the availability of Premier 2027 hardware generation for Managed VMware vSphere solution, bringing significant improvements in compute power, memory capacity, storage capacity, and configuration flexibility.

The new generation improves upon its predecessors, being designed to better support enterprise virtualization environments, modern cloud workloads, as well as evolving VMware licensing models.

Managed VMware vSphere Welcomes a New Generation of Hardware

The Premier 2027 hardware range is replacing the previous Premier generation introduced in 2020, delivering stronger performance and broader configuration options for a wide variety of use cases.
Powered by the latest Intel Emerald Rapids processors, the new infrastructure enables customers to run demanding workloads while maintaining excellent price-performance efficiency.

Key highlights of the new generation include:

• Up to 40% more CPU cores compared to the previous Premier hardware
• Up to 1.5 TB RAM per host
• High-performance NVMe storage
• Up to 50 Gbps private bandwith included

Together, these improvements provide a more powerful and scalable foundation for virtual infrastructures hosted on OVHcloud, our latest pride and joy.

Premier 2027 Hardware Specifications

Latest Intel Emerald Rapids processors

The new servers use Intel Emerald Rapids CPUs, available in both mono-socket and bi-socket configurations, offering a flexible range from 16 to 72 cores.
This allows organizations to choose the right compute capacity for their workloads while benefiting from:

• up to 40% more cores compared to the previous Premier hardware
• up to 50% more CPU cache compared to the previous Premier hardware
• improved performance for compute-intensive applications
• broader servers’ options with global purpose (GP-x) and storage-optimized (STO-x) configurations.

Expanded memory capacity

Premier 2027 servers support up to 1.5 TB of RAM per host, enabling:

• larger virtual machines
• improved consolidation ratios
• better performance for memory-intensive applications such as databases and analytics platforms.

High-performance NVMe storage

The new hardware generation includes NVMe storage, enabling lower latency and faster data throughput.
Storage-optimized configurations (STO-x) leverage vSAN NVMe drives and can support up to 70 TB of storage per host.
This allows organizations to efficiently run storage-intensive workloads, including large databases (such as CRM), analytics platforms and enterprise applications (such as ERP).

High-speed networking

Premier 2027 servers feature up to 50 Gbps private networking included, providing a fast and reliable connectivity for virtual machines and distributed workloads.
This high bandwidth improves performance for applications requiring high data throughput, such as:

• distributed systems
• backup operations
• large-scale data processing.

View prices

Designed for a Wide Range of Enterprise Use Cases

The Premier 2027 hardware generation is designed to support a wide range of enterprise virtualization scenarios.

Cloud migration

Organizations migrating workloads from on-premises VMware environments to the cloud can benefit from performance consistency and familiar tooling, making migration simpler and reducing operational complexity.

The additional compute and memory capacity also make it easier to consolidate workloads and optimize infrastructure costs.

Disaster recovery and business continuity

For disaster recovery environments, infrastructure performance and scalability are critical.
With high-performance NVMe storage and up to 50 Gbps networking, the new hardware enables faster replication, improved recovery times and reliable failover environments.

Customers also benefit from compatible and resilient backup solutions such as Veeam Managed Backup, a managed backup solution to protect and back up their virtual machines, and/or Zerto, a replication platform installed and updated by OVHcloud, that allows them to resume activity quickly and easily.

Enterprise application hosting

Many enterprise applications require predictable performance and large memory capacity.
The Premier 2027 range allows customers to run demanding applications such as:

• large databases, such as CRM
• ERP systems
• data analytics platforms
• containerized workloads on VMware environments.

Seamless Infrastructure Evolution

Customers already running Managed VMware vSphere can integrate the Premier 2027 servers, either global purpose (GP-x) or storage-optimized (STO-x) configurations, into existing environments.

The new hardware is compatible with the current Premier generation, allowing the creation of heterogeneous clusters and enabling customers to scale their infrastructure without requiring a full migration.

This flexibility allows organizations to expand their infrastructure progressively while maintaining operational continuity.

Future-Ready Infrastructure

The Premier 2027 hardware generation provides a strong foundation for future virtualization needs.

With the latest CPU architecture, NVMe storage and high-speed networking, organizations can confidently support evolving workloads and future platform upgrades while maintaining the performance and reliability expected from enterprise VMware environments.

Conclusion

The introduction of Premier 2027 hardware for Managed VMware vSphere marks an important evolution of the OVHcloud Private Cloud platform.

With more powerful processors, increased memory and storage capacity, and flexible configurations, we are delighted to welcome this new generation of infrastructure enabling organizations to run modern workloads more efficiently, while maintaining full control of their VMware environments.

Discover the new Premier 2027 range: https://www.ovhcloud.com/en-ie/hosted-private-cloud/vmware/prices/

Find out more about VMware on OVHcloud solutions: https://www.ovhcloud.com/en-ie/solutions/vmware/

Chez OVHcloud, nous faisons évoluer en continu notre infrastructure afin de permettre à nos clients d’exécuter leurs charges de travail virtualisées avec toujours plus d’efficacité, de flexibilité et de performance.

Dans cette dynamique, nous annonçons aujourd’hui la disponibilité de la nouvelle génération de serveurs Premier 2027 pour la solution Managed VMware vSphere. Cette évolution apporte des améliorations significatives en matière de puissance de calcul, de capacité mémoire, de stockage et de flexibilité de configuration.

Conçue pour s’inscrire dans la continuité des versions précédentes, cette nouvelle génération a été pensée pour mieux répondre aux exigences des environnements de virtualisation d’entreprise, des charges de travail cloud modernes, ainsi qu’à l’évolution des modèles de licence VMware.

Managed VMware vSphere s’enrichit d’une nouvelle génération de serveurs

La gamme de serveurs Premier 2027 succède à la gamme Premier introduite en 2020. Elle propose des performances renforcées, tout en élargissant les possibilités de configuration afin de couvrir un large éventail de cas d’usage.
Grâce aux derniers processeurs Intel Emerald Rapids, cette infrastructure permet d’exécuter des charges de travail exigeantes, tout en conservant un excellent équilibre entre performance et coût.

Principaux points clés de cette évolution : jusqu’à 40 % de cœurs CPU supplémentaires par rapport aux serveurs Premier précédents

• jusqu’à 1,5 To de RAM par hôte
• stockage NVMe haute performance
• bande passante privée jusqu’à 50 Gbit/s incluse

Ensemble, ces améliorations fournissent une base plus puissante et évolutive pour les infrastructures virtuelles hébergées sur OVHcloud, notre dernière fierté.

Spécifications des serveurs Premier 2027

Derniers processeurs Intel Emerald Rapids

Les nouveaux serveurs reposent sur des CPU Intel Emerald Rapids, disponibles en configurations mono-socket et bi-socket, avec une gamme granulaire allant de 16 à 72 cœurs.
Cette diversité permet aux organisations d’ajuster précisément la capacité de calcul à leurs besoins, tout en tirant parti de plusieurs améliorations notables :

• jusqu’à 40 % de cœurs supplémentaires par rapport aux serveurs Premier précédents
• jusqu’à 50 % de cache CPU supplémentaire par rapport aux serveurs Premier précédents
• des performances accrues pour les applications intensives en calcul
• des options de serveurs élargies, avec des configurations polyvalentes (GP-x) et optimisées pour le stockage (STO-x)

Capacité de mémoire étendue

Avec une prise en charge allant jusqu’à 1,5 To de RAM par hôte, les serveurs Premier 2027 permettent :

• le déploiement de machines virtuelles de plus grande taille
• une meilleure consolidation des ressources
• des performances accrues pour les applications exigeantes en mémoire, telles que les bases de données et les plateformes analytiques

Stockage NVMe haute performance

La nouvelle génération de serveurs intègre du stockage NVMe, ce qui se traduit par une latence réduite et un débit de données nettement supérieur.
Dans ce cadre, les configurations optimisées pour le stockage (STO-x) s’appuient sur des disques NVMe vSAN et peuvent atteindre jusqu’à 70 To de capacité par hôte.
Cette architecture permet d’exécuter efficacement des charges de travail intensives en stockage, comme de grandes bases de données telles que les CRM, des plateformes analytiques, ainsi que des applications d’entreprise comme les ERP.

Réseau haut débit

Enfin, les serveurs Premier 2027 intègrent une bande passante privée jusqu’à 50 Gbit/s, assurant une communication rapide et fiable pour les machines virtuelles et les charges de travail distribuées.
Cette bande passante élevée contribue directement à améliorer les performances des applications nécessitant des échanges de données importants, notamment :

• les systèmes distribués
• les opérations de sauvegarde 
• le traitement de données à grande échelle

Voir les prix

Conçu pour une large gamme de cas d’usages Entreprise

La nouvelle génération de serveurs Premier 2027 a été conçue pour prendre en charge un large éventail de scénarios de virtualisation d’entreprise.

Migration vers le cloud

Les organisations qui migrent leurs charges de travail depuis des environnements VMware on-premises vers le cloud bénéficient d’une continuité en matière de performances ainsi que d’outils familiers, simplifiant la migration et réduisant la complexité opérationnelle.

Par ailleurs, l’augmentation des capacités de calcul et de mémoire facilite la consolidation des charges de travail et contribue à optimiser les coûts d’infrastructure.

Reprise après sinistre et continuité d’activité

Pour les environnements de reprise après sinistre, les performances de l’infrastructure et son évolutivité jouent un rôle déterminant.
Grâce au stockage NVMe haute performance et à la connectivité réseau privé jusqu’à 50 Gbit/s, cette gamme permet d’accélérer la réplication, d’améliorer les temps de reprise et de garantir des environnements de basculement fiables.

Les clients peuvent également s’appuyer sur des solutions de sauvegarde compatibles et résilientes, telles que Veeam Managed Backup, une solution managée dédiée à la protection des machines virtuelles, ainsi que Zerto, une plateforme de réplication installée et maintenue par OVHcloud, permettant une reprise d’activité rapide et simplifiée.

Hébergement d’applications d’entreprise

De nombreuses applications d’entreprise nécessitent des performances prévisibles ainsi qu’une capacité de mémoire élevée.
La gamme Premier 2027 permet d’exécuter efficacement des applications exigeantes, telles que :

• de grandes bases de données, comme les CRM ;
• des systèmes ERP ;
• des plateformes d’analyse de données ;
• des charges de travail conteneurisées dans des environnements VMware.

Évolution fluide de l’infrastructure

Les clients utilisant déjà Managed VMware vSphere peuvent intégrer les serveurs Premier 2027, en configurations polyvalentes (GP-x) ou optimisées pour le stockage (STO-x), au sein de leurs environnements existants.

Cette nouvelle gamme de serveursest compatible avec la gamme Premier actuelle, ce qui permet de constituer des clusters hétérogènes et d’étendre l’infrastructure sans nécessiter de migration complète.

Cette approche offre la possibilité de faire évoluer progressivement l’infrastructure tout en assurant la continuité des opérations.

Une infrastructure prête pour l’avenir

La nouvelle génération de serveurs Premier 2027 constitue une base solide pour répondre aux besoins futurs en matière de virtualisation.

Grâce à une architecture CPU de dernière génération, au stockage NVMe et à une connectivité réseau haut débit, les organisations peuvent accompagner l’évolution de leurs charges de travail et de leurs plateformes, tout en maintenant les niveaux de performance et de fiabilité attendus dans des environnements VMware d’entreprise.

Conclusion

L’introduction de la gamme de serveurs Premier 2027 pour Managed VMware vSphere marque une évolution importante de l’offre Private Cloud d’OVHcloud.

Avec des processeurs plus puissants, une capacité de mémoire et de stockage accrue ainsi que des configurations flexibles, cette évolution permet aux organisations d’exécuter plus efficacement des charges de travail modernes, tout en conservant un contrôle total sur leurs environnements VMware.

Découvrez la gamme de serveurs Premier 2027 : https://www.ovhcloud.com/fr/hosted-private-cloud/vmware/prices/

En savoir plus sur les solutions VMware on OVHcloud : https://www.ovhcloud.com/fr/solutions/vmware/

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.

• 👤 Invitée : Thierry CHANTIER
  • Bluesky : @titimoby
  • LinkedIn : https://www.linkedin.com/in/thierrychantier/
• 🗓️ Date d’enregistrement : 30 avril 2026
• 🎧 Lien vers l’épisode

👤 Présentation de Thierry – ⏱️ 1″15s

• https://mixteen.org/
• https://www.ingenieuses.fr/
• https://tontoncodeur.fr/
• https://www.emaxilde.net/#reseaux
• https://techcafe.fr/
• https://lescastcodeurs.com/

📰 News Techs 

🤖 Intelligence Artificielle – ⏱️ 43″35s

Anthropic Claude Code leak

https://www.reddit.com/r/ClaudeAI/comments/1s9d9j9/claude_code_source_leak_megathread/

Qwen 3.6

• https://openrouter.ai/compare/qwen/qwen3.6-plus/anthropic/claude-sonnet-4.6
• https://rits.shanghai.nyu.edu/ai/qwen3-6-27b-a-dense-27b-model-that-beats-a-397b-moe-on-coding/

Quantization from the ground up

https://ngrok.com/blog/quantization

MCP is dead. Long live the CLI

https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

👩‍💻 Développement – ⏱️ 1h07″26s

Thoughts on OpenAI acquiring Astral and uv/ruff/ty

https://simonwillison.net/2026/Mar/19/openai-acquiring-astral

SpaceX is working with Cursor and has an option to buy the startup for $60B

https://techcrunch.com/2026/04/21/spacex-is-working-with-cursor-and-has-an-option-to-buy-the-startup-for-60-billion/

☁️ Cloud – ⏱️ 1h15″15s

OVHcloud Kubernetes Review: Europe’s Quiet Powerhouse

https://www.eucloudcost.com/blog/ovhcloud-cluster

Discovering the External Secrets Operator (ESO) OVHcloud provider to manage your Kubernetes secrets

https://blog.ovhcloud.com/discover-the-external-secret-operator-eso-ovhcloud-provider-to-manage-your-kubernetes-secrets-%f0%9f%8e%89/

Secure your Software Supply Chain with OVHcloud Managed Private Registry (MPR)

https://blog.ovhcloud.com/secure-your-software-supply-chain-with-ovhcloud-managed-private-registry-mpr/

🎤 Conférences / meetup – ⏱️ 1h21″25s

https://developers.events/

Le prochain Riviera Dev

https://www.rivieradev.fr

💡 Retrouvez l’ensemble des autres épisodes ici : https://smartlink.ausha.co/tranches-de-tech 💡

A newly disclosed Linux kernel zero-day, CVE-2026-31431, “Copy.Fail”, is one of the most serious privilege-escalation vulnerabilities in recent years.

Discovered by Theori and publicly disclosed on April 29, 2026, Copy.Fail is a Linux kernel zero-day that roots every distribution since 2017. Unlike many local privilege-escalation flaws that depend on race conditions, kernel address leaks, or distribution-specific behavior, Copy.Fail is alarmingly reliable: it works consistently across mainstream Linux distributions with only a standard user account.

Why the CVE-2026-31431 is dangerous?

Copy.Fail abuses a logic flaw in the Linux kernel’s algif_aead crypto module, introduced through a 2017 optimization. By manipulating the kernel’s AF_ALG crypto interface, an attacker can write controlled data into the Linux page cache (the in-memory representation of trusted system binaries).

This allows attackers to temporarily hijack binaries like /usr/bin/su without modifying the file on disk.

In practical terms:

• A normal user can become root
• A compromised container can escape to the host
• A malicious CI job can root its runner
• Shared infrastructure becomes vulnerable across tenants
• Disk forensics may show no file tampering because only RAM is altered

This makes Copy.Fail especially dangerous for:

• Kubernetes clusters
• CI/CD systems
• Shared development environments
• Cloud notebook platforms
• Multi-tenant container infrastructure

How to patch it easily in your MKS clusters?

OVHcloud is preparing patched MKS versions including the upstream kernel fix. Patched versions are expected to be available 30 April 2026, at 16:00 UTC+2.

While waiting for the next MKS release, here is a DaemonSet manifest that you can apply in your MKS clusters in order to mitigate the vulnerability.

Create a patch-copy-fail-cve file with the following content:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: patch-copy-fail-cve
  labels:
    app: patch-copy-fail-cve
  namespace: default
spec:
  selector:
    matchLabels:
      app: patch-copy-fail-cve
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        app: patch-copy-fail-cve
    spec:
      hostPID: true
      priorityClassName: system-node-critical
      volumes:
        - name: root-mount
          hostPath:
            path: /
            type: Directory
      initContainers:
        - image: mks.kubernatine.ovh/docker.io/library/busybox:1.36.1
          name: patch-copy-fail-cve
          command: ["/bin/bash", "-c"]
          args:
            - |
              tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'
              rmmod algif_aead 2>/dev/null
              update-initramfs -u
          securityContext:
            privileged: true
            runAsUser: 0
          volumeMounts:
            - name: root-mount
              mountPath: /
      containers:
        - image: "mks.kubernatine.ovh/registry.k8s.io/pause:3.10.1"
          name: pause     

Apply it:

kubectl apply -f patch-copy-fail-cve.yaml

⚠️ This mitigation has been tested on OVHcloud internal test clusters. Applying it to your own service remains under your responsibility.

If the vulnerability has already been exploited on your cluster, this mitigation will not remediate any pre-existing compromise.
The recommended remediation remains the official security release, which will be made available as soon as possible.

Read more about the mitigation: https://github.com/rootsecdev/cve_2026_31431#mitigation

Every month, the OVHcloud Developer Advocate team creates content, shares knowledge, and connects with the tech community. Here’s a look at what we did in April 2026. 🚀

🎙️ “Tranches de Tech” – Our monthly podcast

A new episode of our French-language podcast Tranches de Tech 🥑 just dropped!

🎧 Episode 27: Tranches de Tech 26 – Poppy au service des autres

This episode of Tranches de Tech features Annabelle Koster, who shares her journey from tech recruiter to community ambassador, highlighting how she overcame impostor syndrome by actively learning and engaging with developers. She emphasizes the importance of community, conferences, and volunteering in building meaningful connections and personal growth. The discussion also explores the evolving role of AI as a productivity tool in her daily work. Ultimately, the episode underlines that, despite technological advances, human interaction, sharing, and mutual support remain at the heart of the tech ecosystem.

📺 Live on Twitch

We streamed live on Twitch this month! Here’s what we covered:
🎥 Rémy Vandepoel discussed with Antonin Anchisi and Aurélie Vache about our Manages Kubernetes Service (MKS) and some feedbacks about the KubeCon Europe 2026.
Catch the replay on YouTube ▶️.

🎤 Conference Talks

The team hit the road (and the stage) at several conferences this month:

🇫🇷 MiXiT – Lyon, France 🇫🇷

Aurélie Vache gave a talk: Comprendre Kubernetes de manière visuelle

Stéphane Philippart gave a workshop: Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

🇫🇷 Devoxx France – Paris, France 🇫🇷

Aurélie Vache gave a talk: Question pour un cluster Kubernetes : Quiz sur Kubernetes & ses concepts

Stéphane Philippart gave a talk and a workshop (with Mathieu Busquet):
– 🤖 Apprendre à notre IA à … apprendre 🧠
– Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

📝 Our latest blog posts

Here are the articles our team published on the OVHcloud Blog this month.

📝 Extract Text from Images with OCR using Python and OVHcloud AI Endpoints — by Stéphane Philippart

This blog post explains how to perform OCR (Optical Character Recognition) using a vision-capable language model via AI Endpoints and Python. It shows that, instead of traditional OCR tools, developers can send images directly to a multimodal model using the OpenAI-compatible API to extract text while preserving layout. The tutorial walks through a simple Python script, including environment setup, image encoding in base64, and API calls. Overall, it highlights how modern vision LLMs simplify OCR workflows, making text extraction more flexible and easier to implement.

📝 Discover the External Secret Operator (ESO) OVHcloud Provider to manage your Kubernetes secrets 🎉 – by Aurélie Vache

This blog post introduces a new provider for the External Secrets Operator (ESO) that integrates directly with OVHcloud Secret Manager, simplifying how secrets are handled in Kubernetes. It explains how ESO works by synchronizing secrets from external systems into Kubernetes and automatically updating them when changes occur. The tutorial walks through the full setup, including creating a secret in OVHcloud, configuring authentication, and deploying resources like ClusterSecretStore and ExternalSecret. Overall, the article highlights how this new provider streamlines secret management and improves integration between OVHcloud services and Kubernetes environments.

📝 KubeCon + CloudNativeCon Europe 2026 in Amsterdam: feedback and highlights by Aurélie Vache and Rémy Vandepoel

The post highlights KubeCon + CloudNativeCon Europe 2026 as strongly shaped by the rise of AI, pushing cloud-native toward an “AI-native” paradigm. OVHcloud emphasizes sovereign cloud principles, focusing on openness, reversibility, and performance. The event featured rich technical discussions, demos, and exchanges around Kubernetes and demanding workloads. It also underscored the importance of open-source collaboration within the CNCF ecosystem. Finally, OVHcloud’s booth and activities aimed to make these topics more accessible and tangible.

🗓️ Coming up next

Here’s a sneak peek at what’s coming next.

🗓️ – May, 6 & 7 – Devoxx UK, in London

🎤 Stéphane Philippart is giving one talk (Wednesday the 6th at 6PM): 🧰 Dev Containers: the ultimate toolbox for developers?

🗓️ – May, 13 – 1h PM CET – Very Tech Talk Twitch about Human Resources

📺 OVHcloud Twitch channel

🗓️ – May, 19 & 20 – Kubernetes Community Days in Helsinki

🎤 Aurélie Vache is giving one talk (Wednesday the 20th at 2h30 PM): The Ultimate Kubernetes Challenge: An Interactive Trivia Game on concepts, components, usage…

🗓️ – May, 21 & 22 – Devops days in Geneva

🎤 Stéphane Philippart is giving one workshop (Thursday the 21th at 2h55 PM): Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

🗓️ New “Tranches de Tech” podcast episode

🎧 All episodes are available on Ausha and all your favorite podcast applications!

💬 Stay in Touch

Want to chat with us, share your thoughts, or just say hi? Here’s how to get in touch with the Developer Advocate team:

• 🟣 Discord: OVHcloud Discord server
• 🐦 X / Twitter: @OVHcloud
• 💼 LinkedIn: OVHcloud LinkedIn
• 🐙 GitHub: github.com/ovh

See you next month! 👋

Aurélie Vache and Rémy Vandepoel attended alongside 26 other OVHcloud employees. In this blog, they share their thoughts about this second KubeCon set in the land of tulips.

KubeCon Europe 2026: the maturity milestone

Back from Amsterdam, the buzz of the RAI halls still echoes in our ears. This 2026 edition of KubeCon + CloudNativeCon Europe wasn’t just another Kubernetes conference. It marked a turning point for this event: the point of maturity. And this is evident just by looking at the numbers: 13,500 attendees for this edition! The largest attendance ever recorded!

While previous years were about exploration and expansion, 2026 was the year of massive industrialization, with one non-negotiable pre-requirement: digital sovereignty.

Key figures from the 2026 edition:

• 13,500+ attendees (46% first-time attendees)
• 100 countries represented
• 3,474 unique organizations/companies
• 891 sessions
• 230 projects in the CNCF landscape with 19.9 million contributors

CNCF Contributors by Geography (Last 12 Months)

• Europe: 38.8% of contributions (ahead of the United States)
• United States: 36.29%
• Germany: 9.82% (leading in Europe)
• France: 4.68%
• Switzerland: 2.49%
• Strong signals for digital sovereignty, a key theme of this year’s keynotes 💪

Colocated events

KubeCon + CloudNativeCon Europe 2026 traditionally kicks off with a full day dedicated to co-located events. This year was no exception, with an impressive lineup of 16 events, including well-known favorites such as ArgoCon, BackstageCon, CiliumCon, Platform Engineering Day, Kubernetes on Edge Day, and Observability Day.

Among the newcomer events, Open Sovereign Cloud Day was a stand out, as it highlighted the growing importance of cloud sovereignty in Europe.

During CiliumCon, we were proud to see the spotlight on our MKS Standard offer 🚀.

OVHcloud Presence

OVHcloud had a strong presence at the event, with two different booths serving two different purposes.

One was located in the Activation Zone, designed as an interactive space to engage with attendees through a video game “Gaming Camp: Beat Cloud Villains!”, described as “Join the fight against the villains of the cloud. Take on Hidden Cost, Jailor Stack, and Autonomous Zero, and prove yourself as a true Guardian of the Cloud.”

Players were welcomed to step into a two-player fighting game inspired by the style of Street Fighter, where strategy and skill are your best weapons. Winners won exclusive t-shirts.

The second booth had a more corporate focus, highlighting OVHcloud’s broader portfolio, strategic positioning, and enterprise offerings. It provided a space for deeper conversations around demos, use cases, and cloud strategies.

The opportunity was too good to pass up, so we took the chance to interview key players in the ecosystem, as well as customers of our solutions.

We conducted five interviews and had many discussions, and we can’t wait to share them with you soon!

Here’s a sneak peek featuring Sudeep Goswami, CEO of Traefik Labs:

These interviews will soon be available on YouTube, so stay tuned!

Aurélie Vache’s talk

Getting accepted to KubeCon is not easy, and Aurélie, our Developer Advocate and CNCF Ambassador, rose to the challenge by once again presenting a new talk.

“The Ultimate Kubernetes Challenge: An Interactive Trivia Game”:

“Kubernetes has become the de facto standard for deploying and operating containerized applications. We use it, as well as its ecosystem, on a daily basis, but do we know them as well as we think we do?

With a mix of quiz and live demos, come learn and/or improve your knowledge. You will discover (or rediscover) the key concepts of Kubernetes (pods, secrets, services…), internal components but also best practices.

In this fun and dynamic talk, come compete throughout the quiz and explore the wonderful world of Kubernetes.

Icing on the cake: the first will win some swags.“

During this talk, attendees tested their Kubernetes knowledge through an interactive quiz, with results presented via illustrated slides and live, hands-on demos.

Giving a talk at 5 p.m., during the final session of the second day, was an ambitious way to finish up. But thanks to the interactive format of her talk, attendees were able to enjoy testing their knowledge while discovering tips about Kubernetes and its concepts and features.

Three OVHcloud MKS clusters were created especially for the occasion, one with 3 nodes, one with zero nodes, and one with 3 nodes across 3 Availability Zones:

Watch the talk here:

Keynotes: Toward “Agent-Based” and Autonomous AI

Plenary sessions at the event were dominated by a convergence of Kubernetes and Artificial Intelligence. This term, already ubiquitous in tech news, was bound to be a major focus here. Jonathan Bryce, the Executive Director of Cloud & Infrastructure at the Linux Foundation and an iconic figure in the ecosystem, made a strong point by reminding the audience that while Kubernetes is everywhere (82% adoption rate), AI in production remains a major challenge.

In November, during the latest KubeCon + CoudNativeCon NA at Atlanta, the CNCF launched the “Certified Kubernetes AI Conformance Program to Standardize AI Workloads on Kubernetes“.  5 months later, several companies including the OVHcloud Managed Kubernetes Services (MKS) platform, succeeded this new program with their own certified Kubernetes AI platform.

During the keynotes we even saw a real plane!

And to top it off, seeing Michelin present the Top End User Award to SNCF was a real highlight for us. Cocoricoooo! 🇫🇷

Key Trends

Find below the most frequently discussed technical pillars that will remain prominent in the coming months and years:

* Agent-based AI: The focus is shifting from training to inference. The announcement of Dapr Agents 1.0 shows that Kubernetes will now orchestrate agents capable of making real-time decisions on the infrastructure.

* GPU Standardization (DRA): Thanks to NVIDIA’s widespread adoption of Dynamic Resource Allocation (DRA) drivers, GPU scheduling is becoming as simple and granular as CPU scheduling. A boon for cost optimization.

* Sovereignty: Sovereignty is no longer a legal concept; it is an architecture. We have seen a rise in encryption tools for data in transit and at rest (Confidential Computing) natively integrated into CNIs such as Cilium.

* FinOps 2.0: With 67% of AI compute dedicated to inference by the end of 2026, precise monitoring of GPU consumption via projects like Kepler has become essential for the economic viability of projects.

The Gateway API is becoming the standard

As we announced in our blog post “Moving Beyond Ingress: Why should OVHcloud Managed Kubernetes Service (MKS) users start looking at the Gateway API?”, the ingress-nginx controller, the most widely used ingress controller, has now been archived.

Now, after 8 years of development, 275 released versions, and nearly 20k GitHub stars, the maintainers of the Kubernetes Gateway API introduced ingress2gateway v1.0, a tool designed to simplify migration. It automatically converts Ingress resources including annotations into Gateway API resources. The recommended approach remains pragmatic: first migrate the controller while keeping existing Ingress objects, then gradually transition to the Gateway API. Attempting a full migration in a single step is considered risky and unnecessary.

Additionally, Gateway API version 1.5 represents a major milestone: five features have moved from experimental status to the Standard channel in a single release.

Amongst them:

• ListenerSet: delegates TLS listener management outside of the Gateway 
• TLSRoute: SNI-based routing in either termination or passthrough mode
• Client certificate validation for mTLS at the ingress layer
• Native CORS filter for HTTPRoute

The Kubernetes Gateway API is now establishing itself as much more than just a successor to Ingress: it is evolving into Kubernetes’ unified network control plane.

Favorite talk

As usual, Aurélie wasn’t able to attend many talks, but among the 2-3 she did see, there was one that really had a “wow” effect on her:

« An immersive and visual journey into kubernetes networking ».

Benoit, a DevSecOps engineer at Feesh in Switzerland with extensive expertise in Kubernetes networking, created a video game using Godot with four levels: “pod-to-pod basics”, “pod-to-pod advanced”, “service mesh sidecar”, and “service mesh with ambient mode”.

Across these four levels, he explains Kubernetes networking in a vanilla setup, then with Cilium and Istio, all from the perspective of a TCP packet, represented as a fish.

Networking and I don’t exactly get along, and I’ll admit I’ve always struggled with it. Even now, although I’ve had no choice but to work with Kubernetes and service mesh, I still find it challenging. But seeing the fish swim from frontend to backend, enter a building underwater (the node), interact with an eBPF program… it really makes things more visual and intuitive.

On Thursday morning, after the keynote, the room with 2000 seats was packed!

Explaining networking by building a 3D game from scratch specifically for the occasion: hats off to you!

Benoit had an issue on stage, because he had built the game in 4K and it didn’t display properly on the projection screen. Luckily, about 30 seconds before showtime, the production team and he managed to fix it. He went on stage without showing any of that stress 💪.

Replay:

KubeCon in 45 seconds

To keep memories of these 3-4 amazing days, we created a “KubeCon Europe 2026 in 45 seconds movie:

Conclusion

KubeCon Amsterdam proved once again that the strength of open source lies in its community.

From the halls of the RAI to the technical sessions, the excitement was palpable. We’re leaving with our heads full of ideas, but above all with the certainty that collaboration remains the key to solving the complex challenges of modern IT. This was particularly evident in the packed conference rooms and the crowded aisles of the exhibition hall.

One thing is certain: the future of Cloud Native is being written together, and we at OVHcloud look forward to contributing to it with you by helping you get the most out of Kubernetes through our managed platform. Because we’re convinced that for businesses in 2026, the challenge will no longer be how to run Kubernetes, but how to use it to innovate faster and better than the competition.