Why Ingress manages external access in Kubernetes - Why It Works

Introduction

When you run applications inside Kubernetes, they are hidden inside the cluster. Ingress helps you control how users from outside the cluster can reach your apps safely and easily.

When you want to let users access multiple apps through one web address.

When you need to control traffic rules like which app gets traffic based on the URL path.

When you want to secure access using HTTPS with certificates.

When you want to avoid exposing each app with its own public IP or load balancer.

When you want to manage external access centrally instead of configuring each app separately.

Config File - ingress.yaml

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
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 Ingress resource defines rules to route external traffic coming to example.com to two different services inside the cluster: app1-service and app2-service, based on the URL path.

The tls section enables HTTPS using a secret that holds the TLS certificate.

The annotation tells the NGINX Ingress controller to rewrite the URL path before sending it to the backend service.

Commands

This command creates the Ingress resource in Kubernetes, setting up rules for external access to your apps.

Terminal

kubectl apply -f ingress.yaml

Expected Output

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

This command checks that the Ingress resource is created and shows its address and rules.

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, including backend services and TLS settings.

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:8080)

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

Annotations:  nginx.ingress.kubernetes.io/rewrite-target: /

Events:       <none>

Key Concept

Ingress acts as a smart gatekeeper that controls and routes external traffic into your Kubernetes apps using simple rules.

Common Mistakes

Not creating or configuring an Ingress controller in the cluster.

Without an Ingress controller, the Ingress resource does nothing and external access won't work.

Install a supported Ingress controller like NGINX Ingress Controller before applying Ingress resources.

Using incorrect service names or ports in the Ingress backend configuration.

Ingress cannot route traffic if the backend service or port does not exist or is wrong.

Double-check service names and ports match the actual services running in the cluster.

Forgetting to add TLS secrets for HTTPS or misconfiguring the TLS section.

Without proper TLS secrets, HTTPS will not work and users may get security warnings.

Create TLS secrets with valid certificates and reference them correctly in the Ingress spec.

Summary

Create an Ingress resource to define how external traffic reaches your Kubernetes services.

Use rules in the Ingress to route traffic based on hostnames and URL paths.

Check Ingress status and details with kubectl commands to verify external access setup.

Practice

1. What is the primary role of an Ingress in Kubernetes?

easy

A. To manage external access to services inside the cluster

B. To store configuration data for pods

C. To schedule pods on nodes

D. To monitor resource usage of containers

Solution

1. Step 1: Understand Ingress purpose

   Ingress is designed to control how external users access services running inside Kubernetes.

2. Step 2: Compare with other components

   Other components like ConfigMaps store data, schedulers place pods, and metrics monitor usage, but Ingress manages external access.

3. Final Answer:

   To manage external access to services inside the cluster -> Option A

4. Quick Check:

   Ingress controls external access = C [OK]

Hint: Ingress controls outside traffic to services [OK]

Common Mistakes:

• Confusing Ingress with ConfigMap or Scheduler
• Thinking Ingress manages internal pod scheduling
• Assuming Ingress monitors resource usage

2. Which of the following is the correct basic syntax to define an Ingress resource in YAML?

easy

A. apiVersion: v1\nkind: Service\nmetadata:\n name: example-ingress\nspec:\n selector:\n app: example\n ports:\n - protocol: TCP\n port: 80\n targetPort: 9376

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

C. apiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: example-ingress\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: example

D. apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: example-ingress\nspec:\n rules:\n - host: example.com\n tcp:\n ports:\n - port: 80\n backend:\n serviceName: example-service\n servicePort: 80

Solution

1. Step 1: Identify correct Ingress syntax

   Ingress uses apiVersion networking.k8s.io/v1, kind Ingress, and defines rules with host and http paths.

2. Step 2: Check options for correct fields

   apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: example-ingress\nspec:\n rules:\n - host: example.com\n http:\n paths:\n - path: /\n pathType: Prefix\n backend:\n service:\n name: example-service\n port:\n number: 80 matches the correct structure with service name and port under backend. apiVersion: v1\nkind: Service\nmetadata:\n name: example-ingress\nspec:\n selector:\n app: example\n ports:\n - protocol: TCP\n port: 80\n targetPort: 9376 is a Service definition. The other options define a Deployment or incorrectly use a tcp field.

3. Final Answer:

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

4. Quick Check:

   Ingress YAML syntax = A [OK]

Hint: Ingress YAML uses rules with host and http paths [OK]

Common Mistakes:

• Confusing Service or Deployment YAML with Ingress
• Using tcp instead of http in rules
• Incorrect apiVersion or kind for Ingress

3. Given this Ingress rule snippet, what hostname will route traffic to my-service?

spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 8080

medium

A. app.example.com

B. example.com

C. my-service

D. app

Solution

1. Step 1: Identify the host in the Ingress rule

   The host field is set to app.example.com, which defines the hostname for routing.

2. Step 2: Understand routing based on host

   Traffic to app.example.com with path prefix /app routes to my-service on port 8080.

3. Final Answer:

   app.example.com -> Option A

4. Quick Check:

   Host in rule = app.example.com [OK]

Hint: Look for host field in Ingress rules [OK]

Common Mistakes:

• Confusing service name with hostname
• Ignoring the host field and picking path or service name
• Choosing partial strings like 'app' instead of full hostname

4. You created an Ingress resource but external traffic is not reaching your service. Which of these is a likely cause?

medium

A. The pod image is missing a label

B. The cluster has no nodes

C. The service port is set to 0

D. The Ingress controller is not installed or running

Solution

1. Step 1: Check Ingress controller presence

   Ingress resources need an Ingress controller to process rules and route traffic. Without it, Ingress does nothing.

2. Step 2: Evaluate other options

   Pod labels or service ports affect internal routing but won't stop Ingress from receiving traffic. No nodes means cluster is down, but question focuses on Ingress.

3. Final Answer:

   The Ingress controller is not installed or running -> Option D

4. Quick Check:

   Ingress needs controller to route traffic = B [OK]

Hint: Ingress needs a controller running to work [OK]

Common Mistakes:

• Ignoring the need for an Ingress controller
• Blaming pod labels for external access issues
• Confusing service port 0 with Ingress failure

5. You want to expose two services, service-a and service-b, on the same domain but different paths using Ingress. Which configuration correctly achieves this?

hard

A. Use a LoadBalancer service type for each service instead of Ingress

B. Create two Ingress resources with the same host example.com, each with one path for service-a and service-b

C. Define one Ingress with rules for host example.com and paths /a routing to service-a, /b routing to service-b

D. Expose service-a and service-b on different ports without Ingress

Solution

1. Step 1: Understand Ingress path routing

   Ingress can route different URL paths on the same host to different services using rules with multiple paths.

2. Step 2: Compare options for best practice

   Define one Ingress with rules for host example.com and paths /a routing to service-a, /b routing to service-b uses one Ingress with multiple paths, which is efficient and standard. Create two Ingress resources with the same host example.com, each with one path for service-a and service-b may cause conflicts. Options C and D avoid Ingress and don't meet the requirement.

3. Final Answer:

   Define one Ingress with rules for host example.com and paths /a and /b routing to respective services -> Option C

4. Quick Check:

   One Ingress, multiple paths = A [OK]

Hint: Use one Ingress with multiple paths for same host [OK]

Common Mistakes:

• Creating multiple Ingresses with same host causing conflicts
• Using LoadBalancer instead of Ingress for path routing
• Exposing services on different ports without hostname routing