TL;DR
Kubernetes Ingress and Edge Cloud serve different purposes. The Edge Cloud controls the public entry point, protects applications, and terminates TLS. In contrast, Kubernetes Ingress describes the routing within the cluster. A clear separation prevents duplicate rules, contradictory security configurations, and complex operational states.
Introduction
Many Kubernetes architectures treat Ingress as a complete entry layer for applications. This works technically but mixes two areas of responsibility: public network access and routing within the cluster. Once TLS, WAF, DDoS protection, and backend accessibility are additionally managed on an external edge platform, duplicate or contradictory configurations can quickly arise. A hostname can then be terminated, checked, and forwarded at multiple points. The critical architectural question is not whether Kubernetes Ingress or an Edge Cloud is used. What matters is which layer takes on which responsibility and where the respective configuration is binding.
1. Kubernetes Ingress Describes Access to Cluster Services
A Kubernetes Ingress resource is primarily a declarative description for HTTP and HTTPS routing. It maps hostnames and paths to specific services within the cluster. The resource itself does not process traffic. This task is handled by an Ingress Controller, which translates the configuration into a concrete proxy or load balancer configuration.
Thus, the core responsibility of Ingress lies within the cluster: An incoming request is forwarded after being handed over to the Kubernetes service. This includes rules like api.example.de to an API service or /checkout to a specific backend. The division between services, namespaces, or versions can also be modeled there.
This layer is closely tied to the deployment model. Changes to services, pods, and Ingress resources can be managed together via Kubernetes workflows. This is sensible as long as the task is limited to internal accessibility and routing to workloads. However, Ingress should not automatically be understood as a complete security and internet access layer.
2. The Edge Cloud Takes Over the Public Entry
The Edge Cloud is architecturally positioned in front of the cluster. It receives public traffic, distributes it via a distributed multi-PoP infrastructure, and forwards permissible connections to defined backends. At ayedo, this is done through Anycast-based Layer-4 and Layer-7 load balancing. The Edge Cloud is thus not merely a pre-configured load balancer for ayedo Managed Kubernetes but can also be deployed in front of Kubernetes clusters operated by other providers.
At this level, tasks apply that are independent of individual Kubernetes services. These include TLS termination, WAF rules, DDoS protection and scrubbing at the edge, and backend cloaking. With backend cloaking, internal target addresses remain hidden from the public client. Backend health checks and failover additionally determine if a target is reachable and where traffic is redirected in case of disruptions.
This centralization reduces the pressure to replicate security-relevant rules in each cluster separately. At the same time, the cluster remains responsible for the actual application and service configuration.
3. Routing and TLS Need Clear Ownership
Routing becomes problematic when the same decision is made at multiple points. For example, the Edge Cloud forwards /api to a cluster endpoint, while the Ingress further splits the same path. This is not fundamentally wrong but increases the number of rules that must remain synchronized during changes. Different priorities, rewrite rules, or status codes complicate troubleshooting.
A reliable structure thus broadly separates external and internal routing. The Edge Cloud decides which public hostname or service reaches which protected backend endpoint. The Kubernetes Ingress then decides which service within the cluster processes the request. This division should be documented and verifiable based on request flow, responsibility, and change process.
The same applies to TLS termination. If TLS is terminated at the edge, the Ingress typically receives an already forwarded connection. Then protocol, original scheme, and possibly client information must be consistently transmitted. If TLS is additionally terminated within the cluster, it is a deliberate end-to-end decision with its own certificate and operational effort, not an accidental double configuration.
4. Security Logic Belongs at the Appropriate Boundary
WAF and DDoS protection are most effective before harmful or excessive traffic reaches the cluster. An edge platform can perform these checks at the public entry and only pass allowed traffic to the Kubernetes environment. This not only protects individual Ingress rules but also the overall accessibility of the upstream application layer.
Ingress remains security-relevant nonetheless. It limits which services are internally accessible over HTTP and can support the application's routing or authentication requirements. However, it does not replace edge protection functions when attacks or large traffic spikes already consume network and cluster resources.
Organizationally, it is crucial who is allowed to change rules and how changes are tested. Edge rules should not emerge uncontrollably from individual deployment repositories, while Ingress configurations simultaneously alter global public accessibility. A shared model of responsibilities, version control, and monitoring of traffic and usage statistics prevents security and routing logic from diverging between platform and application teams.
Practical and Architectural Scenario
A company operates a Kubernetes cluster with an external provider. The public API should be accessible under api.example.de. The ayedo Edge Cloud handles Anycast DNS, TLS termination, WAF, DDoS protection, and backend cloaking. A publicly accessible cluster endpoint is stored as a backend; health checks detect if it is available.
Within the cluster, a Kubernetes Ingress resource only describes the forwarding from api.example.de to the services api-v1 and api-v2. The Edge Cloud does not decide on internal pod or service names, and the Ingress does not know global DDoS or WAF rules. If the cluster endpoint fails, the edge-side failover takes effect. If the team changes the API versioning, the change remains confined to the cluster configuration.
FAQ
Does the ayedo Edge Cloud replace Kubernetes Ingress?
No. The Edge Cloud takes over the public entry and protection functions. Kubernetes Ingress routes within the cluster to services and remains part of the application-related configuration.
Does TLS always have to be terminated at the edge?
No. TLS termination at the edge is an architectural decision. Additional encryption to the backend may be required but must be consciously planned in terms of certificates and operational effort.
Can the Edge Cloud be used in front of any Kubernetes cluster?
It can be used with ayedo Managed Kubernetes as well as with Kubernetes clusters operated by other providers. Defined, reachable backends and a consistent request flow are crucial.
Conclusion
Kubernetes Ingress and Edge Cloud are not competing implementations of the same layer. Ingress organizes the forwarding to services within the cluster; the Edge Cloud controls public access, protection, TLS termination, and backend accessibility. This separation reduces configuration conflicts and makes responsibilities verifiable. For companies with multiple clusters or providers, a provider-independent edge platform also creates a consistent external architecture, while teams can independently develop their internal Kubernetes configuration.