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.

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

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.

Several months ago, we released the Beta version of the OVHcloud Secret Manager and we guided you how to manage your secrets thanks to the existing External Secret Operator (ESO) Hashicorp Vault provider.

As our Secret Manager is now in General Availability, our teams worked on the development of an OVHcloud ESO Provider now available in the ESO v2.3.0 new release 🎉.

In this blog post, you will learn how to create a new secret in the OVHcloud Secret Manager and how to manage it within your Kubernetes clusters through the OVHcloud ESO provider.

External Secrets Operator (ESO)

The External Secrets Operator (ESO), a CNCF sanbox project since 2022, is a Kubernetes operator that integrates external secret management systems.

The operator reads the information from an external APIs and automatically injects the values into a Kubernetes Secret. If the secret changes in the external API, the operator updates the secret in the Kubernetes cluster.

The ESO connects to an external Secret Manager, such as OVHcloud, Vault, AWS, or GCP, via a provider configured in a (Cluster)SecretStore. An ExternalSecret resource then specifies which secrets to retrieve. ESO fetches those values and creates a corresponding Kubernetes Secret within the cluster.

For more details, read the ESO official documentation.

Prerequisites

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

• Have an OVHcloud account
• Created an OKMS domain (“305db938-331f-454d-83a7-3a0a29291661” for example in this blog post)
• Created an IAM local user (“secretmanager-305db938-331f-454d-83a7-3a0a29291661” for example in this blog post)
• Installed the OVHcloud CLI
• Have a Kubernetes cluster

The ESO OVH provider supports both token and mTLS authentication. In this blog post, we will use the token authentication mode. Please follow the OVHcloud ESO provider guide if you wish to use mTLS authentication mode.

Generate a PAT token (For token authentication only)

The ESO (Cluster)SecretStore needs the permission to fetch secrets from Secret Manager.

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 secret manager for domain <okms-id>" -o json  | jq .details.token |  tr -d '"')

echo $PAT_TOKEN
<your-token>

You should have a result like this:

$ PAT_TOKEN=$(ovhcloud iam user token create secretmanager-305db938-331f-454d-83a7-3a0a29291661 --name pat-secretmanager-305db938-331f-454d-83a7-3a0a29291661 --description "PAT secret manager for domain 305db938-331f-454d-83a7-3a0a29291661" -o json  | jq .details.token |  tr -d '"')
2026/04/07 14:07:45 Final parameters:
{
 "description": "PAT secret manager for domain 305db938-331f-454d-83a7-3a0a29291661",
 "name": "pat-secretmanager-305db938-331f-454d-83a7-3a0a29291661"
}

$ echo $PAT_TOKEN
eyJhbGciOiJFZERTQSIsImtpZCI6IjgzMkFGNUE5ODg3MzFCMDNGM0EzMTRFMDJFRUJFRjBGNDE5MUY0Q0YiLCJraW5kIjoicGF0IiwidHlwIjoiSldUIn0.eyJ0b2tlbiI6InBBSFh1WE5JdVNHYVpmV3F2OUFzVmJrU3UwR2UySTJrdFU0OGdTZkwyZ1k9In0.-VDbiUf4vNm1KB9qSv7i4sGMCvxs_EuZFAETB-eaOFf3IX8-9m7akN800--ASgXy55_DDFHdy4Z5uSq8lww-Bw

Encode the PAT token in base 64 and save it in an environment variable:

export PAT_TOKEN_B64=$(echo -n $PAT_TOKEN | base64)
echo $PAT_TOKEN_B64

Retrieve and save the KMS information

List the OKMS domains:

$ ovhcloud okms list
┌──────────────────────────────────────┬─────────────┐
│                  id                  │   region    │
├──────────────────────────────────────┼─────────────┤
│ 305db938-331f-454d-83a7-3a0a29291661 │ eu-west-par │
│ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │ eu-west-par │
└──────────────────────────────────────┴─────────────┘

Save the KMS endpoint and the OKMS ID in two environment variables. For example:

export OKMS_ID="305db938-331f-454d-83a7-3a0a29291661"
export KMS_ENDPOINT=$(ovhcloud okms get 305db938-331f-454d-83a7-3a0a29291661 -o json | jq .restEndpoint | xargs)

Create a secret in the Secret Manager

In the OVHcloud Control Panel (UI), go to ‘Secret Manager’ section and click on the Create a secret button.

Then in order to create a secret ‘prod/eu-west-par/dockerconfigjson’, in the Europe region (France – Paris) eu-west-par, choose this region:

Then, choose the OKMS domain and create”prod/eu-west-par/dockerconfigjson” in the path and fill the content:

Finally, click on the Create button to finalise the creation of the new secret.

Install or update the ESO

If you’d never installed ESO in your Kubernetes cluster, you can install it via Helm:

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

helm install external-secrets \
   external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --set installCRDs=true

If you already installed it, now you should update it in order to use this new provider:

helm upgrade external-secrets external-secrets/external-secrets -n external-secrets

⚠️ In order to use the OVHcloud provider, you need to have a running instance of ESO equals to version 2.3.0 or more.

$ helm list -n external-secrets

NAME            	NAMESPACE       	REVISION	UPDATED                              	STATUS  	CHART                 	APP VERSION
external-secrets	external-secrets	1       	2026-04-13 13:56:29.071329 +0200 CEST	deployed	external-secrets-2.3.0	v2.3.0

Let’s deploy a Secret in Kubernetes using the ESO provider!

Deploy a ClusterSecretStore to connect ESO to Secret Manager

Set up a ClusterSecretStore to manage synchronization with Secret Manager.
It will use the OVHcloud provider with token authorization mode, and the OKMS endpoint as the backend.

Create a clustersecretstore.yaml.template file with the content below:

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: secret-store-ovh
spec:
  provider:
    ovh:
      server: "$KMS_ENDPOINT" # for example: "https://eu-west-rbx.okms.ovh.net"
      okmsid: "$OKMS_ID" # for example: "734b9b45-8b1a-469c-b140-b10bd6540017"
      auth:
        token:
          tokenSecretRef:
            name: ovh-token
            namespace: external-secrets
            key: token
---
apiVersion: v1
kind: Secret
metadata:
  name: ovh-token
  namespace: external-secrets
data:
  token: $PAT_TOKEN_B64

Generate the clustersecretstore.yaml file from the environment variables you defined:

envsubst < clustersecretstore.yaml.template > clustersecretstore.yaml

You should obtain a file filled with the OVHcloud KMS information:

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: secret-store-ovh
spec:
  provider:
    ovh:
      server: "https://eu-west-par.okms.ovh.net" # for example: "https://eu-west-rbx.okms.ovh.net"
      okmsid: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # for example: "734b9b45-8b1a-469c-b140-b10bd6540017"
      auth:
        token:
          tokenSecretRef:
            name: ovh-token
            namespace: external-secrets
            key: token
---
apiVersion: v1
kind: Secret
metadata:
  name: ovh-token
  namespace: external-secrets
data:
  token: ZXlK...UJ3

Apply it in your Kubernetes cluster:

kubectl apply -f clustersecretstore.yaml

Check:

$ kubectl get clustersecretstore.external-secrets.io/secret-store-ovh

NAME               AGE   STATUS   CAPABILITIES   READY
secret-store-ovh   7s    Valid    ReadWrite      True

Create an ExternalSecret

Create an externalsecret.yaml file with the content below:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: docker-config-secret
  namespace: external-secrets
spec:
  refreshInterval: 30m
  secretStoreRef:
    name: secret-store-ovh
    kind: ClusterSecretStore
  target:
    template:
      type: kubernetes.io/dockerconfigjson
      data:
        .dockerconfigjson: "{{ .mysecret | toString }}"
    name: ovhregistrycred
    creationPolicy: Owner
  data:
  - secretKey: ovhregistrycred
    remoteRef:
      key: prod/eu-west-par/dockerconfigjson

Apply it:

$ kubectl apply -f externalsecret.yaml

externalsecret.external-secrets.io/docker-config-secret created

Check:

