Ingress e routing in Kubernetes
Configuri le risorse Ingress per fornire accesso esterno ai servizi, abilitando routing avanzato e terminazione TLS.
Ingress e routing in Kubernetes è una lezione Docker & Kubernetes for Developers gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Docker & Kubernetes for Developers, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Docker & Kubernetes for Developers include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
Get External Access with Ingress
So far, we've used Services like NodePort or LoadBalancer to expose our applications outside the Kubernetes cluster.
While effective, these have limitations for complex routing, host-based rules, or managing TLS certificates for multiple applications.
This is where Ingress comes in! It acts as an entry point for external traffic, offering more advanced routing capabilities.
Ingress vs. Services: Key Differences
Let's clarify the roles:
- Service: Provides stable networking for Pods within the cluster and can expose a single application externally (e.g.,
NodePort,LoadBalancer). - Ingress: Manages external access to multiple Services, offering features like URL routing, host-based routing, and SSL/TLS termination.
Think of Ingress as a smart traffic controller for your external requests.
The Brain: Ingress Controller
An Ingress resource itself doesn't do anything on its own. It's just a set of rules you define.
You need an Ingress Controller running in your cluster. This controller watches for Ingress resources and configures a proxy (like Nginx, HAProxy, or Traefik) to fulfill those rules.
Without an Ingress Controller, your Ingress rules are ignored!
Anatomy of an Ingress Rule
An Ingress resource uses YAML to define how traffic should be routed. Here's a basic structure:
It specifies rules based on hostnames and paths, directing traffic to a specific Kubernetes Service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-service
port:
number: 80Routing by Hostname
One powerful feature is host-based routing. You can direct traffic for different hostnames to different backend Services.
For example, blog.example.com goes to your blog service, and api.example.com goes to your API service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-host-ingress
spec:
rules:
- host: blog.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: blog-service
port:
number: 80
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80Routing by URL Path
You can also route traffic based on the URL path. This is useful for exposing different parts of a single application or microservices under one domain.
For instance, myapp.com/users might go to a user service, while myapp.com/products goes to a product service.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: path-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /users
pathType: Prefix
backend:
service:
name: user-service
port:
number: 80
- path: /products
pathType: Prefix
backend:
service:
name: product-service
port:
number: 80Handling Unmatched Requests
What if no host or path rule matches an incoming request?
You can define a default backend in your Ingress. This directs all unmatched traffic to a specific Service, often a simple "404 Not Found" page or a default landing page.
It's good practice to always include a default backend for robustness.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: default-backend-ingress
spec:
defaultBackend:
service:
name: default-404-service
port:
number: 80
rules:
- host: myapp.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80Secure Traffic with TLS
Security is crucial! Ingress can also handle TLS termination. This means the Ingress Controller decrypts incoming HTTPS traffic before forwarding it to your backend Services (which can then run on plain HTTP).
This offloads SSL/TLS certificate management from your application Pods to the Ingress Controller.
You'll need a Kubernetes Secret containing your TLS certificate and key.
Ingress with TLS Example
To enable TLS, you reference a Kubernetes Secret in your Ingress definition. This Secret must contain the TLS certificate and private key.
The Ingress Controller will then use this certificate for HTTPS connections to your domain.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: secure-app-ingress
spec:
tls:
- hosts:
- secureapp.example.com
secretName: secureapp-tls-secret # Refers to a Kubernetes Secret
rules:
- host: secureapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: secure-app-service
port:
number: 443 # Or 80, if backend is HTTPIngress Routing Check
Consider an Ingress resource with the following rule:
rules:
- host: myapp.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
Which service will a request to http://myapp.example.com/api/v1/users be routed to?
Ingress: Your Smart Traffic Cop
In this lesson, you've learned about Kubernetes Ingress, a powerful tool for managing external access to your cluster.
- Ingress provides advanced routing features like host and path-based rules.
- An Ingress Controller is essential to make Ingress rules work.
- You can easily secure your applications with TLS termination using Ingress and Kubernetes Secrets.
Ingress simplifies exposing complex applications and microservices to the outside world!
Impara Docker & Kubernetes for Developers con un tutor IA — gratis
Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.
- Corsi
- 12
- Lezioni
- 48
Domande Frequenti
La lezione «Ingress e routing in Kubernetes» è gratuita?
Sì — il testo completo di «Ingress e routing in Kubernetes» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Docker & Kubernetes for Developers, passa a CoddyKit PRO. Il corso Docker & Kubernetes for Developers include 4 lezioni in totale.
Cosa imparerò in «Ingress e routing in Kubernetes»?
Configuri le risorse Ingress per fornire accesso esterno ai servizi, abilitando routing avanzato e terminazione TLS. Eserciti Docker & Kubernetes for Developers con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Docker & Kubernetes for Developers?
Non è richiesta alcuna esperienza precedente. Docker & Kubernetes for Developers su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.
Quanto tempo richiede la lezione «Ingress e routing in Kubernetes»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Docker & Kubernetes for Developers?
Sì. Ogni lezione Docker & Kubernetes for Developers include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Ingress e routing in Kubernetes
- Implementazione delle Network Policy
- Service discovery e DNS in K8s
- Terminazione TLS e protezione dell'Ingress con HTTPS