ayedo Kubernetes Distribution: CNCF-compliant, EU-sovereign, compliance-ready

TL;DR

• The ayedo Kubernetes Distribution offers two distinct operational variants: Loopback for European public clouds and a k3s-based solution for on-premises and enterprise environments – both based on CNCF-certified / CNCF-compliant Kubernetes.
• CNCF compliance ensures API compatibility, avoids lock-in through proprietary extensions, and lays the foundation for portability between clouds, data centers, and providers.
• By operating in EU data centers (Germany, Finland) and embedding into a structured Cloud-Sovereignty-Framework, your organization can consistently address technical sovereignty, data protection requirements, and regulatory mandates.
• Pre-configured platform services like Cilium, VictoriaMetrics/VictoriaLogs, Harbor, Keycloak, Kyverno, Cert-Manager, and Velero form an integrated foundation for security, observability, and resilience – a crucial component for modern compliance.
• ayedo combines these components into a curated, European Kubernetes Distribution, providing a robust, compliance-ready foundation for your own platform – whether in the public cloud or on-premises.

Why a European, CNCF-compliant Kubernetes Distribution?

Today, those responsible for infrastructure and application operations face dual pressures: Teams must quickly and flexibly roll out new services, while regulatory, data protection, and internal governance requirements are increasing.

This is where a CNCF-compliant, European Kubernetes Distribution comes in. It provides:

• a standardized, portable runtime environment for containerized workloads
• a strong foundation for automation and platform operations
• a clear framework to technically implement requirements from GDPR, NIS2 (effective October 17, 2024), DORA, and industry-specific mandates

The ayedo Kubernetes Distribution is deliberately lean but consistently curated. It forms the technical basis of the ayedo platform and can also be operated independently if you “only” need a solid, sovereign Kubernetes foundation.

Two Deployment Variants with a Common Architecture

Both variants of the distribution follow the same goal: Production-ready, CNCF-compliant Kubernetes with clearly defined operational processes – once in European public clouds, once in your own data center or on enterprise infrastructure.

Loopback: European Public Cloud without Lock-in

With Loopback, you operate Kubernetes clusters on European cloud providers and major hyperscalers (in European regions) without getting caught up in proprietary managed Kubernetes dialects.

Key features:

• CNCF-compliant Control Plane: Clusters are based on upstream Kubernetes. API compatibility and standard behavior are ensured.
• Multi-Cloud Capability: Hetzner, IONOS, OVHcloud, Scaleway, as well as AWS, Azure, Google Cloud in EU regions – you can choose the appropriate provider depending on the use case.
• Managed Control Plane: Operation, high availability, and updates of the control plane are outsourced. Your teams focus on workloads and platform services.
• Fast Provisioning: Clusters are created in minutes, facilitating proof-of-concepts, test environments, and scalable production setups alike.

This means for you: You leverage the elasticity and ecosystem of the public cloud while maintaining technical control in a standardized Kubernetes world. A later switch of providers or a transition to an on-premises variant is thus realistically plannable.

k3s: On-Premises and Enterprise, Sovereignly Operated

The second variant of the distribution is based on k3s, a lightweight, CNCF-certified Kubernetes distribution from SUSE. It is optimized for:

• traditional on-premises data centers
• regulated high-security environments (including air-gapped)
• edge or IoT scenarios with limited resources
• companies needing full control over infrastructure and data paths

Key characteristics:

• Resource Efficient: k3s reduces overhead without sacrificing CNCF compliance – ideal for edge and dense consolidation.
• Flexible Deployment: Bare metal, virtual machines, dedicated clusters per zone or location – the distribution adapts to your topology.
• Enterprise Integration: OIDC/SAML via IdPs like Keycloak, private registries, air-gap scenarios, and strict network segmentation are integral parts of the architecture.

Both variants – Loopback and k3s – follow the same concepts and API standards. This reduces cognitive load in your teams and creates real portability: Policies, CI/CD pipelines, and deployment manifests work in both worlds with minimal adjustments.

CNCF Compliance as a Foundation for Portability and Compliance

CNCF compliance is more than a label: It is a technical assurance that certain interfaces, behaviors, and compatibilities are adhered to. For you as a responsible party, this results in three key advantages.

1. Clear Exit Strategy and Multi-Cloud Options

Standardized Kubernetes APIs enable the migration of workloads between different environments:

• between different public clouds
• between public cloud and on-premises
• between different infrastructure-level providers