$ kubectl get externalsecret.external-secrets.io/docker-config-secret -n external-secrets 

NAME                   STORETYPE            STORE              REFRESH INTERVAL   STATUS         READY   LAST SYNC
docker-config-secret   ClusterSecretStore   secret-store-ovh   30m                SecretSynced   True    4s

After applying this command, it will create a Kubernetes Secret object.

$ kubectl get secret ovhregistrycred -n external-secrets

NAME              TYPE                             DATA   AGE
ovhregistrycred   kubernetes.io/dockerconfigjson   1      49s

The Kubernetes Secret have been created 🎉

We created a Secret directly from the key, but the OVHcloud ESO provider allows you to fetch the original secret from different parameters (fetch the whole secret, fetch nested values, fetch multiple secrets…), according to your needs.

Conclusion

In this blog, we’ve explained how to create secrets in the OVHcloud Secret Manager and then integrate them directly in your Kubernetes clusters using the new ESO OVHcloud provider.

With this brand new OVHcloud provider, you will have a smoother integration between the Secret Manager and your Kubernetes clusters with ESO.

Our team are working on several other integrations, so stay tuned, and please share your thoughts with us!

Before an application go to production, it passes through several stages: source code, build, packaging and distribution. But Malicious code – such as a compromised dependency, breached CI pipeline, or modified package in a registry – can be introduced at any point in the development cycle, potentially impacting thousands of projects

This is precisely where Software Supply Chain Security (SSCS) comes in: to protect not just the code itself, but also how it’s built, delivered, and utilised.

Attacks like SolarWinds and Log4Shell aren’t isolated incidents, but rather subtle indicators that have escalated in severity.

This blog post explores recommended solutions and best practices for OVHcloud Managed Private Registry (MPR), an OCI-compliant artifact registry, to help you enhance your Software Supply Chain Security.

Generate a Software Bill Of Materials (SBOM)

SBOMs provides a list of all the ingredients (OS, libraries, code) and anything that composes the images that will run on your Kubernetes cluster. 

From that list, you can find out more about the image, its vulnerabilities, and licenses.

Generate an SBOM manually

To manually generate an SBOM from your image, click the ‘GENERATE SBOM’ button:

Within seconds, the SBOM column for your image will display “Queued”, then change to “Generating”, and a “SBOM details” link will appear.

Click the ‘SBOM details’ link to view the SBOM:

Your application’s SBOM is generated by Trivy in SPDX format. This item is then listed as an accessory for your image in the registry.

Click the ‘sbom.harbor’ accessory type for more details:

Generate an SBOM automatically

Manually generating an SBOM is a good practice, but automating the process is even better. The private registry can automatically generates the SBOM for you once an image is pushed to the desired project.

Click the project your image is part of, navigate to the ‘Configuration’ tab, then tick the SBOM generation checkbox:

Vulnerabilities scanning

We recommend running vulnerability scans on the images to confirm that:

• the images provided are free of any known vulnerabilities (CVEs);
• security patches are well integrated before deployment;
• the images used in production comply with security and compliance policies.

There are several vulnerability scanners available, like Trivy, Docker Scout, and Grype.

The OVHcloud Managed Private Registry uses Trivy as its default vulnerability scanner, but you can add more scanners if needed. Go to the Administration panel, click ‘Interrogation Services’, then navigate to the ‘Scanners’ tab:

Scan your image manually

To manually run a vulnerability scan on your image, go to your project and click the SCAN VULNERABILITIES button:

Within a few seconds, a scan will run and reveal any vulnerabilities detected in your image.

Click your image to take a look at the CVEs list:

Scan your image automatically

To automatically scan images on push, click the project your image is part of, then the ‘Configuration’ tab, and tick the ‘Vulnerabilities scanning’ checkbox:

Schedule vulnerability scans

Another way to stay informed is by configuring your vulnerability scanner to run scans every day. Go in the Administration panel, click ‘Interrogation Services’, then the ‘Vulnerability’ tab:

You can choose to schedule the scan Hourly, Daily, Weekly or you can customize when the scan will be triggered.

Scheduled scans ensure that existing images are regularly/periodically analyzed for newly discovered vulnerabilities (CVEs).

Prevent vulnerable images from running

You can also configure a project to prevent vulnerable images from being pulled. In order to do that, check the Prevent vulnerable images from running checkbox.

Select the severity level of vulnerabilities to prevent images from running, from None to Critical.

With this configuration, images cannot be pulled if their level is equal to or higher than the selected level of severity.

Exploitable vulnerabilities

When a scanner found vulnerabilities for your images, it is not necessary that they are exploitable in your application/in your image.

In this example, my application is build with golang 1.25-alpine, but Trivy found several CVEs that are only exploitable in golang 1.19.1 or less.

In order to remove/skip the “false positive”, a solution exists.

VEX (Vulnerability Exploitability eXchange) is a standard “format” to state whether a vulnerability is exploitable or not in a specific context.

You can generate a VEX file with vexctl or govulncheck tools.

Example:

# With vexctl
$ VULN_ID="CVE-2022-27664"
$ PRODUCT="pkg:golang/golang.org/x/net@v0.0.0-20220127200216-cd36cc0744dd"
$ vexctl create --file vex.json --author 'Aurélie Vache' --product "pkg:oci/demo@sha256:$HASH?repository_url=$REGISTRY/$HARBOR_PROJECT/demo" --vuln "$VULN_ID" --status 'not_affected' --justification 'vulnerable_code_not_present' --impact-statement "HTTP/2 vulnerability $VULN_ID is not exploitable because the image is compiled with Go 1.20, which contains the patched library."

# With govulncheck (for Go apps)
$ govulncheck -format openvex ./... > ../demo.vex.json

For the moment, OVHcloud MPR (managed Harbor) does not support VEX files (and the OpenVEX format) but it is planned in the future.

💡But the good news is that you can configure a CVEs whitelist with the list of not exploitable CVEs to ignore them during vulnerability scanning:

You can optionally uncheck the Never expires checkbox and use the calendar selector to set an expiry date for the allowlist.

Sign your images

It’s recommended to sign your images to ensure they haven’t been modified and originate from your pipeline (CI/CD).

Signing your images is crucial for protecting them against compromised registries and unauthorised image replacements.

Without a signature, there’s no guarantee the deployed image is the one you originally built!

You can sign your images with Sigstore Cosign or Notation tools:

