Demo Cilium Ingress

This guide demonstrates how to enable and use the Cilium ingress controller on a Kubernetes cluster where Cilium was installed (for example via Helm) with the default values (ingress disabled by default). You’ll learn the required Cilium Helm values, how to enable the Cilium ingress controller, deploy example apps, create an Ingress resource using the Cilium ingress class, and validate routing.

Prerequisites

Quick cluster sanity check:

# kubectl get nodes
NAME                       STATUS   ROLES           AGE   VERSION
my-cluster-control-plane   Ready    control-plane   14m   v1.32.2
my-cluster-worker          Ready    <none>          14m   v1.32.2
my-cluster-worker2         Ready    <none>          14m   v1.32.2

Cilium’s ingress support requires one of two approaches. Choose either NodePort-based ingress or kube-proxy replacement plus L7 proxy. Below is a summary to compare the two options.

Resource / Option	Use case
`nodePort.enabled: true`	Use NodePort-based ingress if you prefer not to replace kube-proxy and want a simple, direct way to expose the Cilium ingress LoadBalancer through a node port.
`kubeProxyReplacement: "strict"` + `l7proxy: true`	Use kube-proxy replacement with Cilium’s L7 proxy if you want Cilium to replace kube-proxy functionality and handle load balancing at L7. This is more feature-rich but requires kube-proxy replacement.

Minimum required Helm values examples (pick one approach):

# Option A: enable NodePort-based ingress
nodePort:
  enabled: true

# Option B: enable kube-proxy replacement + L7 proxy
kubeProxyReplacement: "strict"   # or "true" depending on your Cilium version
l7proxy: true

If your environment is kind (or another local cluster without a cloud LB), provide a LoadBalancer implementation such as MetalLB so the Cilium ingress LoadBalancer can obtain an external IP.

Cilium documentation reference:

Enable the Cilium ingress controller

Add or update the ingress controller section in your values.yaml for the Cilium Helm chart:

ingressController:
  enabled: true
  default: true

  # Example ingress-related settings
  loadbalancerMode: shared   # supported values: shared, dedicated
  enforceHttps: true
  enableProxyProtocol: false

Notes on key fields:

loadbalancerMode: shared — multiple Ingress resources share a single Cilium-created LoadBalancer (cilium-ingress).
loadbalancerMode: dedicated — each Ingress gets its own LoadBalancer (separate external IP per Ingress).
enforceHttps: true — forces HTTP → HTTPS (308) redirection for TLS-enabled hosts.

Apply the Helm upgrade and restart Cilium components:

helm upgrade cilium cilium/cilium -f values.yaml -n kube-system

kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

Verify the Cilium IngressClass has been created:

kubectl get ingressclass
NAME     CONTROLLER                     PARAMETERS   AGE
cilium   cilium.io/ingress-controller   <none>       2m53s

If using a local cluster (kind, minikube, etc.)

Local clusters often lack a cloud load balancer. Install MetalLB or another LoadBalancer provider and configure an address pool so the cilium-ingress LoadBalancer acquires an external IP address for testing.

Example application topology

For this demo we deploy three services and a default backend:

shopping.com
- /products → ecom-products-service (port 3000)
- /cart → ecom-carts-service (port 3000)
blogger.com
- all paths → blog-service (port 3000)
default-backend-service (port 80) — catch-all for unmatched hosts/paths

Application manifests (Deployment + Service)

Save the following manifests in the working directory and apply them with kubectl apply -f .. ecom-products (deployment + service):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ecom-products
spec:
  selector:
    matchLabels:
      app: ecom-products
  template:
    metadata:
      labels:
        app: ecom-products
    spec:
      containers:
      - name: ecom-products
        image: sanjeevkt720/350-ecom-products

---
apiVersion: v1
kind: Service
metadata:
  name: ecom-products-service
spec:
  type: ClusterIP
  selector:
    app: ecom-products
  ports:
  - port: 3000
    targetPort: 3000

ecom-carts (deployment + service):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ecom-carts
spec:
  selector:
    matchLabels:
      app: ecom-carts
  template:
    metadata:
      labels:
        app: ecom-carts
    spec:
      containers:
      - name: ecom-carts
        image: sanjeevkt720/350-ecom-cart:v3

---
apiVersion: v1
kind: Service
metadata:
  name: ecom-carts-service
spec:
  type: ClusterIP
  selector:
    app: ecom-carts
  ports:
  - port: 3000
    targetPort: 3000

blog (deployment + service):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog
spec:
  selector:
    matchLabels:
      app: blog
  template:
    metadata:
      labels:
        app: blog
    spec:
      containers:
      - name: blog
        image: sanjeevkt720/350-blog

---
apiVersion: v1
kind: Service
metadata:
  name: blog-service
spec:
  type: ClusterIP
  selector:
    app: blog
  ports:
  - port: 3000
    targetPort: 3000

default-backend (deployment + service):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-backend
spec:
  selector:
    matchLabels:
      app: default-backend
  template:
    metadata:
      labels:
        app: default-backend
    spec:
      containers:
      - name: nginx
        image: nginx

---
apiVersion: v1
kind: Service
metadata:
  name: default-backend-service
spec:
  type: ClusterIP
  selector:
    app: default-backend
  ports:
  - port: 80
    targetPort: 80

Deploy the example apps:

