Cloud Native 18 min read

Mastering Kubernetes Ingress: From Basics to TLS‑Enabled Deployments

This guide explains Kubernetes service exposure options, the challenges they address, and provides a step‑by‑step tutorial for deploying an Ingress controller, creating Ingress resources, and configuring TLS to securely expose applications within a cluster.

Full-Stack DevOps & Kubernetes
Full-Stack DevOps & Kubernetes
Full-Stack DevOps & Kubernetes
Mastering Kubernetes Ingress: From Basics to TLS‑Enabled Deployments

Review

Kubernetes currently offers four ways to expose services: LoadBalancer Service, ExternalName, NodePort Service, and Ingress. When using a Layer‑4 load‑balancer Service, traffic flows as client → nodeIP:port → serviceIP:port → podIP:port.

What are Ingress and Ingress Controller?

Ingress abstracts the need to edit Nginx configuration by defining routing rules in a YAML object. The Ingress Controller watches the Kubernetes API, generates Nginx (or Traefik) configuration from those rules, writes it to the controller pod, and reloads the proxy.

Ingress itself is only a set of routing rules; the actual traffic handling is performed by an Ingress Controller.

Common Issues Without Ingress

Pod IP drift – Pods are recreated on any node, causing IP changes. Service abstraction solves this by providing a stable Service IP.

Port management – NodePort requires many ports on each node, hard to maintain.

Domain allocation and dynamic updates – Manually editing Nginx for each new service is error‑prone.

Seven‑Layer Load Balancers

Ingress Controllers are Layer‑7 load balancers (e.g., Nginx, Traefik). They receive client requests, forward them to backend Services, which in turn route to Pods.

Creating an Ingress Resource

An Ingress object contains spec.rules, an optional spec.backend, and optional spec.tls. Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-myapp
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: tomcat.lucky.com
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp
          servicePort: 80

The rules field maps hostnames or URL paths to backend Services. The backend field provides a default Service when no rule matches. The tls field configures HTTPS termination.

Ingress Controller Deployment (Traefik example)

Deploy the Ingress Controller pod (e.g., via provided YAML).

Create a Service (NodePort) to expose the controller outside the cluster.

Deploy backend Services and Pods (e.g., myapp, tomcat).

Apply Ingress resources that reference those Services.

Typical commands:

kubectl apply -f namespace.yaml
kubectl apply -f .
kubectl get all -n ingress-nginx
kubectl apply -f ingress-myapp.yaml
kubectl describe ingress ingress-myapp

TLS‑Enabled Ingress

Generate a TLS key and certificate, create a Kubernetes secret, and reference it in the Ingress tls section.

openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -out tls.crt -subj "/C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.lucky.com"
kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls.key

Ingress YAML snippet for TLS:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tomcat-tls
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - tomcat.lucky.com
    secretName: tomcat‑ingress‑secret
  rules:
  - host: tomcat.lucky.com
    http:
      paths:
      - backend:
          serviceName: tomcat
          servicePort: 8080

Access the service via https://tomcat.lucky.com:30443/. If automatic HTTP‑to‑HTTPS redirection is undesired, add the annotation nginx.ingress.kubernetes.io/ssl-redirect: "false".

Summary of Deployment Steps

Download Ingress Controller YAML and create a dedicated namespace.

Deploy backend Services (e.g., myapp).

Deploy the Ingress Controller Service (NodePort) to accept external traffic.

Create Ingress resources that bind hostnames/paths to backend Services, optionally with TLS.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeKubernetesDevOpsYAMLTLSIngress
Full-Stack DevOps & Kubernetes
Written by

Full-Stack DevOps & Kubernetes

Focused on sharing DevOps, Kubernetes, Linux, Docker, Istio, microservices, Spring Cloud, Python, Go, databases, Nginx, Tomcat, cloud computing, and related technologies.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.