$ export HARBOR_PROJECT=supply-chain
$ export IMAGE=xxxxxx.c1.de1.container-registry.ovh.net/$HARBOR_PROJECT/demo
$ export HASH=$(skopeo inspect docker://${IMAGE}:latest | jq -r .Digest | sed "s/^sha256://")

# Sign with Cosign
## Generate a private and a public key
$ cosign generate-key-pair
## Sign the image with the OCI 1.1 Referrers API
$ cosign sign -y --key cosign.key $IMAGE@sha256:$HASH 

# Sign with Notation
## Generate a RSA key & a self-signed X.509 test certificate
$ notation cert generate-test --default "test"

## Sign the image with the OCI 1.1 Refferrers API
$ export NOTATION_EXPERIMENTAL=1 ; notation sign -d --allow-referrers-api ${IMAGE}@sha256:${HASH}

You can use Cosign or Notation to sign your images, OVHcloud MPR supports both.

Your signature will appear beside your image as an accessory, plus a green checkmark ✅ in your column:

⚠️ Keep in mind, MPR (Harbor) doesn’t support signatures generated by Cosign v3 (the signature will upload and appear as an accessory, but the mark will stay red instead of turning green). This bug should be fixed in Harbor 2.15 💪.

Signing your OCI artifacts and linking them to your images is recommended, and you can do this using Cosign:

$ cosign attest -y --predicate sbom.spdx.json --key cosign.key $IMAGE@sha256:$HASH

They will be uploaded to the OVHcloud private registry and listed as accessories.

Ensure only verified images are pushed to your registry’s projects

To allow only verified/signed images to be deployed on a project, click the project your image is part of, navigate to the ‘Configuration’ tab, and tick the Cosign and/or Notation checkbox:

When checked, the registry will only allow verified images to be pulled from the project. Verified images are determined by Cosign or Notation, depending on the policy you have checked. Note that if you have both Cosign and Notation policies enforced, then images will need to be signed by both Cosign and Notation to be pulled.

Tag immutability

By default, tags are mutables, it means that you can push an image demo with the tag 1.0.0, do a modification in the code and push again to this same tag.

It could be useful to fix a bug but in term of security a mutable tag does not guarantee that the image you’ve built and pushed for the 1.0.0 version is the same image that exists now in the registry.

Moreover, on Harbor (so on OVHcloud MPR), due to limitations in the upstream OCI Distribution specification, the registry does not enforce a strict link between a tag and an image digest.

As a result, a tag can be reassigned to a different artifact. And it causes a side effect on the registry, this causes the tag to migrate across the artifacts and every artifact that has its tag taken away becomes tagless.

To prevent this situation, you can configure tag immutability rules. Tag immutability guarantees that an immutable tagged artifact cannot be deleted, and also cannot be altered in any way such as through re-pushing, re-tagging, or replication from another target registry.

To do that, click on your project and on the Policy tab and select TAG IMMUTABILITY:

And then click the ADD RULE button.

Fill the repositories and tags list according to your needs.

Example:

⚠️ You can add a maximum of 15 immutability rules per project.

To wrap thing up

Software supply chain security is super important these days. Everything is changing quickly – the concept, standards, and tools. So, leveraging useful tools like OVHcloud MPR and knowing how to set them up can boost your Software Supply Chain Security efforts.

To learn more about how to use and configure OVHcloud private registries, don’t hesitate to follow our guides.

For years, the Kubernetes Ingress API, and the popular Ingress NGINX controller (ingress-nginx), have been the default way to expose applications running inside a Kubernetes cluster.

But the ecosystem is changing: the Kubernetes SIG network has announced the retirement of Ingress NGINX in March 2026.

After March 2026 the Ingress NGINX will no longer get new features, new releases, security patches and bug fixes.

Furthermore, the Kubernetes project recommends using Gateway instead of Ingress.

The Ingress API has already been frozen, which means it is no longer being developed, and will have no further changes or updates made to it. The Kubernetes project has no plans to remove Ingress from Kubernetes.

While OVHcloud Managed Kubernetes Service (MKS) does not yet provide a native GatewayClass, you can already benefit from Gateway API capabilities today by deploying your own controller 💪 .

Also, until Gateway API becomes fully integrated with OpenStack providers, there is an intermediate option: using a modern, actively maintained Ingress controller other than ingress-nginx.

The limitations of the current Ingress controller model

The traditional Kubernetes Ingress model was intentionally simple: define an Ingress, install an Ingress Controller, and let it configure a single proxy (usually Nginx) to route traffic.

This design works, but it comes with limitations:

– Single Monolithic “Entry Point”: All HTTP routing for the entire cluster goes through one shared proxy. It adds complexity, configuration conflicts and scaling challenges.
– Protocol limitations: only HTTP and HTTPS.Support for gRPC, HTTP/2, TCP, UDP or TLS passthrough is inconsistent and controller-specific.
– Heavy Reliance on Annotations: Advanced features (timeouts, rewrites, header handling…) rely on custom annotations.
– Strong 3rd parties and cloud Load Balancers support: Every Ingress controllers (3rd parties providers) come with their specialized annotations.

Finally, as mentioned, the most used Ingress controller, Ingress NGINX, will be retired in March 2026.

A Transitional Solution: Using a Modern Ingress Controller (Traefik, Contour, HAProxy…)

Before moving to the Gateway API, as a transitional solution, OVHcloud MKS users can simply replace Ingress Nginx with a modern, actively maintained Ingress controller.

This allows you to:

– keep using your existing Ingress manifests
– keep the same architecture: Service type LoadBalancer → OVHcloud Public Cloud Load Balancer → Ingress Controller
– avoid relying on unsupported or deprecated components
– gain features (better gRPC support, built‑in dashboards, improved L7 behaviour…)

Popular alternatives:

Traefik:
– Very easy to deploy
– Excellent support for HTTP/2, gRPC, WebSockets
– Built‑in dashboard
– Supports both Ingress and Gateway API
– Actively maintained
– Seamless migration from NGINX Ingress Controller to Traefik with NGINX annotation compatibility

Contour (Envoy):
– Envoy-based Ingress Controller
– Excellent performance
– Good stepping‑stone toward Gateway API

HAProxy Ingress:
– Extremely performant
– Enterprise-grade L7 routing
– Optional Gateway API support

NGINX Gateway Fabric (NGF):
– The successor to Ingress NGINX
– Built directly around Gateway API
– Still maturing but a strong long‑term candidate

If you are interested, you can read the more exhaustive list of Ingress controllers.

Installing an Alternative Ingress Controller on OVHcloud MKS

We will show you how to install Traefik, as an alternative Ingress controller and use it to spawn a single OVHcloud Public Cloud Load Balancer (based on OpenStack Octavia).

Install Traefik:

helm repo add traefik https://traefik.github.io/charts
helm repo update

helm install traefik traefik/traefik --namespace traefik --create-namespace --set service.type=LoadBalancer

This automatically triggers:
– the OpenStack CCM (used by OVHcloud)
– the creation of an OVHcloud Public Cloud Load Balancer
– exposure of Traefik through a public IP

After several seconds, the Load Balancer will be active.

Check that Traefik is running:

$ kubectl get all -n traefik
NAME                           READY   STATUS    RESTARTS   AGE
pod/traefik-6777c5db85-pddd6   1/1     Running   0          31s

NAME              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/traefik   LoadBalancer   10.3.129.188   <pending>     80:30267/TCP,443:30417/TCP   31s

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/traefik   1/1     1            1           31s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/traefik-6777c5db85   1         1         1       31s

Then in order to use it, create an ingress.yaml file with the following content:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "traefik"  # Specifies Traefik as the ingress controller
spec:
  rules:
    - host: my-app.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

And apply it in your cluster:

kubectl apply -f ingress.yaml

Using this type of alternative provides a fully supported, modern Ingress Controller while you prepare a long‑term transition to the Gateway API.

Gateway API: A modern, flexible networking model

The Gateway API is the next-generation Kubernetes networking specification. It introduces clearer roles and more flexible architectures.

Gateway API splits responsibilities across:
– GatewayClass: defines the type of gateway and which controller manages it
– Gateway: the actual entry point (e.g., a Load Balancer)
– Routes: routing rules, protocol-specific (HTTPRoute, TLSRoute, GRPCRoute, TCPRoute…)

Gateway API supports:
– HTTP(S)
– HTTP/2
– gRPC
– TCP
– TLS passthrough
…in a consistent and portable way.

Unlike Ingress, Gateway API is explicitly designed to allow providers like OVHcloud, AWS, GCP, Azure to:
– provision Load Balancers (LB)
– manage listeners
– expose multiple ports
– integrate with their LB features
This paves the way for native OVHcloud GatewayClass support.

How does it work today on OVHcloud MKS?

OVHcloud MKS relies on the OpenStack Cloud Controller Manager (CCM) to provision OVHcloud Public Cloud Load Balancers in response to a Service of type LoadBalancer.

Since MKS does not yet include a native GatewayClass, you can use Gateway API today as follows:

1. You deploy an existing Gateway Controller (Envoy Gateway, Traefik, Contour/Envoy…) and its GatewayClass.
2. The controller deploys a Data Plane proxy inside the cluster.
3. To expose that proxy, you still have to create a Service of type LoadBalancer (and your app of course).
4. The CCM provisions an OVHcloud Public Cloud Load Balancer and forwards traffic to your proxy.

Thanks to that, you will have a fully functional Gateway API. The workflow is very similar to that which is required for using NGINX Ingress controller.

Using the Gateway API on OVHcloud MKS today

You can already use the Gateway API by deploying your preferred controller.

Here’s an example using Envoy Gateway, one of the most future-proof options.

Install Gateway API CRDs:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

Deploy Envoy Gateway:

helm install eg oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

You should have a result like this:

$ helm install eg oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

Pulled: docker.io/envoyproxy/gateway-helm:1.6.0
Digest: sha256:5c55e7844ae8cff3152ca00330234ef61b1f9fa3d466f50db2c63a279f1cd1df
NAME: eg
LAST DEPLOYED: Mon Dec  1 16:27:07 2025
NAMESPACE: envoy-gateway-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
**************************************************************************
*** PLEASE BE PATIENT: Envoy Gateway may take a few minutes to install ***
**************************************************************************

Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway.

Thank you for installing Envoy Gateway! 🎉

Your release is named: eg. 🎉

Your release is in namespace: envoy-gateway-system. 🎉

To learn more about the release, try:

  $ helm status eg -n envoy-gateway-system
  $ helm get all eg -n envoy-gateway-system

To have a quickstart of Envoy Gateway, please refer to https://gateway.envoyproxy.io/latest/tasks/quickstart.

To get more details, please visit https://gateway.envoyproxy.io and https://github.com/envoyproxy/gateway.

Check the Envoy gateway is running:

$ kubectl get po -n envoy-gateway-system
NAME                            READY   STATUS    RESTARTS   AGE
envoy-gateway-9cbbc577c-5h5qw   1/1     Running   0          16m

As a quickstart, you can install directly the GatewayClass, Gateway, HTTPRoute and an example app:

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/quickstart.yaml -n default

This command deploys a GatewayClass, a Gateway, a HTTPRoute and an app deployed in a deployment and exposed through a service:

gatewayclass.gateway.networking.k8s.io/eg created
gateway.gateway.networking.k8s.io/eg created
serviceaccount/backend created
service/backend created
deployment.apps/backend created
httproute.gateway.networking.k8s.io/backend created

As you can see, a GatewayClass have been deployed:

$ kubectl get gatewayclass -o yaml | kubectl neat
apiVersion: v1
items:
- apiVersion: gateway.networking.k8s.io/v1
  kind: GatewayClass
  metadata:
    name: eg
  spec:
    controllerName: gateway.envoyproxy.io/gatewayclass-controller
kind: List
metadata:
  resourceVersion: ""

Note that a GatewayClass is a cluster-wide resource so you don’t have to specify any namespace.

A Gateway have been deployed also:

$ kubectl get gateway -o yaml -n default | kubectl neat
apiVersion: v1
items:
- apiVersion: gateway.networking.k8s.io/v1
  kind: Gateway
  metadata:
    name: eg
    namespace: default
  spec:
    gatewayClassName: eg
    listeners:
    - allowedRoutes:
        namespaces:
          from: Same
      name: http
      port: 80
      protocol: HTTP
kind: List
metadata:
  resourceVersion: ""

A HTTPRoute also:

$ kubectl get httproute -o yaml -n default | kubectl neat
apiVersion: v1
items:
- apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: backend
    namespace: default
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: eg
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: backend
        port: 3000
        weight: 1
      matches:
      - path:
          type: PathPrefix
          value: /
kind: List
metadata:
  resourceVersion: ""

In order to retrieve the external IP (of the external Load Balancer), you just have to get information about the Gateway and export it in an environment variable:

$ kubectl get gateway eg
NAME   CLASS   ADDRESS        PROGRAMMED   AGE
eg     eg      xx.xxx.xx.xxx   True        18m

$ export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')

$ echo $GATEWAY_HOST
xx.xxx.xx.xxx

And finally, a backend service have been deployed with its deployment:

$ kubectl get pod,svc -l app=backend -n default
NAME                           READY   STATUS    RESTARTS   AGE
pod/backend-765694d47f-zr6hh   1/1     Running   0          21m

NAME              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/backend   ClusterIP   10.3.114.179   <none>        3000/TCP   21m

In order to create your own Gateway and *Route resources, don’t hesitate to take a look at the Gateway API website.

Conclusion

Two migration paths are currently available for OVHcloud MKS users:

• Short-term: switch to a modern Ingress Controller (Traefik, Contour, HAProxy, NGF…). It provides full support for current Ingress usage, without requiring API changes.
• Long-term: adopt the Gateway API. Gateway API brings multi‑protocol support, clearer separation of roles, and is the strategic direction of Kubernetes networking.

Which approach and which tool should you choose? Well, it’s up to you, depending on your use cases, your teams, your needs… 🙂

As we have seen in this blog post, OVHcloud MKS users can begin adopting these technologies today, safely and incrementally.

This ecosystem is evolving quickly, so stay tuned to find out about the coming release of a pre-installed official GatewayClass (based on OpenStack Octavia) 💪.

Secrets resources in Kubernetes help us keep sensitive information like logins, passwords, tokens, credentials and certificates secure. But just a heads up: Secrets in Kubernetes are base64 encoded, not encrypted so anyone can read and decode them if they know how.

The good news is that OVHcloud has just launched the Secret Manager Beta, which you can use within your Kubernetes clusters via the External Secrets Operator (ESO) 🎉.

External Secrets Operator

The External Secrets Operator (ESO) extends Kubernetes with Custom Resource Definitions (CRDs) ) that define where secrets are and how to sync them.

