Below you will find pages that utilize the taxonomy term “Ingress”

Kubernetes

II. Understanding Kubernetes Service Types & Ingress

1. Introduction

  • Why exposing services matters in Kubernetes:

    • Your workloads are useless if no one can reach them. Service abstraction lets you decouple pod lifecycles from stable endpoints.

  • Overview of Service types vs. Ingress:

    • Services give every workload an IP; Ingress turns a set of Services into a coherent, externally reachable API surface.

2. Kubernetes Service Types Explained

a. ClusterIP

- Exposes the Service on a cluster-internal IP
- Accessible **only inside** the cluster
- Typical use: 
    - Internal-only services 
    - Microservices talking to each other

b. NodePort

- Exposes the Service on each node’s IP at a static port (the NodePort)
- Accessible from outside the cluster: same VPC or the internet (depending on firewall/Security Group rules)
- Reachable via **NodeIP:NodePort** (port range 30000 - 32767)
- Typical use:
    - Simple setups, debugging, or in environments without cloud LBs. 
    - Quick test or direct access, not recommended for production internet-facing apps.

c. LoadBalancer

- Creates a cloud load balancer (cloud provider integration, e.g., AWS ALB).
- Assigns a public IP and routes traffic to your Service.
- Accessible from the internet.
- Typical use: exposing production workloads to the internet (websites, APIs).

d. ExternalName

- Maps the Service to an external DNS name.
- Used for routing cluster traffic to resources outside Kubernetes.
- Not used for exposing services to the internet.
- Typical use: referencing services outside the cluster by DNS name(database,SaaS endpoints).

3. Ingress

  • Ingress is a Kubernetes resource that manages external HTTP/HTTPS traffic
    • Receives incoming requests from outside the cluster
    • Routes them to the right Service based on rules (URL path, host, headers…)
  • Typical flow: User → ALB/NLB/NGINX (provisioned by the Ingress Controller) → Service → Pods.
  • Ingress Controller:
    • A pod/deployment running inside your cluster
    • monitors your Ingress resources.
    • configures and manages actual routing rules on a cloud load balancer
  • Ingress Class:
    • a way to specify which Ingress Controller is responsible for handling a particular Ingress resource

4. Curious question

Q: Why Do You Need Ingress? A: Without Ingress, to expose multiple applications or services externally, you would need many individual LoadBalancer services, which becomes expensive and complex quickly.

read more