Breaking the Cloud Lock-In: Complete OVHcloud Automation via Crossplane Provider OVH 2.17.0

Managing infrastructure across European sovereign cloud providers used to mean choosing between brittle Terraform glue code or sacrificing true Kubernetes-native state reconciliation. The release of provider-ovh 2.17.0 changes everything by delivering 100% full OVHcloud schema coverage natively inside Crossplane control planes.

---

The Problem Everyone Ignores

For years, platform engineering teams deploying workloads on OVHcloud faced a painful reality: incomplete provider coverage forced engineers into writing custom shell wrappers or maintaining hybrid, multi-engine pipelines. When your control plane natively reconciles 80% of your resources but leaves the remaining 20% to manual scripts or legacy Terraform state files, your infrastructure drift detection completely breaks down.

I watched a production cluster drop traffic for three hours last quarter simply because a private API Gateway endpoint had to be provisioned outside our declarative GitOps pipeline using an unversioned Terraform module. The state drift went completely unnoticed until an automated deployment overwrote critical network routes.

When your provider lacks full schema coverage, you end up building custom CRDs and maintenance overhead just to bridge basic gaps like advanced Public Cloud networking, IAM roles, or managed DBaaS parameters.

---

What Actually Works

The true fix is moving away from fragmented provisioning mechanisms and adopting a fully unified Control Plane architecture using Crossplane Provider OVH 2.17.0. By leveraging Upjet's modern schema generation pipelines, version 2.17.0 maps every single OVHcloud API resource and sub-property directly into Kubernetes Custom Resource Definitions (CRDs).

This architecture gives you continuous reconciliation loops, unified GitOps workflows via ArgoCD or Flux, and native secret management without touching external orchestration engines.

Here is how you define a complete, production-grade OVHcloud Managed Kubernetes (MKS) cluster alongside a private network infrastructure using pure Kubernetes manifests:

apiVersion: kube.ovh.crossplane.io/v1alpha1
kind: Cluster
metadata:
  name: prod-par-cluster-01
  namespace: crossplane-system
spec:
  forProvider:
    serviceName: "1234567890abcdef1234567890abcdef"
    region: "PAR8"
    name: "prod-par-cluster-01"
    version: "1.29"
    customization:
      apiServer:
        admissionPlugins:
          enabled:
            - "NodeRestriction"
            - "AlwaysPullImages"
  providerConfigRef:
    name: ovh-provider-config
---
apiVersion: cloudproject.ovh.crossplane.io/v1alpha1
kind: NetworkPrivate
metadata:
  name: prod-private-network
spec:
  forProvider:
    serviceName: "1234567890abcdef1234567890abcdef"
    name: "prod-vnet-paris"
    regions:
      - "PAR8"
    vlanId: 100
  providerConfigRef:
    name: ovh-provider-config

This single manifest triggers Crossplane to asynchronously provision a secure, enterprise-grade Managed Kubernetes cluster attached directly to a dedicated private VLAN inside OVHcloud's Paris datacenters.

---

Step-by-Step: Let's Build It Together

Let's walk through building a complete cloud environment from scratch using Provider OVH 2.17.0.

Step 1: Install and Configure the Provider Credentials

First, we need to deploy the provider package into our Crossplane control plane and supply the required OVHcloud API credentials via a secure Kubernetes Secret.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-ovh
spec:
  package: xpkg.upbound.io/crossplane-contrib/provider-ovh:v2.17.0
---
apiVersion: v1
kind: Secret
metadata:
  name: ovh-credentials
  namespace: crossplane-system
type: Opaque
stringData:
  credentials: |
    {
      "application_key": "YOUR_APP_KEY",
      "application_secret": "YOUR_APP_SECRET",
      "consumer_key": "YOUR_CONSUMER_KEY",
      "endpoint": "ovh-eu"
    }

This manifest fetches the full 2.17.0 schema bundle from the registry and stores your OVH API keys in an Opaque Secret ready for consumption.

Step 2: Establish Provider Configuration

Now we create the ProviderConfig object that binds the installed provider directly to the credentials secret we just created.

apiVersion: ovh.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: ovh-provider-config
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: ovh-credentials
      key: credentials

This step activates the active API connection channel between your Crossplane operator and the OVHcloud regional endpoint.

Step 3: Provision a High-Availability Managed PostgreSQL Database

With credentials established, we deploy a high-availability PostgreSQL engine complete with automated backup policies leveraging the newly expanded DBaaS schema support.

apiVersion: dbaas.ovh.crossplane.io/v1alpha1
kind: LogsCluster
metadata:
  name: prod-db-pg-cluster
spec:
  forProvider:
    serviceName: "1234567890abcdef1234567890abcdef"
    engine: "postgresql"
    version: "15"
    plan: "business"
    nodes:
      - region: "PAR8"
      - region: "GRA11"
    flavor: "db1-7"
  providerConfigRef:
    name: ovh-provider-config

You now have a multi-region, high-availability database cluster spinning up completely managed by your Kubernetes control plane.

---

The Mistakes That Will Burn You

Even with complete schema coverage, multi-cloud platform migrations can hit severe roadblocks if key details are overlooked.

• Mistake 1: Forgetting strict API rate limit handling. OVHcloud enforces strict API quotas per consumer key; if your Crossplane reconciliation loop interval is too aggressive, your control plane will get IP-throttled immediately.
• Mistake 2: Mismatched regional availability zones. Specifying sub-resources in regions where your primary vRack network is not attached will cause silent resource creation timeouts.
• Mistake 3: Storing state secrets unencrypted. Failing to configure SealedSecrets or Vault integration for your OVH credential payloads leaves consumer secrets exposed inside the crossplane-system namespace.

---

Production Checklist

Before shipping your Crossplane OVH implementation into production, verify these critical security and performance requirements:

• Do this: Restrict OVH API consumer key permissions specifically to required endpoints instead of granting wildcards.
• Do this: Configure explicit reconcileRate parameters on your ProviderConfig to avoid hitting cloud quota limits.
• Never do this: Do not hardcode service names or project IDs inside your developer-facing compositions; abstract them using XRD claims.

---

Key Takeaways

• Provider OVH 2.17.0 introduces total schema parity across all OVHcloud API endpoints.
• Zero state drift: Continuous reconciliation loops ensure your infrastructure remains locked to Git declarative state.
• Unified tooling: Manage Kubernetes clusters, databases, and private networks through a single spec without legacy Terraform wrappers.

---

Engr. Hamza | AI & MLOps Engineer | Building autonomous systems at the edge of possibility