The controller retrieves secrets from an external API and creates Kubernetes Secrets. If the secret changes in the external API, the controller updates the secret in the Kubernetes cluster.

Basically, the ESO can connect to an external Secret Manager like OVHcloud, Vault, AWS, or GCP using a (Cluster)SecretStore, and an ExternalSecret to figure out which Secret it needs to fetch. It then creates a Secret in the Kubernetes cluster with the fetched secret’s value.

Plus, it can sync secrets across all the namespaces in your Kubernetes cluster (I love this feature ❤️):

You can use External Secrets with different Providers, including AWS Secrets Manager, HashiCorp Vault, Google Secret Manager. In this blog I’ll show you how to create a secret in the new OVHcloud Secret Manager using Hashicorp Vault.

For more details, read the ESO official documentation.

Let’s jump in!

Create an IAM local user

To fetch secrets in Secret Manager, you’ll need an IAM user with the right permissions. You can either set it up or use an existing one.

In the OVHcloud Control Panel (UI), go to ‘Identity and Access Management’, then ‘Identities’.

Click the ‘Add user’ button to create an IAM local user and complete the fields as shown below:

Quick note, I’ve named the user ‘secretmanager-’ followed by the ID of the OKMS domain I want to use.

The user needs to be an ADMIN, or, ideally, have the following policies:

okms:apikms:secret/create
okms:apikms:secret/version/getData
okms:apiovh:secret/get

Get the Personal Access Token (PAT)

The ESO ClusterSecretStore needs the permission to fetch secrets from Secret Manager, so you’ll need a token (PAT).

You can access it via our API, which you’ll find here: https://eu.api.ovh.com/console/?section=%2Fme&branch=v1#post-/me/identity/user/-user-/token

Path parameters

user: secretmanager-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx

Request body:

{
  "description": "PAT secretmanager-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx",
  "name": "pat-secretmanager-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx"
}

You should obtain a response like this:

{
  "creation": "2025-11-07T14:02:56.679157188Z",
  "description": "PAT secretmanager-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx",
  "expiresAt": null,
  "lastUsed": null,
  "name": "pat-secretmanager-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx",
  "token": "eyJhbGciOiJ...punpVAg"
}

Save the token value, because you’ll need it in a bit.

Create a secret in the Secret Manager

Here’s how to create a secret with OVHcloud MPR credentials for use in Kubernetes cluster(s).

In the OVHcloud Control Panel (UI), go to ‘Secret Manager’, then create a secret ‘prod/va1/dockerconfigjson’ in the Europe region (France – Paris) eu-west-par:

You’ll need to activate the region if you’re selecting it for the first time:

Select an OKMS domain:

Enter the path and value of your secret. For example:

Your secret is all set!

Install External Secrets Operators on your cluster

Deploy external secret through Helm:

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

Install from the chart repository:

helm install external-secrets \
   external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --set installCRDs=true

Your result should look something like this:

$ helm install external-secrets \
   external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --set installCRDs=true

