Ingress resource definition in Kubernetes - Commands & Configuration

Introduction

When you want to let users access your apps running inside Kubernetes from outside, you need a way to route their requests. An Ingress resource defines rules to control this routing, so you can direct traffic to different apps based on the URL or host name.

When you have multiple apps running in the same Kubernetes cluster and want to share one external IP address for all.

When you want to route traffic to different services based on the URL path, like example.com/app1 and example.com/app2.

When you want to use HTTPS with your apps by configuring TLS certificates in one place.

When you want to control access to your apps with rules like blocking or allowing certain hosts.

When you want to simplify exposing your services without creating many LoadBalancer or NodePort services.

Config File - ingress.yaml

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: example-tls-secret

This file defines an Ingress resource named example-ingress in the default namespace.

The rules section routes requests for example.com/app1 to the app1-service and example.com/app2 to the app2-service.

The tls section enables HTTPS for example.com using a TLS secret named example-tls-secret.

Commands

This command creates the Ingress resource in the cluster using the configuration file. It sets up the routing rules and TLS settings.

Terminal

kubectl apply -f ingress.yaml

Expected Output

ingress.networking.k8s.io/example-ingress created

This command checks that the Ingress resource was created and shows its current status and assigned IP or hostname.

Terminal

kubectl get ingress example-ingress

Expected Output

NAME              CLASS    HOSTS         ADDRESS        PORTS   AGE

example-ingress   <none>   example.com   192.168.1.100  80,443  10s

This command shows detailed information about the Ingress resource, including rules, backend services, and events.

Terminal

kubectl describe ingress example-ingress

Expected Output

Name:             example-ingress

Namespace:        default

Address:          192.168.1.100

Default backend:  <none>

Rules:

  Host        Path  Backends

  ----        ----  --------

  example.com

              /app1   app1-service:80 (10.1.1.10:80)

              /app2   app2-service:80 (10.1.1.11:80)

Annotations:  <none>

Events:

  Type    Reason  Age   From                      Message

  ----    ------  ----  ----                      -------

  Normal  Sync    10s   ingress-controller        Scheduled for sync

Key Concept

If you remember nothing else from this pattern, remember: an Ingress resource lets you control how external traffic reaches your Kubernetes services by defining rules and TLS settings in one place.

Common Mistakes

Not specifying the correct pathType in the paths section

Without the correct pathType (like Prefix), the routing may not work as expected and requests might not reach the intended service.

Always set pathType to Prefix or Exact depending on your routing needs; Prefix is common for routing all paths under a URL.

Forgetting to create or reference a valid TLS secret for HTTPS

If the TLS secret does not exist or is misnamed, HTTPS will fail and users may get security warnings or no encryption.

Create the TLS secret with your certificates and reference it correctly in the tls section of the Ingress.

Applying the Ingress resource without an Ingress controller installed

The Ingress resource alone does nothing without a controller to implement the rules, so traffic won't be routed.

Make sure an Ingress controller like NGINX or Traefik is installed and running in your cluster before applying Ingress resources.

Summary

Create an Ingress resource YAML file to define routing rules and TLS settings.

Apply the Ingress resource with kubectl apply to create it in the cluster.

Use kubectl get and describe commands to verify the Ingress status and details.

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