Ingress resource definition in Kubernetes - Step-by-Step Execution

Process Flow - Ingress resource definition

Define Ingress YAML

↓

Apply YAML with kubectl

↓

Kubernetes creates Ingress resource

↓

Ingress Controller watches resource

↓

Ingress Controller configures routing

↓

External requests routed to services

The flow shows how you write an Ingress YAML, apply it, and how the Ingress Controller uses it to route external traffic to services.

Execution Sample

Kubernetes

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

This YAML defines an Ingress that routes requests for example.com to the example-service on port 80.

Process Table

Step	Action	Resource State	Ingress Controller Reaction	Result
1	Write Ingress YAML	Ingress resource defined but not applied	No reaction	No routing configured
2	kubectl apply ingress.yaml	Ingress resource created in cluster	Ingress Controller detects new resource	Starts processing rules
3	Ingress Controller reads rules	Ingress resource with host example.com and path /	Configures routing rules in controller	Routes external traffic matching example.com to example-service:80
4	External request to example.com arrives	Ingress resource unchanged	Ingress Controller routes request	Request forwarded to example-service on port 80
5	Ingress resource deleted	Ingress resource removed	Ingress Controller removes routing rules	Traffic no longer routed through Ingress

💡 Ingress resource deleted or no longer exists, so routing stops

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Ingress Resource	undefined	defined in cluster	configured with rules	unchanged	deleted
Ingress Controller State	idle	detects resource	configures routing	routes traffic	removes routing

Key Moments - 3 Insights

Why doesn't the Ingress route traffic immediately after writing the YAML file?

Because the YAML file is only local until applied with kubectl (see execution_table step 1 and 2). The Ingress Controller reacts only after the resource exists in the cluster.

What happens if the Ingress resource is deleted but the service still exists?

The Ingress Controller removes routing rules (execution_table step 5), so external traffic won't reach the service via Ingress anymore.

How does the Ingress Controller know which service to route traffic to?

It reads the backend service name and port from the Ingress rules (execution_table step 3) and configures routing accordingly.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the Ingress Controller start configuring routing rules?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Ingress Controller Reaction' column in execution_table rows

According to the variable tracker, what is the state of the Ingress Resource after Step 3?

A configured with rules

B defined in cluster

C undefined

D deleted

💡 Hint

Look at the 'Ingress Resource' row and 'After Step 3' column in variable_tracker

If the Ingress resource is deleted, what happens to the routing according to the execution table?

A Routing continues as before

B Routing stops because rules are removed

C Ingress Controller adds new rules

D Service is deleted automatically

💡 Hint

See the 'Result' column at Step 5 in execution_table

Concept Snapshot

Ingress resource defines rules to route external HTTP(S) traffic to Kubernetes services.
Write YAML with apiVersion, kind: Ingress, metadata, and spec.rules.
Apply with kubectl to create resource in cluster.
Ingress Controller watches resource and configures routing.
Deleting Ingress removes routing rules.
Ingress routes based on host and path to backend service and port.

Full Transcript

An Ingress resource in Kubernetes is a set of rules that tell the cluster how to route external web traffic to internal services. First, you write a YAML file defining the Ingress with host and path rules pointing to a service and port. Then you apply this YAML using kubectl, which creates the Ingress resource in the cluster. The Ingress Controller watches for these resources and configures itself to route incoming requests matching the rules to the correct service. When the Ingress resource is deleted, the controller removes the routing rules, stopping traffic from being routed through it. This flow ensures external traffic reaches the right service based on the rules you define.

Practice

1. What is the main purpose of a Kubernetes Ingress resource?

easy

A. To route external HTTP(S) traffic to internal services based on rules

B. To store configuration data for pods

C. To manage persistent storage volumes

D. To schedule pods on specific nodes

Solution

1. Step 1: Understand Ingress role

   An Ingress resource defines rules to route external traffic to services inside the cluster.

2. Step 2: Compare with other resources

   ConfigMaps store config, PersistentVolumes manage storage, and scheduling is done by the scheduler, not Ingress.

3. Final Answer:

   To route external HTTP(S) traffic to internal services based on rules -> Option A

4. Quick Check:

   Ingress routes external traffic [OK]

Hint: Ingress routes external traffic to services inside Kubernetes [OK]

Common Mistakes:

• Confusing Ingress with ConfigMap or PersistentVolume
• Thinking Ingress schedules pods
• Assuming Ingress manages storage

2. Which of the following is the correct minimal YAML snippet to define an Ingress that routes /app path to a service named my-service on port 80?

easy

A. apiVersion: networking.k8s.io/v1\nkind: Service\nmetadata:\n name: example-ingress\nspec:\n selector:\n app: my-service\n ports:\n - protocol: TCP\n port: 80\n targetPort: 80

B. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: example-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /app\n pathType: Prefix\n backend:\n service:\n name: my-service\n port:\n number: 80

C. apiVersion: v1\nkind: Ingress\nmetadata:\n name: example-ingress\nspec:\n rules:\n - host: example.com\n http:\n paths:\n - path: /app\n backend:\n serviceName: my-service\n servicePort: 80

D. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: example-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /app\n backend:\n service:\n name: my-service\n port: 8080

Solution