NAME: external-secrets
LAST DEPLOYED: Mon Nov 24 17:08:58 2025
NAMESPACE: external-secrets
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
external-secrets has been deployed successfully in namespace external-secrets!

In order to begin using ExternalSecrets, you will need to set up a SecretStore
or ClusterSecretStore resource (for example, by creating a 'vault' SecretStore).

More information on the different types of SecretStores and how to configure them
can be found in our Github: https://github.com/external-secrets/external-secrets

This command will install the External Secrets Operator in your cluster.

Check ESO is running:

$ kubectl get all -n external-secrets
NAME                                                    READY   STATUS    RESTARTS   AGE
pod/external-secrets-6b9f8ff5d4-jwd6g                   1/1     Running   0          25m
pod/external-secrets-cert-controller-7bf8fd894c-d24xb   1/1     Running   0          25m
pod/external-secrets-webhook-df488ddff-2xv4t            1/1     Running   0          25m

NAME                               TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/external-secrets-webhook   ClusterIP   10.3.106.32   <none>        443/TCP   25m

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/external-secrets                   1/1     1            1           25m
deployment.apps/external-secrets-cert-controller   1/1     1            1           25m
deployment.apps/external-secrets-webhook           1/1     1            1           25m

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/external-secrets-6b9f8ff5d4                   1         1         1       25m
replicaset.apps/external-secrets-cert-controller-7bf8fd894c   1         1         1       25m
replicaset.apps/external-secrets-webhook-df488ddff            1         1         1       25m

Create a Secret contains the PAT

Encode the PAT in base64:

$ echo -n "<token>" | base64

ZXlKaG...wVkFn

Create a secret with it inside a secret.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: ovhcloud-vault-token
  namespace: external-secrets
data:
  token: ZXlKaG...wVkFn

Apply the resource in your cluster:

kubectl apply -f secret.yaml

Check that the secret have been created:

$ kubectl get secret ovhcloud-vault-token -n external-secrets
NAME                   TYPE     DATA   AGE
ovhcloud-vault-token   Opaque   1      5m

Deploy a ClusterSecretStore to connect ESO to Secret Manager

Set up a ClusterSecretStore to manage synchronisation with Secret Manager.
It will use the HashiCorp Vault provider with token auth, and the OKMS endpoint as the backend.

Create a clustersecretstore.yaml file with the content below:

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: vault-secret-store
spec:
  provider:
      vault:
        server: "https://eu-west-par.okms.ovh.net/api/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # OKMS endpoint, fill with the correct region and your okms_id
        path: "secret"
        version: "v2"
        auth:
            tokenSecretRef:
              name: ovhcloud-vault-token # The k8s secret that contain your PAT
              key: token

Keep in mind, in our example, we’ve selected the “eu-west-par” region. You can enter a different server URL, depending on your desired region.

Apply it:

kubectl apply -f clustersecretstore.yaml

Check:

$ kubectl get clustersecretstore.external-secrets.io/vault-secret-store
NAME                 AGE   STATUS   CAPABILITIES   READY
vault-secret-store   2m   Valid    ReadWrite      True

Create an ExternalSecret

Create an externalsecret.yaml file with the content below:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: docker-config-secret
  namespace: external-secrets
spec:
  refreshInterval: 30m
  secretStoreRef:
    name: vault-secret-store
    kind: ClusterSecretStore
  target:
    template:
      type: kubernetes.io/dockerconfigjson
      data:
        .dockerconfigjson: "{{ .mysecret | toString }}"
    name: ovhregistrycred
    creationPolicy: Owner
  data:
  - secretKey: mysecret
    remoteRef:
      key: prod/va1/dockerconfigjson

Apply it:

$ kubectl apply -f externalsecret.yaml
externalsecret.external-secrets.io/docker-config-secret created

Check:

$ kubectl get externalsecret.external-secrets.io/docker-config-secret -n external-secrets
NAME                   STORETYPE            STORE                REFRESH INTERVAL   STATUS         READY
docker-config-secret   ClusterSecretStore   vault-secret-store   30m0s              SecretSynced   True

After applying this command, it will create a Kubernetes Secret object.

$ kubectl get secret -n external-secrets
NAME                                     TYPE                             DATA   AGE
...
ovhregistrycred                          kubernetes.io/dockerconfigjson   1      17d
...

As you can see, the Secret is ready, and you can now use it as an imagePullSecret in your Pods!

Conclusion

In this blog, we’ve explained how to create secrets in the new OVHcloud Secret Manager and integrate them directly in your Kubernetes clusters using the ESO Vault provider.

And here’s some great news: our teams are working on an OVHcloud External Secret Operator, set to go live in the coming months, which you can use 🎉.

Stay tuned and share your thoughts!

Since this summer, it’s possible to create encrypted OVHcloud Block Storage with OMK (OVHcloud managed key) in RBX, SBG, Paris & BHS regions. More regions will come in the coming months 💪.

And the good news is that you can use encrypted Block Storage using Persistent Volumes in your OVHcloud Managed Kubernetes Service (MKS) clusters 🎉.

In this post, we’ll show you how to encrypt persistent volumes on an OVHcloud Managed Kubernetes (MKS) cluster using a csi-cinder-high-speed-gen2-luks Storage Class. Leveraging LUKS-based encryption at the storage layer, you’ll learn how to protect your data at rest without sacrificing the performance of NVMe-backed volumes.

We’ll guide you step by step: defining the Storage Class, creating a Persistent Volume Claim (PVC), and deploying a Pod that mounts the encrypted volume.

This practical walkthrough is designed for developers and platform engineers looking to secure their Kubernetes workloads on OVHcloud in a straightforward way.

How to

You will create a Persistent Volume Claim (PVC), linked to a Storage Class, that will automatically create a Persistent Volume (PV) that will automatically create an associated encrypted Public Cloud Block Storage volume.
Then you will create a Pod attached to the PVC.

Let’s create an encrypted Persistent Volume in our OVHcloud MKS cluster

Prerequisite: Have an OVHcloud MKS cluster.

First, create a csi-cinder-high-speed-gen2-luks.yaml file with the following content:

💡 Note that if you deploy in on a MKS 1AZ cluster (instead of my 3AZ MKS cluster), you should define the volumeBindingMode to Immediate instead.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-cinder-high-speed-gen2-luks
allowVolumeExpansion: true
parameters:
  fsType: ext4
  type: high-speed-gen2-luks
provisioner: cinder.csi.openstack.org
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer 

This StorageClass is using the same configuration as existing csi-cinder-high-speed-gen2 but with the high-speed-gen2-luks type.

So the result will be the usage of SSD disks with NVMe interfaces encrypted with LUKS (Linux Unified Key Setup) which is a standard on-disk format for hard disk encryption.

Apply the manifest file:

kubectl apply -f csi-cinder-high-speed-gen2-luks.yaml

⚠️ You can’t modify the volumeBindingMode value for an existing Storage Class, you have to delete it and create a new one.

List the Storage Classes in the cluster:

$ kubectl get sc
NAME                              PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
csi-cinder-high-speed (default)   cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   33d
csi-cinder-high-speed-gen-2       cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   33d
csi-cinder-high-speed-gen2-luks   cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   4s

Create a pvc-luks.yaml file with the following content:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-luks
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: csi-cinder-high-speed-gen2-luks

Create a new namespace and apply the manifest file into it:

kubectl create ns test-pvc-luks
kubectl apply -f pvc-luks.yaml -n test-pvc-luks

Check the status of our newly created PVC:

$ kubectl get pvc -n test-pvc-luks
NAME       STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS                      VOLUMEATTRIBUTESCLASS   AGE
pvc-luks   Pending                                      csi-cinder-high-speed-gen2-luks   <unset>                 3s


$ kubectl describe pvc pvc-luks -n test-pvc-luks
Name:          pvc-luks
Namespace:     test-pvc-luks
StorageClass:  csi-cinder-high-speed-gen2-luks
Status:        Pending
Volume:
Labels:        <none>
Annotations:   <none>
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Used By:       <none>
Events:
  Type    Reason                Age                From                         Message
  ----    ------                ----               ----                         -------
  Normal  WaitForFirstConsumer  10s (x2 over 10s)  persistentvolume-controller  waiting for first consumer to be created before binding