This portability is not just a technical convenience but a governance issue: You create a robust exit strategy and strengthen your negotiating position with individual providers.

2. Reusable Security and Compliance Concepts

A unified, CNCF-compliant foundation allows security and compliance concepts to be developed cleanly once and then reused: Policies, network segmentation, observability standards, and backup strategies become reusable building blocks.

In combination with policy engines like Kyverno (more on that shortly), you can:

• Define mandatory security standards centrally
• Enforce these standards across multiple cluster environments
• Automatically detect deviations and – where appropriate – block them

Especially in the context of compliance in regulated industries, this reusability is a significant efficiency lever.

3. Reduced Complexity in Tooling

CNCF compliance also means: The ecosystem around Kubernetes – from the ingress controller to the service mesh – functions as expected. You can rely on a wide range of open-source and enterprise tools without having to maintain special solutions for proprietary platforms.

EU Sovereignty: Data Centers, Data Flows, and Governance

Technical portability is only half the battle. The second pillar of the ayedo Kubernetes Distribution is EU sovereignty – understood as a combination of infrastructure location, data flows, and governance processes.

EU Data Centers in Germany and Finland

The distribution can be operated in European data centers, particularly in:

• Germany
• Finland

This makes it significantly easier to address requirements from GDPR, BDSG, and country-specific regulatory authorities. You maintain control over:

• where data is processed
• which jurisdiction applies in case of conflict
• which third countries have no direct access to data or metadata

In conjunction with our Cloud-Sovereignty-Framework, this creates a structured model that aligns technical architecture, operational processes, and legal requirements.

Sovereignty as a Design Principle, Not an Add-on

Sovereignty is not a retrofitted “feature” in the ayedo Distribution but a design principle:

• Transparent Data Paths: Clear documentation of which components run where and what data they process.
• Open Components: Focus on open-source building blocks with transparent governance (e.g., CNCF, Linux Foundation).
• Internal Control Capabilities: Logging, auditing, and policy enforcement are designed to make internal and external audits realistically feasible.

For you as a responsible party, this means: You can not only promise sovereignty but also technically substantiate it.

Platform Services in Detail: Security, Observability, Resilience

Beyond the mere Kubernetes cluster, the ayedo Kubernetes Distribution brings a curated selection of platform services that are practically always needed in modern environments. These components are chosen to seamlessly integrate into a compliance-oriented operational model.

Cilium: Network, Security, and Transparency

Cilium acts as a CNI (Container Network Interface) and offers:

• Kubernetes-native network connectivity
• fine-grained network policies based on identities rather than just IPs
• deep observability for network traffic between services

Especially in segmented, regulated environments, the ability to isolate services logically rather than just by IP is a crucial security gain. Cilium supports you in gradually implementing zero-trust architectures practically.

VictoriaMetrics / VictoriaLogs: Consistently Capture Metrics and Logs

VictoriaMetrics and VictoriaLogs together form the backbone for:

• scalable metric collection (cluster, applications, infrastructure)
• structured log storage and analysis

For audits and internal compliance requirements, it is essential that:

• technical events are recorded in a traceable manner
• retention times and access controls are definable
• correlation across metrics and logs is possible

The distribution integrates these building blocks so that observability is not seen as an afterthought project but as an inherent part of the platform.

Harbor: Container Registry with Supply-Chain Security

Harbor is an enterprise-capable container registry and a central element of the software supply chain in the distribution:

• signing and verification of container images
• vulnerability scanning and policy-based admission
• multi-tenancy and fine-grained rights management

This lays the foundation for technically anchoring requirements from supply chain regulation and internal security policies: Only verified, signed images make it into production.

Keycloak: Identity, SSO, and Central Authentication

Keycloak acts as a central identity provider:

• SSO for platform and application access
• integration with existing directory services (e.g., LDAP, Active Directory)
• OIDC / SAML for modern applications and Kubernetes APIs

In combination with Kubernetes RBAC, you define:

• who can administer which clusters and namespaces
• how self-service functions can be securely provided
• what audit trails are created during administrative actions

Kyverno: Policies as Code for Kubernetes

Kyverno is a policy engine specifically developed for Kubernetes. In the distribution, it serves as a central building block for governance and compliance:

• validating deployments against security standards (e.g., no “latest” tag, no privileged containers)
• mutating policies to automatically enforce standards (e.g., sidecar injection, default labels)
• generation rules to standardize resources (e.g., default network policies, resource quotas)