Ingress annotations for customization in Kubernetes - Step-by-Step Execution

Process Flow - Ingress annotations for customization

Create Ingress resource

↓

Add annotations in metadata

↓

Ingress controller reads annotations

↓

Apply custom behavior (e.g., rewrite, timeout)

↓

Ingress routes traffic with customization

Annotations are added to the Ingress resource metadata to tell the Ingress controller how to customize traffic routing and behavior.

Execution Sample

Kubernetes

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/"

This Ingress resource uses an annotation to rewrite the URL path to '/' before forwarding.

Process Table

Step	Action	Annotation Read	Effect on Ingress Controller	Resulting Behavior
1	Ingress resource created	nginx.ingress.kubernetes.io/rewrite-target: /	Controller detects rewrite annotation	URL paths rewritten to '/'
2	Ingress controller processes request	rewrite-target: /	Modifies request path	Request forwarded with rewritten path
3	Ingress controller applies default rules	No conflicting annotations	Default routing applies	Traffic routed to backend service
4	No more annotations	End of annotation list	No further customization	Ingress routing complete

💡 All annotations processed; Ingress controller applies customizations and routes traffic accordingly

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Ingress Annotations	{}	{"nginx.ingress.kubernetes.io/rewrite-target": "/"}	{"nginx.ingress.kubernetes.io/rewrite-target": "/"}	{"nginx.ingress.kubernetes.io/rewrite-target": "/"}	{"nginx.ingress.kubernetes.io/rewrite-target": "/"}
Request Path	/app	/app	/	/	/
Routing Decision	None	None	Rewrite applied	Route to backend	Route complete

Key Moments - 3 Insights

Why does the request path change from '/app' to '/'?

Because the annotation 'nginx.ingress.kubernetes.io/rewrite-target: /' tells the Ingress controller to rewrite the path before forwarding, as shown in execution_table step 2.

What happens if there are no annotations in the Ingress resource?

The Ingress controller applies default routing rules without customization, as seen in execution_table step 3.

Can multiple annotations be processed at once?

Yes, the controller reads all annotations in metadata and applies their effects in order, but this example shows a single annotation for clarity.

Visual Quiz - 3 Questions

Look at the execution table, what is the request path after step 2?

A "/app"

B "/"

C "/rewrite"

D "/backend"

💡 Hint

Check the 'Request Path' variable in variable_tracker after Step 2.

At which step does the Ingress controller apply default routing rules?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Effect on Ingress Controller' column in execution_table for default routing.

If the annotation 'nginx.ingress.kubernetes.io/rewrite-target' was removed, what would happen to the request path?

A It would be blocked

B It would be rewritten to '/'

C It would remain unchanged as '/app'

D It would be redirected to another domain

💡 Hint

Refer to key_moments about behavior without annotations and variable_tracker initial values.

Concept Snapshot

Ingress annotations customize traffic routing by adding key-value pairs in metadata.
Annotations tell the Ingress controller how to modify requests (e.g., rewrite paths).
The controller reads annotations and applies changes before routing.
Without annotations, default routing rules apply.
Annotations enable flexible, per-Ingress customization without changing backend services.

Full Transcript

Ingress annotations are special settings added to the metadata of an Ingress resource in Kubernetes. When you create an Ingress, you can add annotations as key-value pairs. The Ingress controller reads these annotations and changes how it handles incoming traffic. For example, the annotation 'nginx.ingress.kubernetes.io/rewrite-target: /' tells the controller to change the request path to '/' before sending it to the backend service. This lets you customize routing without changing your backend apps. If no annotations are present, the controller just routes traffic normally. This visual trace shows how the controller reads annotations step-by-step, applies changes like rewriting paths, and then routes the traffic accordingly.

Practice

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

easy

A. To specify the IP address of the Ingress controller

B. To define the backend services for routing traffic

C. To customize the behavior of the Ingress controller without changing the main spec

D. To set resource limits for the Ingress pod

Solution

1. Step 1: Understand the role of annotations in Kubernetes

   Annotations are key-value pairs used to add metadata or customize behavior without changing the main resource spec.

2. Step 2: Apply this to Ingress resources

   In Ingress, annotations allow customization of controller behavior like SSL settings or rewrite rules without modifying the core routing rules.

3. Final Answer:

   To customize the behavior of the Ingress controller without changing the main spec -> Option C

4. Quick Check:

   Ingress annotations = customization without spec change [OK]

Hint: Annotations customize Ingress behavior without touching main config [OK]

Common Mistakes:

• Confusing annotations with service definitions
• Thinking annotations set IP addresses
• Assuming annotations control pod resources

2. Which of the following is the correct syntax to add an annotation for enabling SSL redirect in a Kubernetes Ingress YAML?

easy

A. metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"

B. spec:
annotations:
ssl-redirect: true

C. metadata:
labels:
nginx.ingress.kubernetes.io/ssl-redirect: true

D. annotations:
ssl-redirect: "true"

Solution

1. Step 1: Locate where annotations belong in Ingress YAML

   Annotations must be under metadata.annotations as key-value pairs.

2. Step 2: Check correct key and value format

   The key for SSL redirect in nginx ingress is nginx.ingress.kubernetes.io/ssl-redirect and the value should be a string "true".

3. Final Answer:

   metadata: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true" -> Option A

4. Quick Check:

   Annotations under metadata.annotations with string values [OK]

Hint: Annotations go under metadata.annotations as string key-values [OK]

Common Mistakes:

• Placing annotations under spec instead of metadata
• Using labels instead of annotations
• Using boolean true instead of string "true"

3. Given this Ingress snippet with annotations:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"

What will be the effect on incoming HTTP requests?

medium

A. Requests will be redirected to HTTPS and paths rewritten to root

B. Requests will not redirect to HTTPS and paths will be rewritten to root

C. Requests will redirect to HTTPS but paths will not be rewritten

D. Requests will neither redirect to HTTPS nor rewrite paths

Solution

1. Step 1: Analyze the ssl-redirect annotation

   The annotation nginx.ingress.kubernetes.io/ssl-redirect: "false" disables automatic HTTP to HTTPS redirection.

2. Step 2: Analyze the rewrite-target annotation

   The annotation nginx.ingress.kubernetes.io/rewrite-target: "/" rewrites the path of incoming requests to root (/).

3. Final Answer:

   Requests will not redirect to HTTPS and paths will be rewritten to root -> Option B

4. Quick Check:

   ssl-redirect false disables HTTPS redirect; rewrite-target "/" rewrites paths [OK]

Hint: ssl-redirect false disables HTTPS redirect; rewrite-target changes path [OK]

Common Mistakes:

• Assuming ssl-redirect false still redirects
• Ignoring rewrite-target effect
• Confusing rewrite-target with redirect

4. You added this annotation to your Ingress:

nginx.ingress.kubernetes.io/ssl-redirect: true

But HTTPS redirection is not working. What is the most likely cause?

medium

A. The annotation value should be a string "true", not boolean true

B. The annotation must be under spec.annotations, not metadata.annotations

C. The Ingress controller does not support this annotation

D. You need to restart the Ingress controller pod

Solution

1. Step 1: Check annotation value type

   Annotations require string values, so boolean true is invalid and ignored.

2. Step 2: Confirm correct placement and support

   The annotation must be under metadata.annotations and nginx ingress supports this annotation.

3. Final Answer:

   The annotation value should be a string "true", not boolean true -> Option A

4. Quick Check:

   Annotation values must be strings, not booleans [OK]

Hint: Annotation values must be strings, not booleans [OK]

Common Mistakes:

• Placing annotations under spec instead of metadata
• Assuming controller restart fixes annotation issues
• Ignoring controller support for annotation

5. You want to customize your Ingress to add a custom header X-Frame-Options: DENY for security. Which annotation and value should you add to achieve this with nginx ingress controller?

hard

A. nginx.ingress.kubernetes.io/custom-header: "X-Frame-Options=DENY"

B. nginx.ingress.kubernetes.io/add-headers: "X-Frame-Options: DENY"

C. nginx.ingress.kubernetes.io/headers: "X-Frame-Options: DENY"

D. nginx.ingress.kubernetes.io/configuration-snippet: "more_set_headers \"X-Frame-Options: DENY\";"

Solution

1. Step 1: Identify how to add custom headers in nginx ingress

   The nginx ingress controller supports adding custom headers via the configuration-snippet annotation using nginx directives.

2. Step 2: Use the correct syntax for setting headers

   The directive more_set_headers "X-Frame-Options: DENY"; correctly adds the header.

3. Final Answer:

   nginx.ingress.kubernetes.io/configuration-snippet: "more_set_headers \"X-Frame-Options: DENY\";" -> Option D

4. Quick Check:

   Use configuration-snippet with more_set_headers for custom headers [OK]

Hint: Use configuration-snippet with nginx directive for custom headers [OK]

Common Mistakes:

• Using non-existent annotation keys
• Incorrect syntax for header setting
• Confusing add-headers with configuration-snippet