$ kubectl describe pvc pvc-luks
Name:          pvc-luks
Namespace:     test-pvc-luks
StorageClass:  csi-cinder-high-speed-gen2-luks
Status:        Pending
Volume:
Labels:        <none>
Annotations:   <none>
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Used By:       <none>
Events:
  Type    Reason                Age                From                         Message
  ----    ------                ----               ----                         -------
  Normal  WaitForFirstConsumer  10s (x2 over 10s)  persistentvolume-controller  waiting for first consumer to be created before binding

As you can see, your PVC have been creating, with the luks Storage Class, and is Pending to be Bound, until the creation of a Pod with a volume (because of the WaitForFirstConsumer value):

Create a pod.yaml file with the following content:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-encrypted-volume
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: encrypted-volume
  volumes:
  - name: encrypted-volume
    persistentVolumeClaim:
      claimName: pvc-luks

Create a new namespace and apply the manifest file into it:

kubectl apply -f pod.yaml -n test-pvc-luks

The PVC should now be Bound and a new PV should be created:

$ kubectl get pvc -n test-pvc-luks
NAME       STATUS   VOLUME                                                                     CAPACITY   ACCESS MODES   STORAGECLASS                      VOLUMEATTRIBUTESCLASS   AGE
pvc-luks   Bound    ovh-managed-kubernetes-siti343p-pvc-3a3b1d2e-ebdf-41a2-8f8f-4ee6984b6149   10Gi       RWO            csi-cinder-high-speed-gen2-luks   <unset>                 3m27s

$ kubectl get pv -n test-pvc-luks
NAME                                                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS                      VOLUMEATTRIBUTESCLASS   REASON   AGE
ovh-managed-kubernetes-siti343p-pvc-3a3b1d2e-ebdf-41a2-8f8f-4ee6984b6149   10Gi       RWO            Delete           Bound    test-pvc-luks/pvc-luks   csi-cinder-high-speed-gen2-luks   <unset>                          32s

First the Pod should be in ContainerCreating state (waiting the creation and the attachment of the volume) and after few seconds it will be Running:

$ kubectl get pod pod-with-encrypted-volume -n test-pvc-luks
NAME                        READY   STATUS              RESTARTS   AGE
pod-with-encrypted-volume   0/1     ContainerCreating   0          44s

# Wait a little...

$ kubectl get pod pod-with-encrypted-volume -n test-pvc-luks
NAME                        READY   STATUS    RESTARTS   AGE
pod-with-encrypted-volume   1/1     Running   0          2m10s

The Pod is now created with an attached volume:

$ kubectl describe pod pod-with-encrypted-volume -n test-pvc-luks
Name:             pod-with-encrypted-volume
Namespace:        test-pvc-luks
Priority:         0
Service Account:  default
Node:             my-pool-zone-c-h5xjf-7n7kt/192.168.142.174
Start Time:       Tue, 19 Aug 2025 10:10:41 +0200
Labels:           <none>
Annotations:      <none>
Status:           Running
IP:               10.240.0.203
IPs:
  IP:  10.240.0.203
Containers:
  nginx:
    Container ID:   containerd://c38c0a0e19970503ad1bfaa0c74b5cc320cb9df08456c7613b9a9a8c908b9190
    Image:          nginx
    Image ID:       docker.io/library/nginx@sha256:33e0bbc7ca9ecf108140af6288c7c9d1ecc77548cbfd3952fd8466a75edefe57
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Tue, 19 Aug 2025 10:11:42 +0200
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /usr/share/nginx/html from encrypted-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vbcnk (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       True
  ContainersReady             True
  PodScheduled                True
Volumes:
  encrypted-volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  pvc-luks
    ReadOnly:   false
  kube-api-access-vbcnk:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age                    From                     Message
  ----     ------                  ----                   ----                     -------
  Normal   Scheduled               3m48s                  default-scheduler        Successfully assigned test-pvc-luks/pod-with-encrypted-volume to my-pool-zone-c-xxxx-xxxx
  ...
  Normal   SuccessfulAttachVolume  3m8s                   attachdetach-controller  AttachVolume.Attach succeeded for volume "ovh-managed-kubernetes-siti343p-pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  Normal   Pulling                 2m53s                  kubelet                  Pulling image "nginx"
  Normal   Pulled                  2m48s                  kubelet                  Successfully pulled image "nginx" in 5.072s (5.072s including waiting). Image size: 72324501 bytes.
  Normal   Created                 2m48s                  kubelet                  Created container: nginx
  Normal   Started                 2m48s                  kubelet                  Started container nginx

Logging in the OVHcloud Control Panel, you can see that the encrypted volume have been successfully created:

Finally, you can use your volume.

Execute a shell in the Nginx Pod and create an index.html file into it:

$ kubectl exec -it pod-with-encrypted-volume -n test-pvc-luks -- /bin/bash

root@pod-with-encrypted-volume:/# echo "Hello from OVHcloud encrypted Block Storage!" > /usr/share/nginx/html/index.html

And curl the webserver:

root@pod-with-encrypted-volume:/# apt update
root@pod-with-encrypted-volume:/# apt install curl
root@pod-with-encrypted-volume:/# curl http://localhost/
Hello from OVHcloud encrypted Block Storage!

🎉

What’s next?

In this blog post we saw a basic (but concrete) usage of the encrypted Persistent Volume on OVHcloud Kubernetes clusters that just bee released, don’t hesitate to think about it for your sensitive data.

In the coming months, the encrypted Block Storage will be available worldwide. Follow the Encrypted Block Volumes issue on GitHub to stay informed.

And don’t hesitate to take a look to our Cloud Roadmap & Changelog to see the state of all of the coming features in OVHcloud Public Cloud products.

When working on Infrastructure as Code projects, with Terraform or OpenTofu, Terraform States files are created and modified locally in a terraform.tfstate file. It’s a common usage and practice but not convenient when working as a team.

Do you know that you can configure Terraform to store data remotely on OVHcloud S3-compatible Object Storage?

OVHcloud Terraform/OpenTofu provider

To easily provision your infrastructures, OVHcloud provides a Terraform provider which is available in the official Terraform registry.

The provider is synchronized in the OpenTofu registry also:

Read the Infrastructure as Code (IaC) on OVHcloud – part 1: Terraform / OpenTofu blog post to have more information about the provider and IaC on OVHcloud.

Note that in the rest of the blog post we will be using terraform CLI and talking about Terraform, but you can also follow the blog post if you are using OpenTofu and tofu CLI instead 😉.

How to

In this blog post we will handle two projects:

• object-storage-tf: creation of an OVHcloud S3-compatible Object Sorage and an user and necessary policies
• my-app: usage of a backend.tf file that store and get TF states in your newly created S3-compatible bucket

Note that all the following source code are available on the OVHcloud Public Cloud examples GitHub repository.

Prerequisites:

• Install the Terraform CLI
• For non Linux users, install gettext (that included `envsubst` command)

$ brew install gettext

$ brew link --force gettext

• Get the credentials from the OVHCloud Public Cloud project

Let’s create an Object Storage with Terraform

Create a new folder, named object-storage-tf, for example and go into it.

Create a provider.tf file:

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
    }
    
    random = {
      source  = "hashicorp/random"
      version = "3.6.3"
    }
  }
}

provider "ovh" {
}

The OVHcloud Terraform provider need the endpoint, the secret keys and the Public Cloud ID that needs to be retrieved from your environment variables:

• OVH_ENDPOINT
• OVH_APPLICATION_KEY
• OVH_APPLICATION_SECRET
• OVH_CONSUMER_KEY
• OVH_CLOUD_PROJECT_SERVICE

Then, create a variables.tf.template file with the following content:

variable "service_name" {
  default = "$OVH_CLOUD_PROJECT_SERVICE"
}


variable bucket_name {
  type        = string
}

variable bucket_region {
  type        = string
  default     = "GRA"
}