1. Step 1: Check apiVersion and kind

   Correct apiVersion for Ingress is networking.k8s.io/v1 and kind is Ingress.

2. Step 2: Validate backend service and port

   apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: example-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /app\n pathType: Prefix\n backend:\n service:\n name: my-service\n port:\n number: 80 uses correct new syntax with service name and port number 80 matching the question.

3. Final Answer:

   YAML with apiVersion networking.k8s.io/v1, kind Ingress, path /app, service my-service, port 80 -> Option B

4. Quick Check:

   Correct Ingress YAML uses networking.k8s.io/v1 and service port number [OK]

Hint: Use networking.k8s.io/v1 and service.port.number for Ingress backend [OK]

Common Mistakes:

• Using old apiVersion v1 for Ingress
• Using serviceName/servicePort instead of service.name/port.number
• Wrong port number in backend
• Defining Service instead of Ingress

3. Given this Ingress YAML snippet, what host and path will route traffic to web-service?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

medium

A. Traffic to host example.com and path starting with /web

B. Traffic to any host and path /web

C. Traffic to host example.com and any path

D. Traffic to host example.com and path exactly /web

Solution

1. Step 1: Identify host and path in rules

   The rule specifies host example.com and path /web with pathType Prefix.

2. Step 2: Understand pathType Prefix meaning

   Prefix means any path starting with /web will match, not just exactly /web.

3. Final Answer:

   Traffic to host example.com and path starting with /web -> Option A

4. Quick Check:

   Host and prefix path routing = Traffic to host example.com and path starting with /web [OK]

Hint: Prefix path matches all paths starting with given string [OK]

Common Mistakes:

• Assuming path matches exactly instead of prefix
• Ignoring host field and assuming any host
• Confusing pathType Prefix with Exact

4. You applied this Ingress YAML but traffic is not routing correctly:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: bad-ingress
spec:
  rules:
  - http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          serviceName: app-service
          servicePort: 80

What is the likely cause of the problem?

medium

A. Missing host field in rules

B. Incorrect apiVersion for Ingress

C. Using deprecated backend syntax serviceName and servicePort instead of service.name and service.port.number

D. Missing metadata name field

Solution

1. Step 1: Check backend syntax in Ingress spec

   The YAML uses old syntax with serviceName and servicePort which is deprecated in networking.k8s.io/v1.

2. Step 2: Confirm correct syntax

   Correct syntax uses service.name and service.port.number fields under backend.service.

3. Final Answer:

   Using deprecated backend syntax serviceName and servicePort instead of service.name and service.port.number -> Option C

4. Quick Check:

   Use service.name and service.port.number in Ingress backend [OK]

Hint: Use service.name and service.port.number for backend in networking.k8s.io/v1 [OK]

Common Mistakes:

• Using old backend syntax causing Ingress controller to ignore rules
• Assuming missing host always breaks routing
• Confusing apiVersion correctness
• Forgetting metadata name

5. You want to expose two services, service-a and service-b, on the same IP but different paths /a and /b. Which Ingress YAML snippet correctly defines this?

hard

A. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: multi-service-ingress\nspec:\n rules:\n - host: example.com\n http:\n paths:\n - path: /a\n pathType: Prefix\n backend:\n service:\n name: service-a\n port:\n number: 80

B. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: multi-service-ingress\nspec:\n rules:\n - host: example.com\n http:\n paths:\n - path: /a\n backend:\n serviceName: service-a\n servicePort: 80\n - path: /b\n backend:\n serviceName: service-b\n servicePort: 80

C. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: multi-service-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /a\n pathType: Exact\n backend:\n serviceName: service-a\n servicePort: 80\n - path: /b\n pathType: Exact\n backend:\n serviceName: service-b\n servicePort: 80

D. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: multi-service-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /a\n pathType: Prefix\n backend:\n service:\n name: service-a\n port:\n number: 80\n - path: /b\n pathType: Prefix\n backend:\n service:\n name: service-b\n port:\n number: 80

Solution

1. Step 1: Check apiVersion and kind

   All options use correct apiVersion and kind for Ingress.

2. Step 2: Validate backend syntax and multiple paths

   apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: multi-service-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /a\n pathType: Prefix\n backend:\n service:\n name: service-a\n port:\n number: 80\n - path: /b\n pathType: Prefix\n backend:\n service:\n name: service-b\n port:\n number: 80 correctly uses service.name and service.port.number with two paths under one rule without host, matching the requirement.

3. Step 3: Compare pathType usage

   Prefix pathType allows routing all requests starting with /a or /b, which is typical for path-based routing.

4. Final Answer:

   Ingress with two paths /a and /b routing to service-a and service-b using correct backend syntax -> Option D

5. Quick Check:

   Multiple paths with service.name and port.number = apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: multi-service-ingress\nspec:\n rules:\n - http:\n paths:\n - path: /a\n pathType: Prefix\n backend:\n service:\n name: service-a\n port:\n number: 80\n - path: /b\n pathType: Prefix\n backend:\n service:\n name: service-b\n port:\n number: 80 [OK]

Hint: Use one rule with multiple paths and service.name/port.number [OK]

Common Mistakes:

• Using deprecated backend syntax serviceName/servicePort
• Missing one of the paths or services
• Using pathType Exact which may limit routing
• Defining only one path instead of two