Edge is Not a Kubernetes Feature

Why the ayedo Edge Cloud Can Operate Independently of Any Infrastructure

Equating Edge infrastructure with Kubernetes conflates two distinct layers.

Kubernetes orchestrates workloads. An Edge Cloud controls how traffic reaches these workloads.

This separation is crucial.

The ayedo Edge Cloud forms an independent infrastructure layer between the internet and the backend. DNS, routing, load balancing, monitoring, and protection mechanisms are implemented not where an application runs, but in front of it.

Therefore, the backend can be a Kubernetes cluster. It can also be a traditional server, a VM, a managed server at another provider, or infrastructure in one’s own data center.

Edge and Compute Are Separate Layers

Technically speaking, the Edge Cloud first requires accessible backends.

Incoming traffic is received by our Edge infrastructure and then forwarded to the configured target systems. The Edge location and compute location need not be in the same data center nor operated by the same provider.

This decoupling enables heterogeneous architectures.

A company can continue to operate its existing servers while adding additional infrastructure in front of them. This includes, for example, Anycast DNS, Layer-4 load balancing, endpoint monitoring, or a web application firewall.

The application does not need to be migrated to the ayedo Compute Cloud.

Anycast Makes Entry Independent of the Backend

A central component of this architecture is Anycast.

The same IP address is announced by multiple Edge locations. The network routes a connection to a suitable point of presence. If one location fails, another can take over without needing to change DNS entries and wait for their TTLs.

The public accessibility of an application is thus decoupled from its actual compute location.

Behind this entry point, different backends can reside. The Edge Cloud manages the distribution of connections and monitors the configured endpoints.

This creates an additional availability and routing layer without having to replace the underlying infrastructure.

Security Belongs in Front of the Backend

The same principle applies to security.

A web application firewall is most effective when it sits in front of the actual application. HTTP(S) traffic can be inspected at the Edge before it reaches the backend.

Thus, the WAF does not become a feature of the server or Kubernetes cluster, but rather a preemptive protection layer.

This is architecturally significant: Additional security requirements do not automatically force a change in compute infrastructure.

Existing systems can remain in place. The additional function is added where it technically belongs: at the ingress.

Kubernetes Automates – But Is Not a Prerequisite

With Kubernetes , this architecture can be significantly more automated.

Our Edge services are therefore closely integrated with components like cert-manager, external-dns, and the Cloud Controller Manager. DNS entries, certificates, and load balancers can thus be managed or provisioned directly from Kubernetes.

However, this is an integration, not a technical requirement for the Edge Cloud.

A regular server does not require a Kubernetes cluster for traffic to be routed to it via the Edge infrastructure.

This distinction is important.

Kubernetes automates the connection to the Edge. It does not define what can run behind the Edge.

Infrastructure Must Remain Combinable

Cloud platforms are often thought of vertically: compute, network, DNS, security, and platform services come from the same provider.

This coupling is not technically necessary.

An independent Edge layer enables a different architecture: operate compute where it is technically, economically, or regulatorily sensible – and organize routing, accessibility, and protection independently.

This can be the ayedo Compute Cloud.

But it doesn’t have to be.

For us, this decoupling is an important component of sovereign infrastructure. An additional infrastructure service should not require a provider change.

The Edge Cloud decides how an application is accessible. Not where it must run.