Replace the value of your OVH_CLOUD_PROJECT_SERVICE environment variable in the variables.tf file (in the service_name variable):

$ envsubst < variables.tf.template > variables.tf

Define the resources you want to create in a new file called s3.tf:

resource "random_string" "bucket_name_suffix" {
  length  = 16
  special = false
  lower   = true
  upper   = false
}

resource "ovh_cloud_project_storage" "s3_bucket" {
  service_name = var.service_name
  region_name = var.bucket_region
  name = "${var.bucket_name}-${random_string.bucket_name_suffix.result}" # the name must be unique within OVHcloud
}

resource "ovh_cloud_project_user" "s3_user" {
  description	= "${var.bucket_name}-${random_string.bucket_name_suffix.result}"
  role_name	= "objectstore_operator"
}

resource "ovh_cloud_project_user_s3_credential" "s3_user_cred" {
  user_id	= ovh_cloud_project_user.s3_user.id
}

resource "ovh_cloud_project_user_s3_policy" "s3_user_policy" {
  service_name = var.service_name
  user_id      = ovh_cloud_project_user.s3_user.id
  policy = jsonencode({
    "Statement": [{
      "Action": ["s3:*"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::${ovh_cloud_project_storage.s3_bucket.name}","arn:aws:s3:::${ovh_cloud_project_storage.s3_bucket.name}/*"],
      "Sid": "AdminContainer"
    }]
  })
}

In this file we defined that we want to create a S3-compatible Object Storage bucket and an user (with its credentials) that will have the rights (policies) to do actions on this bucket.

Define the information that you want to get after the creation of the resources, in an output.tf file:

output "s3_bucket" {
  value = "${ovh_cloud_project_storage.s3_bucket.name}"
}

output "access_key_id" {
    value = ovh_cloud_project_user_s3_credential.s3_user_cred.access_key_id
}

output "secret_access_key" {
    value = ovh_cloud_project_user_s3_credential.s3_user_cred.secret_access_key
    sensitive = true
}

Now we need to initialise Terraform:

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/random versions matching "3.6.3"...
- Reusing previous version of ovh/ovh from the dependency lock file
- Installing hashicorp/random v3.6.3...
- Installed hashicorp/random v3.6.3 (signed by HashiCorp)
- Using previously-installed ovh/ovh v2.5.0

Terraform has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.

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.

Generate the plan and apply it:

$ terraform apply -var bucket_name=my-bucket

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:

  # ovh_cloud_project_storage.s3_bucket will be created
  + resource "ovh_cloud_project_storage" "s3_bucket" {
      + created_at    = (known after apply)
      + encryption    = (known after apply)
      + limit         = (known after apply)
      + marker        = (known after apply)
      + name          = (known after apply)
      + objects       = (known after apply)
      + objects_count = (known after apply)
      + objects_size  = (known after apply)
      + owner_id      = (known after apply)
      + prefix        = (known after apply)
      + region        = (known after apply)
      + region_name   = "GRA"
      + replication   = (known after apply)
      + service_name  = "xxxxxxxxxxx"
      + versioning    = (known after apply)
      + virtual_host  = (known after apply)
    }

  # ovh_cloud_project_user.s3_user will be created
  + resource "ovh_cloud_project_user" "s3_user" {
      + creation_date = (known after apply)
      + description   = (known after apply)
      + id            = (known after apply)
      + openstack_rc  = (known after apply)
      + password      = (sensitive value)
      + role_name     = "objectstore_operator"
      + roles         = (known after apply)
      + service_name  = "xxxxxxxxxxx"
      + status        = (known after apply)
      + username      = (known after apply)
    }

  # ovh_cloud_project_user_s3_credential.s3_user_cred will be created
  + resource "ovh_cloud_project_user_s3_credential" "s3_user_cred" {
      + access_key_id     = (known after apply)
      + id                = (known after apply)
      + internal_user_id  = (known after apply)
      + secret_access_key = (sensitive value)
      + service_name      = "xxxxxxxxx"
      + user_id           = (known after apply)
    }

  # ovh_cloud_project_user_s3_policy.s3_user_policy will be created
  + resource "ovh_cloud_project_user_s3_policy" "s3_user_policy" {
      + id           = (known after apply)
      + policy       = (known after apply)
      + service_name = "xxxxxxxx"
      + user_id      = (known after apply)
    }

  # random_string.bucket_name_suffix will be created
  + resource "random_string" "bucket_name_suffix" {
      + id          = (known after apply)
      + length      = 16
      + lower       = true
      + min_lower   = 0
      + min_numeric = 0
      + min_special = 0
      + min_upper   = 0
      + number      = true
      + numeric     = true
      + result      = (known after apply)
      + special     = false
      + upper       = false
    }

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

Changes to Outputs:
  + access_key_id     = (known after apply)
  + s3_bucket         = (known after apply)
  + secret_access_key = (sensitive value)

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

random_string.bucket_name_suffix: Creating...
random_string.bucket_name_suffix: Creation complete after 0s [id=4qiyj7ywrt2sspfe]
ovh_cloud_project_user.s3_user: Creating...
ovh_cloud_project_storage.s3_bucket: Creating...
ovh_cloud_project_storage.s3_bucket: Creation complete after 1s [name=my-bucket-4qiyj7ywrt2sspfe]
ovh_cloud_project_user.s3_user: Still creating... [10s elapsed]
ovh_cloud_project_user.s3_user: Creation complete after 20s [id=535967]
ovh_cloud_project_user_s3_credential.s3_user_cred: Creating...
ovh_cloud_project_user_s3_policy.s3_user_policy: Creating...
ovh_cloud_project_user_s3_credential.s3_user_cred: Creation complete after 0s [id=5ab69860beb34575acb42c7ba8553884]
ovh_cloud_project_user_s3_policy.s3_user_policy: Creation complete after 0s [id=xxxxxxxxxxx/535967]

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

Outputs:

access_key_id = "5ab69860beb34575acb42c7ba8553884"
s3_bucket = "my-bucket-4qiyj7ywrt2sspfe"
secret_access_key = <sensitive>

🎉

Save the s3 user credentials in environment variables (mandatory for the following section):

$ export AWS_ACCESS_KEY_ID=$(terraform output -raw access_key_id)
$ export AWS_SECRET_ACCESS_KEY=$(terraform output -raw secret_access_key)

Let’s configure an OVHcloud S3-compatible Object Storage as Terraform Backend

Create a new folder, named my-app, and go into it.

Create a backend.tf file with the following content:

⚠️ If you have a terraform version before 1.6.0:

terraform {
    backend "s3" {
      bucket = "<my-bucket>"
      key    = "my-app.tfstate"
      region = "gra"
      endpoint = "s3.gra.io.cloud.ovh.net"
      skip_credentials_validation = true
      skip_region_validation      = true
    }
}

⚠️ Since Terraform version 1.6.0:

terraform {
    backend "s3" {
      bucket = "<my-bucket>"
      key    = "my-app.tfstate"
      region = "gra"
      endpoints = {
        s3 = "https://s3.gra.io.cloud.ovh.net/"
      }
      skip_credentials_validation = true
      skip_region_validation      = true
      skip_requesting_account_id  = true
      skip_s3_checksum            = true
    }
}

You can replace <my-bucket> with the newly created bucket or with an existing bucket you created.

Initialise Terraform:

$ terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding latest version of ovh/ovh...
- Installing ovh/ovh v2.5.0...
- Installed ovh/ovh v2.5.0 (signed by a HashiCorp partner, key ID F56D1A6CBDAAADA5)

...

As you can see, now, terraform is using “s3” backend! 💪

Want to go further?

In this blog post, we created an S3-compatible Object Storage with basic configuration but be aware that you can configure a S3-compatible bucket with encryption, versioning and more:

💡 Terraform States are not encrypted at rest when stored by Terraform so we recommend to enable the encryption the OVHcloud S3-compatible Object Storage bucket 🙂.

Kubernetes 1.33 version has just been released few days/weeks ago.
As this new release contains 64 enhancements (!), it can not be easy to know what are the interesting and useful features and how to use them.

In this blog post, let’s discover one of interesting and useful new feature: “Topology aware routing in multi-zones Kubernetes clusters”.

⚠️ Kubernetes 1.33 should be available on OVHcloud MKS clusters at the end of June/beginning of July but the demo is working also on MKS with Kubernetes 1.32 release 😉.

Topology aware routing

Since Kubernetes 1.33, the topology aware routing and traffic distribution feature is in General Availability (GA).

This feature allows to optimize service traffic in multi-zone clusters and reduce latency and cross-zone data transfer cost.

Topology Aware Routing provides a mechanism to help keep traffic within the zone it originated from.

In a context of multi-zone clusters, it helps reliability, performance, reduce costs or improve network performance.

As OVHcloud just released, in Beta, the launch of their Managed Kubernetes clusters (MKS) on 3 AZ (Availability Zones), it’s the perfect occasion for me to test this brand new Kubernetes feature 🙂.

Demo

Prerequisite: Have a Kubernetes cluster with at least 2 nodes running in 2 different zones.

If you already don’t have one, you can follow this blog post in order to create an OVHcloud MKS cluster with 3 nodes pools, one per AZ.

On my side I set-up a MKS cluster in 3AZ (one per node pool), with 3 nodes per node pool:

$ kubectx kubernetes-admin@multi-zone-mks
Switched to context "kubernetes-admin@multi-zone-mks".

$ kubectl get np
NAME             FLAVOR   AUTOSCALED   MONTHLYBILLED   ANTIAFFINITY   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   MIN   MAX   AGE
my-pool-zone-a   b3-8     false        false           false          3         3         3            3           0     100   20d
my-pool-zone-b   b3-8     false        false           false          3         3         3            3           0     100   20d
my-pool-zone-c   b3-8     false        false           false          3         3         3            3           0     100   20d

$ kubectl get no
NAME                         STATUS   ROLES    AGE   VERSION
my-pool-zone-a-b9ztj-brgpq   Ready    <none>   20d   v1.32.3
my-pool-zone-a-b9ztj-gt5vd   Ready    <none>   20d   v1.32.3
my-pool-zone-a-b9ztj-mss8j   Ready    <none>   20d   v1.32.3
my-pool-zone-b-tr6wf-5wfgz   Ready    <none>   20d   v1.32.3
my-pool-zone-b-tr6wf-ct7fs   Ready    <none>   20d   v1.32.3
my-pool-zone-b-tr6wf-vlkwg   Ready    <none>   20d   v1.32.3
my-pool-zone-c-wgrl6-b2f9s   Ready    <none>   20d   v1.32.3
my-pool-zone-c-wgrl6-lp22l   Ready    <none>   20d   v1.32.3
my-pool-zone-c-wgrl6-slkq5   Ready    <none>   20d   v1.32.3

⚠️ As you saw, the Kubernetes version installed on my cluster is not equals to 1.33, but the ServiceTrafficDistribution feature gate is in Beta and it is activated:

$ kubectl get --raw /metrics | grep kubernetes_feature_enabled | grep Traffic

kubernetes_feature_enabled{name="ServiceTrafficDistribution",stage="BETA"} 1

A visual architecture of my MKS cluster:

⚠️ In MKS Standard clusters, don’t forget to enable the topology aware routing for 3AZ region.

In order to test this feature, in a new namespace, we will deploy:

• a deployment with two pods named receiver-xxx
• a ClusterIP service named svc-prefer-close with the feature enabled
• a Pod named sender

Let’s do that!

Create a deploy.yaml file with the following content:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: service-traffic-example
  name: receiver
  namespace: prefer-close
spec:
  replicas: 2
  selector:
    matchLabels:
      app: service-traffic-example
  template:
    metadata:
      labels:
        app: service-traffic-example
    spec:
      containers:
      - image: scraly/hello-pod:1.0.1
        name: receiver
        ports:
        - containerPort: 8080
        env:
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName

Create a svc.yaml file with the following content:

apiVersion: v1
kind: Service
metadata:
  name: svc-prefer-close
  namespace: prefer-close
  annotations:
    service.kubernetes.io/topology-mode: auto
spec:
  ports:
    - name: http
      protocol: TCP
      port: 8080
      targetPort: 8080
  selector:
    app: service-traffic-example
  type: ClusterIP
  trafficDistribution: PreferClose

As you can see, this Service has two specific configurations.
First, we added the service.kubernetes.io/topology-mode: auto annotation to enable Topology Aware Routing for a Service.
Then, we configured the trafficDistribution to PreferClose in order to ask Kubernetes to send the traffic, preferably, to a pod that is “closed” to the sender.

Create a new namespace and apply the manifest files:

$ kubectl create ns prefer-close
$ kubectl apply -f deploy.yaml
$ kubectl apply -f svc.yaml

Result:
You should have two running Pods on 2 differents Nodes.

$ kubectl get po -o wide -n prefer-close

NAME                        READY   STATUS              RESTARTS   AGE   IP            NODE                         NOMINATED NODE   READINESS GATES
receiver-7cfd89d78d-dhv6z   1/1     Running             0          94s   10.240.4.91   my-pool-zone-c-wgrl6-slkq5   <none>           <none>
receiver-7cfd89d78d-hrxrt   1/1     Running             0          94s   10.240.5.63   my-pool-zone-a-b9ztj-mss8j   <none>           <none>

OK, receiver-xxxxxxxx-dhv6z is running on my-pool-zone-c-xxxx and the other pod is running on my-pool-zone-a-xxxx. There are running on differents Availability Zones.

Now, we can create a Pod sender. it will be scheduled on a Node:

Run it and execute a curl command to test the traffic redirection to the “svc-prefer-close” Service:

$ kubectl run sender -n prefer-close --image=curlimages/curl -it -- sh
If you don't see a command prompt, try pressing enter.
~ $ curl http://svc-prefer-close.prefer-close:8080
Version: 1.0.1
Hostname: receiver-7cfd89d78d-dhv6z
Node: my-pool-zone-c-wgrl6-slkq5

Let’s verify where are our Pods:

$ kubectl get po -n prefer-close -o wide
NAME                        READY   STATUS    RESTARTS     AGE   IP             NODE                         NOMINATED NODE   READINESS GATES
receiver-7cfd89d78d-dhv6z   1/1     Running   0            9d    10.240.4.91    my-pool-zone-c-wgrl6-slkq5   <none>           <none>
receiver-7cfd89d78d-hrxrt   1/1     Running   0            9d    10.240.5.63    my-pool-zone-a-b9ztj-mss8j   <none>           <none>
sender                      1/1     Running   1 (5s ago)   21s   10.240.3.134   my-pool-zone-c-wgrl6-b2f9s   <none>           <none>

Kube-proxy sent the traffic from sender to a receiver-xx Pod on the same Availability Zone 🎉

⚠️ Note that because preferClose means “topologically proximate”, it may vary across implementations and could encompass endpoints within the same node, rack, zone, or even region.

How is it working?

When calculating the endpoints for a Service, the EndpointSlice controller considers the topology (region and zone) of each endpoint and populates the hints field to allocate it to a zone.

Cluster components such as kube-proxy can then consume those hints, and use them to influence how the traffic is routed (favoring topologically closer endpoints).

So, with PreferClose value for trafficDistribution, we ask kube-proxy to redirect traffic to the nearest available endpoints based on the network topology.

That’s why the option is called PreferClose.

What’s next?

In the future you will be able to configure the trafficDistribution field with other values.

Indeed, two new values, more explicit, are currently in Alpha since the Kubernetes 1.33 release: PreferSameZone and PreferSameNode.

Personally I can’t wait to test them 😇.

Want to go further?

Want to learn more on this topic? In the coming days, we will publish a blog post about MKS Premium plan.

Visit our Managed Kubernetes Service (MKS) Premium plan in the OVHcloud Labs website to know more about Premium MKS.

Join the free Beta: https://labs.ovhcloud.com/en/managed-kubernetes-service-mks-premium-plan/

Read the documentation about the new Managed Kubernetes Service (MKS) Premium plan.

Join us on Discord and give us your feedbacks.