Ingress Controller w Kubernetes – zarządzanie ruchem HTTP/HTTPS do aplikacji
Ingress Controller w Kubernetes – zarządzanie ruchem HTTP/HTTPS do aplikacji
W klasycznym środowisku serwerowym publikowanie aplikacji jest stosunkowo proste:
Internet
↓
Firewall
↓
Web Server (Nginx/Apache)
↓
Application
W Kubernetes sytuacja jest bardziej skomplikowana.
Aplikacje działają w Podach, które:
- są dynamiczne,
- mogą być tworzone i usuwane,
- mają zmienne adresy IP,
- mogą działać na wielu Node’ach.
Bez dodatkowej warstwy zarządzanie ruchem HTTP/HTTPS byłoby bardzo trudne.
Tutaj pojawia się Ingress Controller.
Czym jest Ingress Controller?
Ingress Controller to komponent Kubernetes odpowiedzialny za obsługę ruchu przychodzącego do klastra.
Jego zadaniem jest:
- odbieranie ruchu HTTP/HTTPS,
- terminowanie TLS,
- kierowanie żądań do odpowiednich Service,
- load balancing,
- routing na podstawie domen i ścieżek.
Schemat:
Internet
|
↓
Ingress Controller
|
+---------+---------+
| |
Frontend Backend
Service Service
| |
Pods Pods
Ingress vs Ingress Controller
Często te pojęcia są mylone.
Ingress
To obiekt Kubernetes opisujący reguły ruchu.
Przykład:
example.com
↓
frontend-service
/api
↓
backend-service
Ingress Controller
To działająca aplikacja, która realizuje te reguły.
Czyli:
Ingress
(configuration)
↓
Ingress Controller
(execution)
↓
Services
↓
Pods
Sam obiekt Ingress niczego nie wykonuje.
Dlaczego potrzebujemy Ingress?
Bez Ingress każda aplikacja mogłaby wymagać własnego Load Balancera.
Przykład:
Application A
↓
LoadBalancer
↓
Public IP
Application B
↓
LoadBalancer
↓
Public IP
Application C
↓
LoadBalancer
↓
Public IP
Problemy:
- wysokie koszty,
- trudne zarządzanie,
- dużo adresów IP,
- brak centralnej kontroli.
Z Ingress:
One Public IP
|
Ingress Controller
+------------+------------+
| |
app.example.com api.example.com
| |
Frontend Backend
Najpopularniejsze Ingress Controllers
W praktyce spotykamy:
NGINX Ingress Controller
Najpopularniejszy wybór.
Wykorzystuje:
- NGINX jako reverse proxy,
- konfigurację generowaną z Kubernetes API.
Zastosowania:
- aplikacje webowe,
- API,
- mikroserwisy.
Traefik
Popularny w:
- mniejszych klastrach,
- środowiskach DevOps,
- homelabach.
Zalety:
- prosta konfiguracja,
- automatyczne wykrywanie usług,
- dobra integracja z Docker/Kubernetes.
HAProxy Ingress
Wybierany tam, gdzie liczy się:
- wydajność,
- duża liczba połączeń,
- niskie opóźnienia.
Cilium Gateway API
Nowoczesne podejście wykorzystujące:
- eBPF,
- Gateway API,
- wysoką wydajność sieciową.
Jak działa ruch przez Ingress?
Przykładowy przepływ:
1. Użytkownik wpisuje:
https://app.example.com
2. DNS zwraca:
Load Balancer IP
3. Ruch trafia do:
Ingress Controller
4. Controller sprawdza:
Host:
app.example.com
5. Kieruje ruch do:
frontend-service
6. Service wybiera:
Pod
Schemat:
Client
↓
DNS
↓
Load Balancer
↓
Ingress Controller
↓
Service
↓
Pod
Przykład Ingress Resource
Załóżmy:
Mamy Service:
frontend-service
backend-service
Tworzymy:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: application-ingress
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: backend-service
port:
number: 8080
Efekt:
app.example.com
↓
frontend-service
api.example.com
↓
backend-service
Routing według ścieżki
Ingress może kierować ruch według URL.
Przykład:
example.com/
↓
frontend
example.com/api
↓
backend
example.com/admin
↓
admin-panel
Konfiguracja:
paths:
- path: /api
backend:
service:
name: api-service
TLS i HTTPS
Ingress często odpowiada za szyfrowanie HTTPS.
Schemat:
Client
HTTPS
↓
Ingress Controller
TLS Termination
↓
HTTP Internal Traffic
↓
Service
Certyfikat:
tls:
- hosts:
- example.com
secretName:
example-tls
Cert-Manager i automatyczne certyfikaty
W produkcji często używa się:
- cert-manager,
- Let’s Encrypt.
Proces:
New Domain
↓
Ingress
↓
cert-manager
↓
Let's Encrypt
↓
TLS Certificate
↓
HTTPS Enabled
Dzięki temu certyfikaty mogą odnawiać się automatycznie.
Ingress jako Reverse Proxy
Ingress pełni podobną rolę jak:
- NGINX,
- Apache,
- HAProxy.
Może wykonywać:
- routing,
- przekierowania,
- nagłówki HTTP,
- limity połączeń,
- rate limiting.
Rate Limiting
Przykład ochrony API:
Client
↓
10000 requests/sec
↓
Ingress
↓
BLOCK
Reguła:
Maximum:
100 requests/minute
Chroni przed:
- botami,
- prostymi DoS,
- nadużyciem API.
Authentication na poziomie Ingress
Ingress może integrować się z:
- OAuth2,
- OpenID Connect,
- LDAP,
- SSO.
Przykład:
User
↓
Ingress
↓
Authentication
↓
Application
Aplikacja nie musi sama implementować logowania.
Ingress i bezpieczeństwo
Sam Ingress jest elementem krytycznym.
Błędy konfiguracji mogą prowadzić do:
- nieautoryzowanego dostępu,
- wycieku usług,
- błędnego routingu,
- ujawnienia aplikacji administracyjnych.
Najważniejsze zabezpieczenia
1. TLS wszędzie
Nie:
HTTP
Tak:
HTTPS
2. Ograniczenie dostępnych usług
Nie publikuj:
database-admin.example.com
jeżeli nie jest to konieczne.
3. Security Headers
Przykłady:
X-Frame-Options
Content-Security-Policy
HSTS
4. WAF przed Ingress
Często stosuje się:
Internet
↓
WAF
↓
Load Balancer
↓
Ingress Controller
↓
Application
Przykłady:
- ModSecurity,
- Cloudflare WAF,
- AWS WAF.
Ingress Controller i Network Policies
Ingress powinien współpracować z Network Policies.
Przykład:
Dozwolone:
Ingress Controller
↓
Frontend Service
Zablokowane:
Internet
↓
Database Pod
Monitoring Ingress
Warto monitorować:
- liczbę requestów,
- błędy HTTP,
- czas odpowiedzi,
- nietypowe wzorce ruchu.
Popularne narzędzia:
- Prometheus,
- Grafana,
- Loki,
- Elasticsearch.
Przykładowe metryki:
HTTP 200
HTTP 404
HTTP 500
Latency
Requests/sec
Ingress Controller w architekturze produkcyjnej
Internet
|
↓
Firewall
|
↓
Load Balancer
|
↓
Ingress Controller
/ \
/ \
Frontend API
Service Service
| |
Pods Pods
↓
Network Policies
↓
Backend Services
Najczęstsze błędy
❌ brak TLS
❌ publikowanie paneli administracyjnych
❌ brak rate limiting
❌ brak monitoringu
❌ brak Network Policies
❌ jeden ogromny Ingress dla całej infrastruktury
❌ przechowywanie certyfikatów bez odpowiedniej ochrony
Najlepsze praktyki
✅ używaj HTTPS wszędzie
✅ automatyzuj certyfikaty przez cert-manager
✅ ograniczaj dostęp przez Network Policies
✅ monitoruj ruch
✅ stosuj WAF dla aplikacji publicznych
✅ używaj osobnych reguł dla różnych aplikacji
✅ regularnie audytuj konfigurację Ingress
Podsumowanie
Ingress Controller jest jednym z kluczowych elementów produkcyjnego klastra Kubernetes. Zapewnia kontrolowany dostęp zewnętrzny do aplikacji, zastępując wiele indywidualnych Load Balancerów i centralizując zarządzanie ruchem HTTP/HTTPS.
W bezpiecznej architekturze Kubernetes Ingress nie działa samodzielnie. Powinien współpracować z:
- Network Policies,
- TLS,
- RBAC,
- WAF,
- monitoringiem,
- Pod Security Standards.
Najważniejsza zasada:
Ingress powinien być jedyną kontrolowaną bramą do aplikacji, a nie otwartym wejściem do całego klastra.
Tryb gry Windows 11 - czy warto go włączać? Tryb gry to funkcja systemu Windows 11, która ma na celu Czytaj dalej
Aby pobrać plik ISO bądź wykonać nośnik instalacyjny wystarczy wejść na stronę: https://www.microsoft.com/pl-pl/software-download/windows10 Po wejściu na stronę musimy upewnić się, Czytaj dalej