kubectl apply -f .

Typical apply output (example):

deployment.apps/blog created
service/blog-service created
deployment.apps/default-backend created
service/default-backend-service created
deployment.apps/ecom-carts created
service/ecom-carts-service created
deployment.apps/ecom-products created
service/ecom-products-service created

Confirm deployments and services are ready:

kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
blog               1/1     1            1           6m
default-backend    1/1     1            1           6m
ecom-carts         1/1     1            1           6m
ecom-products      1/1     1            1           6m

kubectl get svc
NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)
blog-service              ClusterIP   10.96.50.148     <none>        3000/TCP
default-backend-service   ClusterIP   10.96.149.234    <none>        80/TCP
ecom-carts-service        ClusterIP   10.96.2.237      <none>        3000/TCP
ecom-products-service     ClusterIP   10.96.155.189    <none>        3000/TCP

Ingress resource (Cilium ingress class)

Create ingress.yaml to define host/path routing and a default backend. The Ingress uses the Cilium ingress class:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
spec:
  ingressClassName: cilium
  rules:
    - host: "shopping.com"
      http:
        paths:
          - pathType: Prefix
            path: "/products"
            backend:
              service:
                name: ecom-products-service
                port:
                  number: 3000
          - pathType: Prefix
            path: "/cart"
            backend:
              service:
                name: ecom-carts-service
                port:
                  number: 3000
    - host: "blogger.com"
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: blog-service
                port:
                  number: 3000
  # Default catch-all rule (no host specified)
  # Matches any host/path not matched above
  defaultBackend:
    service:
      name: default-backend-service
      port:
        number: 80

Apply the Ingress:

kubectl apply -f ingress.yaml

Verify the Ingress and the Cilium LoadBalancer:

kubectl get ingress
NAME      CLASS    HOSTS                         ADDRESS         PORTS   AGE
ingress   cilium   shopping.com,blogger.com      172.19.255.91   80      16s

kubectl get svc -A
NAMESPACE    NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)
kube-system  cilium-ingress            LoadBalancer   10.96.73.78      172.19.255.91     80:31190/TCP,443:32649/TCP

The Ingress ADDRESS corresponds to the external IP assigned to the cilium-ingress LoadBalancer service.

DNS / hosts mapping for testing

For local testing, map the demo hostnames to the LoadBalancer IP (example /etc/hosts entries):

19.255.91 shopping.com
19.255.91 blogger.com
19.255.91 testing123.com

Testing the routes

Use curl (or a browser) to validate routing via the LoadBalancer IP:

# blogger.com -> blog service
curl -s blogger.com
# shopping.com -> products
curl -s shopping.com/products
# shopping.com -> cart
curl -s shopping.com/cart
# unmatched host -> default backend (nginx)
curl -s testing123.com
# <html> ... Welcome to nginx! ...</html>

Troubleshooting checklist

Confirm ingressClassName: cilium on the Ingress or that Cilium is set as the default IngressController.
Verify service names and ports referenced by the Ingress match the Services (kubectl get svc).
Check for typos in hostnames and paths (e.g., /card vs /cart).
Ensure the cilium-ingress Service has an external IP (install MetalLB in local environments if necessary).
Inspect Cilium logs if requests are not reaching the expected backend:
- kubectl -n kube-system logs deployment/cilium-operator
- kubectl -n kube-system logs ds/cilium

Shared vs dedicated LoadBalancer behavior

Mode	Behavior
shared	A single `cilium-ingress` LoadBalancer service is created and multiple Ingress resources share the same external IP.
dedicated	Cilium creates one LoadBalancer per Ingress resource; each Ingress receives its own external IP.

Conclusion

You have enabled the Cilium ingress controller, configured load balancer behavior, deployed demo applications, created an Ingress resource using the Cilium ingress class, and tested routing. For production or multi-environment use, consider DNS automation to point hostnames to the Cilium LoadBalancer external IP(s) and review TLS configuration and enforceHttps behavior.

Introduction

Cilium Overview

Installing & Configuring Cilium

Exploring Cilium

Network Policy

Service Mesh

Cluster Mesh

Observability

BGP & External Networking

Optimization

Demo Cilium Ingress

Prerequisites

Enable the Cilium ingress controller

If using a local cluster (kind, minikube, etc.)

Example application topology

Application manifests (Deployment + Service)

Ingress resource (Cilium ingress class)

DNS / hosts mapping for testing

Testing the routes

Troubleshooting checklist

Shared vs dedicated LoadBalancer behavior

Conclusion

Links and references

Watch Video

​Prerequisites

​Enable the Cilium ingress controller

​If using a local cluster (kind, minikube, etc.)

​Example application topology

​Application manifests (Deployment + Service)

​Ingress resource (Cilium ingress class)

​DNS / hosts mapping for testing

​Testing the routes

​Troubleshooting checklist

​Shared vs dedicated LoadBalancer behavior

​Conclusion

​Links and references

Watch Video

Prerequisites

Enable the Cilium ingress controller

If using a local cluster (kind, minikube, etc.)

Example application topology

Application manifests (Deployment + Service)

Ingress resource (Cilium ingress class)

DNS / hosts mapping for testing

Testing the routes

Troubleshooting checklist

Shared vs dedicated LoadBalancer behavior

Conclusion

Links and references