Use a CDN as Ingress for Kubernetes Traffic (2026)

A Content Delivery Network (CDN) can act as your Kubernetes cluster’s front door, but it’s not just about caching static assets; it fundamentally changes how you manage network access and security.

Let’s see what that looks like. Imagine a user in London requesting a dynamic API endpoint from your application running in a Kubernetes cluster in New York.

User (London) -> DNS Resolution -> CDN Edge Server (London) -> CDN Origin Fetch (to New York) -> Kubernetes Ingress Controller -> Service -> Pod

When the CDN is used as an Ingress, the traffic flow is altered. Instead of the user’s DNS directly resolving to your cluster’s public IP, it resolves to the CDN’s IP addresses. The CDN then fetches the content from your Kubernetes cluster, which acts as the "origin" for the CDN.

Here’s a simplified Kubernetes Ingress resource that might be used with a CDN:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    # This is a placeholder annotation. Actual CDN integration
    # would involve specific annotations for your chosen CDN provider.
    # For example, Cloudflare might use:
    # cloudflare.com/proxy-status: "on"
spec:
  rules:
  - host: api.mydomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

In this setup, the Ingress controller within your Kubernetes cluster (like Nginx, Traefik, or HAProxy) is still responsible for routing traffic to the correct Kubernetes Service and Pod. However, the CDN sits in front of this Ingress controller. The CDN’s role is to:

1. Cache static assets: Reduce load on your cluster for things like images, CSS, and JavaScript.
2. Handle TLS termination: Offload SSL/TLS encryption/decryption from your cluster.
3. DDoS mitigation: Provide a first line of defense against malicious traffic.
4. Global load balancing: Direct users to the nearest CDN edge server.
5. Origin Shielding: Aggregate requests from edge servers to your cluster, reducing direct hits.

The key mental model shift is understanding that your Kubernetes Ingress controller is no longer directly exposed to the internet. It’s now an "origin" endpoint for the CDN. This means you need to configure the CDN to point to your Ingress controller’s IP or hostname.

How to configure the CDN to point to your Kubernetes origin:

This process is highly dependent on your chosen CDN provider (e.g., Cloudflare, Akamai, AWS CloudFront, Fastly). Generally, you’ll:

1. Identify your Kubernetes origin IP/hostname: This is typically the external IP address of your LoadBalancer Service that exposes your Ingress controller, or a hostname provided by your cloud provider for that LoadBalancer. For example, if your Ingress controller is exposed via an AWS ELB, you’ll use its *.elb.amazonaws.com hostname.
2. Configure the CDN origin: In your CDN provider’s dashboard, you’ll set up an "origin" that points to this IP address or hostname. You’ll specify which hostname(s) (e.g., api.mydomain.com) the CDN should serve.
3. Configure DNS: Update your domain’s DNS records to point to the CDN provider’s edge servers, not directly to your Kubernetes cluster.

Example Scenario: Using Cloudflare with Kubernetes Ingress

Let’s say your Ingress controller is exposed via a Kubernetes Service of type LoadBalancer with an external IP 203.0.113.10.

1. Cloudflare DNS: You’d add a CNAME record for api.mydomain.com pointing to your-ingress-controller-service.your-namespace.svc.cluster.local (or the actual LoadBalancer hostname if you don’t have internal DNS setup for this). You would then enable the Cloudflare proxy (orange cloud).
2. Cloudflare Origin: In Cloudflare’s "Origin Server" settings for your zone, you’d configure it to use 203.0.113.10 as the origin IP. You might also set "Host Header Override" to api.mydomain.com to ensure your Ingress controller receives the correct Host header.

The most surprising true thing about using a CDN as an Ingress is that your Kubernetes Ingress controller’s IP address often becomes private or at least not directly routable from the public internet in the same way it was before. The CDN handles the public-facing IP and all the complexities that come with it.

Here’s a look at the traffic flow with Cloudflare proxying:

User (London) -> DNS Resolution -> Cloudflare Edge (London) -> Cloudflare Network -> Cloudflare Origin Fetch (to New York) -> Kubernetes LoadBalancer (203.0.113.10) -> Kubernetes Ingress Controller -> Service -> Pod

When traffic hits the Cloudflare edge server, Cloudflare checks its cache. If the content is cached and fresh, it serves it directly. If not, Cloudflare forwards the request to your Kubernetes origin (your Ingress controller’s LoadBalancer IP). Crucially, Cloudflare will typically set the X-Forwarded-For header to the original user’s IP address, and potentially X-Forwarded-Proto to indicate if the original request was HTTPS. Your Ingress controller and application must be configured to trust and use these headers for accurate client IP information.

Many people assume the CDN just caches things. The reality is that the CDN becomes your entire network perimeter. Your Kubernetes cluster’s Ingress controller is now an internal service that the CDN pulls from, rather than a public-facing service that pushes traffic. This means you need to carefully manage security groups or firewall rules to only allow traffic from your CDN provider’s IP ranges to reach your Ingress controller’s LoadBalancer.

The next concept you’ll encounter is managing the dynamic nature of CDN IP addresses and ensuring your firewall rules stay up-to-date, especially if your CDN provider changes their IP ranges or if you have multiple origin servers.