Learning Kubernetes - Introduction and Explanation of Ingress

#Introduction

In the previous episode, we learned about Service for exposing and accessing applications within and outside the cluster. In episode 19, we'll discuss Ingress, which provides sophisticated HTTP/HTTPS routing to Services.

Note: Here I'll be using a Kubernetes Cluster installed through K3s.

While Services can expose applications using LoadBalancer or NodePort, Ingress provides a more powerful and flexible way to manage external access. Ingress acts as a smart HTTP router, enabling features like host-based routing, path-based routing, TLS termination, and more - all with a single external IP.

#What Is Ingress?

Ingress is a Kubernetes API object that manages external HTTP and HTTPS access to Services in a cluster. It provides HTTP routing rules to direct traffic to different Services based on hostnames, paths, and other criteria.

Think of Ingress like a reverse proxy or API gateway - it sits at the edge of your cluster, receives external HTTP/HTTPS traffic, and routes it to the appropriate Services based on rules you define. Instead of creating multiple LoadBalancers (one per Service), you use a single Ingress with routing rules.

Key characteristics of Ingress:

HTTP/HTTPS routing - Routes traffic based on host and path
Single entry point - One external IP for multiple Services
TLS termination - Handles SSL/TLS certificates
Name-based virtual hosting - Multiple domains on one IP
Path-based routing - Different paths to different Services
Load balancing - Distributes traffic across Service endpoints
Requires Ingress Controller - Needs controller implementation

#Ingress vs Service

Let's understand the key differences:

Aspect	Ingress	LoadBalancer Service
Layer	Layer 7 (HTTP/HTTPS)	Layer 4 (TCP/UDP)
Routing	Host and path-based	Port-based only
External IPs	One IP for many Services	One IP per Service
TLS	Built-in TLS termination	Requires external setup
Cost	Single load balancer	Multiple load balancers
Protocol	HTTP/HTTPS only	Any TCP/UDP protocol

Example scenario:

Ingress: Route api.example.com to API Service, web.example.com to Web Service - one IP
LoadBalancer: Each Service gets its own external IP and load balancer

#Ingress Controller

Ingress resources don't work alone - they require an Ingress Controller to function.

#What Is Ingress Controller?

An Ingress Controller is a specialized load balancer that reads Ingress resources and implements the routing rules. It's the actual component that handles traffic.

Popular Ingress Controllers:

NGINX Ingress Controller - Most popular, feature-rich
Traefik - Modern, dynamic configuration
HAProxy Ingress - High performance
Kong - API gateway features
Istio Gateway - Service mesh integration
AWS ALB Ingress - AWS Application Load Balancer
GCE Ingress - Google Cloud Load Balancer

Important

Important: You must install an Ingress Controller before Ingress resources will work. Kubernetes doesn't include one by default.

#Installing NGINX Ingress Controller

For K3s (comes with Traefik by default):

Important

If you're using K3s, it's already default running Ingress Controller using Traefik like this:

For other clusters:

Verify installation:

#Creating Basic Ingress

Let's create a simple Ingress to expose a Service.

#Step 1: Create Deployment and Service

Apply:

#Step 2: Create Ingress

Apply:

Verify:

Output:

Now traffic to web.example.com routes to web-service.

Tip

If you want to access web.example.com, you can add static record on /etc/hosts that mapping to NodeIP, for example

After that tried to access with curl like this

Or if you don't want to used /etc/hosts, you can change directly the header from curl like this

Then you will get response from Deployment Pod like this

#Path-Based Routing

Route different paths to different Services.

#Example: Multiple Services

This routes:

example.com/api/* → api-service
example.com/web/* → web-service
example.com/* → frontend-service

#Host-Based Routing

Route different hostnames to different Services.

#Example: Multiple Hosts

This routes:

api.example.com → api-service
web.example.com → web-service
admin.example.com → admin-service

#Path Types

Ingress supports three path types:

#Prefix

Matches based on URL path prefix:

Matches: /api, /api/users, /api/v1/users

#Exact

Matches exact path only:

Matches: /api only Doesn't match: /api/, /api/users

#ImplementationSpecific

Depends on Ingress Controller implementation:

Behavior varies by controller.

#TLS/HTTPS Configuration

Enable HTTPS with TLS certificates.

#Step 1: Generate Self-Signed Certificate

After that add configuration like this to the file openssl.cnf

openssl.cnf

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext
 
[dn]
CN = example.com
 
[req_ext]
subjectAltName = @alt_names
 
[alt_names]
DNS.1 = example.com
DNS.2 = *.example.com

Next generate using this command

#Step 2: Create TLS Secret from Self-Signed Certificate

#Step 3: Create Deployment and Ingress with TLS

#Step 4: Run and Test HTTPS Request

Tip

HTTPS Request if you want valid used cert you should used SNI or Server Name Indication, because if change HTTP Header like curl request before using this

That will not work and it will be fallback to default cert K3s which is from Traefik (if used default Ingress Controller on K3s), because that HTTP Header happen after process TLS Handshake finish.

#Annotations

Customize Ingress behavior with annotations (controller-specific).

#NGINX Ingress Annotations

Common annotations:

rewrite-target: Rewrite URL path
ssl-redirect: Redirect HTTP to HTTPS
proxy-body-size: Max request body size
rate-limit: Rate limiting
whitelist-source-range: IP whitelisting

#Default Backend

Specify a default Service for unmatched requests.

Requests not matching any rule go to default-service.

#Practical Examples

#Example 1: Complete Microservices Setup

#Example 2: Multi-Environment Ingress

#Example 3: Ingress with Authentication

Create auth secret:

Tip

If you used default K3s Ingress Controller which is Traefik, you can create Ingress Basic Auth using CRD or Custom Resource Definition like this

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: basic-auth
spec:
basicAuth:
  secret: basic-auth

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: auth-ingress-traefik
annotations:
  traefik.ingress.kubernetes.io/router.middlewares: default-basic-auth@kubernetescrd
spec:
tls:
  - hosts:
      - example.com
      - www.example.com
      - admin.example.com
    secretName: example-tls
rules:
  - host: admin.example.com
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: web-service
              port:
                number: 80

After that you can access admin.example.com using command curl like this

bash

curl -k --resolve admin.example.com:443:10.10.10.4 https://admin.example.com -u admin:admin -v

#Viewing Ingress Details

#Get Ingress

#Describe Ingress

Output:

#View Ingress YAML

#Common Mistakes and Pitfalls

#Mistake 1: No Ingress Controller

Problem: Ingress created but not working.

Solution: Install Ingress Controller first:

#Mistake 2: Wrong Service Name

Problem: Ingress can't find Service.

Solution: Verify Service exists:

#Mistake 3: DNS Not Configured

Problem: Can't access via hostname.

Solution: Configure DNS or use /etc/hosts:

bash

203.0.113.10 example.com

#Mistake 4: Missing TLS Secret

Problem: HTTPS not working.

Solution: Verify secret exists:

#Mistake 5: Path Conflicts

Problem: Wrong Service receives traffic.

Solution: Order paths from most specific to least specific:

#Best Practices

#Use TLS for Production

Always enable HTTPS:

#Organize by Environment

Separate Ingress per environment:

#Use Meaningful Names

Choose descriptive Ingress names:

#Set Resource Limits on Services

Ingress routes to Services, ensure Pods have limits:

#Implement Rate Limiting

Protect against abuse:

#Use Cert-Manager for TLS

Automate certificate management:

#Monitor Ingress

Check Ingress Controller logs:

#Troubleshooting Ingress

#Check Ingress Controller

#Test Service Directly

#Verify DNS Resolution

#Check Ingress Events

#Conclusion

In episode 19, we've explored Ingress in Kubernetes in depth. We've learned what Ingress is, how it differs from Services, and how to use it for sophisticated HTTP/HTTPS routing.

Key takeaways:

Ingress manages external HTTP/HTTPS access to Services
Requires Ingress Controller to function (NGINX, Traefik, etc.)
Provides host-based and path-based routing
Single external IP for multiple Services
Built-in TLS termination for HTTPS
Three path types: Prefix, Exact, ImplementationSpecific
Customizable via annotations (controller-specific)
More cost-effective than multiple LoadBalancers
Layer 7 (HTTP/HTTPS) routing vs Service Layer 4 (TCP/UDP)
Always use TLS for production
Install Ingress Controller before creating Ingress resources

Ingress is essential for exposing HTTP/HTTPS applications in Kubernetes. By understanding Ingress, you can build sophisticated routing configurations, manage TLS certificates, and efficiently expose multiple Services through a single entry point.

Are you getting a clearer understanding of Ingress in Kubernetes? Keep your learning momentum going and look forward to the next episode!