Featured

Kubernetes as the Independence Layer

The Terraform license change taught us: widely adopted doesn't mean truly open. Kubernetes is different—CNCF-governed with over 88,000 contributors from 8,000+ companies. Your manifests work on Scaleway, OVHcloud, Hetzner, AWS, or bare metal. This is the portability foundation that makes independence possible.

By Jurg van Vliet

Published Jul 10, 2025

What Makes a Standard vs. a Product

Before August 2023, many organisations treated Terraform as an open standard. It was widely adopted. It had a permissive license (MPL 2.0). It felt like public infrastructure.

Then HashiCorp changed the license to Business Source License (BSL). The community forked it. And we learned the difference between "widely adopted" and "truly open."

Terraform was a product: One company controlled it. That company could—and did—change the terms. The fork (OpenTofu) was possible because of the previous MPL license, but the disruption was real.

Kubernetes is a standard: Governed by the CNCF (Cloud Native Computing Foundation), part of the Linux Foundation. No single company can change its terms or direction unilaterally.

For foundational infrastructure—the layer everything else depends on—this distinction is critical.

How Kubernetes Governance Actually Works

Kubernetes isn't controlled by Google, despite Google originating the project in 2014. In 2015, Google donated Kubernetes to the CNCF, ceding control to foundation governance.

Decision-making structure:

Steering Committee: Representatives from multiple organizations (Google, Red Hat, Microsoft, VMware, independent contributors). Makes architectural decisions through consensus.

Special Interest Groups (SIGs): Domain-specific groups (SIG Network, SIG Storage, SIG Security) that own specific aspects. Anyone can participate.

Technical Oversight Committee: Governs technical processes, defines project scope, resolves disputes.

Contributors: Over 88,000 individuals from more than 8,000 companies across 44 countries. This is the second-largest open source project globally (after Linux kernel).

No single company can unilaterally:

  • Change Kubernetes license
  • Remove features other companies depend on
  • Force architectural direction
  • Monetize the project proprietary

This distributed governance creates stability. Decisions emerge from consensus, not corporate mandate.

Multiple Implementations Prove It's a Standard

Managed Kubernetes offerings:

  • Google GKE (Google Cloud)
  • AWS EKS (Amazon)
  • Azure AKS (Microsoft)
  • Scaleway Kapsule (Scaleway)
  • OVHcloud Managed Kubernetes
  • IONOS Managed Kubernetes
  • DigitalOcean Kubernetes
  • Dozens more

Self-hosted distributions:

  • OpenShift (Red Hat)
  • Rancher (SUSE)
  • K3s (lightweight Kubernetes)
  • MicroK8s (Canonical)
  • Talos (immutable infrastructure)

All of these implement the same Kubernetes API. A deployment manifest written for GKE works on Scaleway Kapsule. This is portability through standards.

What True Portability Looks Like

Our production deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: clouds-of-europe-app
  namespace: app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: app
        image: rg.fr-par.scw.cloud/clouds-of-europe/app:v1.2.3
        ports:
        - containerPort: 3000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: database-credentials
              key: url
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "1000m"
        livenessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 5

This is vanilla Kubernetes. It runs on:

  • Scaleway Kapsule (current production)
  • OVHcloud Managed Kubernetes (tested)
  • Kind (local development)
  • Any Kubernetes 1.28+ cluster

Only provider-specific element: Image registry URL (rg.fr-par.scw.cloud). Change to different registry, manifest still works.

We've actually tested this. Same manifest, different clusters, works identically. That's the value of standards.

What Breaks Portability

Provider-specific annotations:

# AWS-specific (breaks portability)
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"

# GCP-specific (breaks portability)
metadata:
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
    cloud.google.com/backend-config: "backend-config"

# Scaleway-specific (breaks portability)
metadata:
  annotations:
    service.beta.kubernetes.io/scw-loadbalancer-proxy-protocol-v2: "true"

Every provider-specific annotation is a hidden dependency you'll need to address during migration.

Proprietary storage classes:

# AWS-specific EBS storage
volumeClaimTemplates:
  spec:
    storageClassName: gp3  # AWS EBS gp3

Using cloud-specific storage classes ties you to that provider's storage implementation. Better: use generic storage class names that providers implement consistently.

Custom resource definitions (CRDs):

AWS Controllers for Kubernetes (ACK), Azure Service Operator, GCP Config Connector—these let you manage cloud resources from Kubernetes. They're also completely proprietary. Every resource defined with provider CRDs is something you can't move elsewhere.

The Portable Architecture Pattern

What we do:

1. Stick to vanilla Kubernetes APIs Use Deployment, Service, Ingress (now Gateway API), ConfigMap, Secret—the standard resources. These work everywhere.

2. Abstract provider-specific needs Need object storage? Use S3-compatible API (works on AWS S3, Scaleway Object Storage, Wasabi, self-hosted MinIO).

Need DNS? Use external-dns with standard annotations (works with Route53, Scaleway DNS, Cloudflare).

Need certificates? Use cert-manager with ACME or DNS-01 (works with Let's Encrypt on any provider).

3. Use Gateway API for routing As described in our Envoy migration article—Gateway API provides implementation-agnostic routing. Change proxy implementation without touching HTTPRoute definitions.

4. Document provider-specific choices When you must use provider-specific features, document it explicitly. Make it a conscious tradeoff, not accidental dependency.

Why This Matters for Independence

Scenario 1: Locked in You've built on AWS Lambda, DynamoDB, CloudFormation, SQS. Five years invested. AWS increases pricing 30% at renewal. You can't credibly threaten to leave—migration would cost more than paying the increase.

Scenario 2: Portable You've built on Kubernetes, PostgreSQL, RabbitMQ, OpenTofu. Five years invested on AWS. AWS increases pricing 30% at renewal. You can credibly say: "We can migrate to Scaleway in 3 months for €X cost. Will you match competitive pricing?"

Portability creates negotiating optionality. You might never migrate. But the ability to migrate changes pricing conversations.

The Kubernetes Portability Test

Can you rebuild your infrastructure on a different provider in under 1 week with 1 engineer?

If yes: you've achieved portability. Congratulations.

If no: identify what's preventing it. Provider-specific services? Proprietary APIs? Lack of documentation?

Fix these incrementally. Each improvement increases optionality and reduces lock-in risk.

Sources:

#kubernetes #portability #standards #independence #cloudsofeurope

Tags

#cloudsofeurope#independence#kubernetes#portability#standards