Traefik; Containous (sonradan Traefik Labs) tarafından geliştirilen, konteyner çağı için tasarlanmış L7 reverse proxy ve yük dengeleyicidir. Geleneksel reverse proxy’lerin aksine konfigürasyon dosyasıyla statik tanım yerine, çalışma ortamından (Docker, Kubernetes, Consul, ECS) dinamik servis keşfi yapar.
Bir servisin yeni bir replica’sı çalıştığında Traefik bunu konfigürasyon değişikliği veya reload olmadan otomatik tanır ve yük dağıtmaya başlar. Bu özellik özellikle blue-green / canary deploy’lerde, yatay ölçeklendirmede ve mikroservis ortamlarında geliştirici deneyimini ciddi iyileştirir.
Mono’nun yaklaşımı
Mono ekibi Traefik’i hem K8s ingress controller olarak hem de VM/Docker host ortamlarında reverse proxy olarak kullanır. Standart kurulum kararları:
- TLS: Let’s Encrypt + DNS-01 challenge (Cloudflare); wildcard sertifika *.example.com.
- Provider önceliği: K8s’te
kubernetescrd(IngressRoute), VM’defileprovider; ikisinin paralel çalıştığı hibrit kurulumlar mümkün. - Middleware kütüphanesi: Standart Mono middleware paketi - auth (forward-auth → Keycloak), rate-limit, security headers, gzip/brotli sıkıştırma, retry.
- Observability: Prometheus metrikleri açık, access log JSON formatta Loki’ye, Tempo ile request tracing.
- Oturum yönetimi: Gerekli uygulamalarda cookie affinity; yük dağıtım algoritması kullanılan sürümün desteklediği seçeneklerle doğrulanır.
Tipik kurulum
K8s’te desteklenen Ingress, Gateway API veya IngressRoute kaynaklarıyla yönlendirme tanımlanabilir. Deployment ile route manifest’lerinin aynı pakette tutulması değişiklikleri sürümlemeyi kolaylaştırır; Kubernetes kaynakları ayrı uzlaştırıldığından atomik güncelleme garantisi vermez. Readiness ve yayın sırası ayrıca tasarlanır.
Docker host’ta servis label’ları (traefik.http.routers.web.rule) kullanılır; docker compose dosyası tek başına route + TLS yönetimini içerir.
Yaygın sorunlar ve çözümler
- 404 sorunu route doğru görünüyor: TLS ile HTTP arasındaki entrypoint farkı. Her iki entrypoint için ayrı router (HTTP redirect dahil).
- ACME rate-limit: Test ortamında staging endpoint kullanın (
caServer: https://acme-staging-v02.api.letsencrypt.org/directory); CI’da sertifika cache’i. - Yavaş ilk istek: Backend başlangıcı, DNS, TLS ve bağlantı kurulumu ayrı ölçülür; timeout artırmak varsayılan çözüm değildir.
- Bellek artışı: Kaynak sayısı, trafik ve gözlemlenebilirlik ayarları ölçülür; sürüm notları ve yeniden üretilebilir hata bulguları incelenir.
- WebSocket kopması: İstemci, proxy ve backend sınırları birlikte test edilir. Boş HTTP keepalive bağlantı ayarı aktif WebSocket ömrüyle karıştırılmaz.
Router, middleware ve service ayrımı
Traefik’te router gelen isteğin hangi kuralla eşleştiğini belirler; middleware isteğe veya yanıta politika uygular; service trafiğin gideceği backend’i tanımlar. Bu sorumlulukları ayrı düşünmek hata ayıklamayı kolaylaştırır. 404, eşleşmeyen bir route’tan kaynaklanabilirken 502/503 backend erişimi veya uygun hedef bulunmamasıyla ilişkili olabilir.
Middleware sırası önemlidir. Path’i değiştirdikten sonra uygulanan kimlik doğrulama, orijinal path üzerinden çalışan politikadan farklı sonuç verebilir. Forward-auth tarafında kullanılan servis ve protokolün gerçekten uyumlu olması gerekir; bir kimlik sağlayıcının adını konfigürasyona yazmak tek başına entegrasyon oluşturmaz. Retry politikası da idempotent olmayan işlemlerde çift işlem riskini gözetmelidir.
Çok replikalı Traefik’te sertifika yönetimi
Tek instance için çalışan yerleşik ACME düzeni, birden fazla instance’a dosya kopyalayarak güvenle ölçeklenmiş sayılmaz. Sertifika edinme ve yenileme koordinasyonu, depolama ve challenge trafiğinin doğru node’a ulaşması planlanmalıdır. Kubernetes ortamında cert-manager gibi ayrı bir sertifika yöneticisinin ürettiği Secret’ları kullanmak bu sorumlulukları ayırmanın bir yoludur.
DNS-01 wildcard sertifikalara imkân verir; fakat DNS API anahtarının kapsamı ve yenileme hatalarının alarmı önemlidir. Testlerde sertifika otoritesinin staging ortamı kullanılır. Uygulama erişilebilirken yaklaşan sertifika süresinin gözden kaçmaması için süre takibi ayrı yapılır.
Docker ve Kubernetes güvenlik sınırları
| Ortam | Kritik kontrol |
|---|---|
| Docker provider | Docker API erişiminin güçlü yetkiler taşıdığı hesaba katılır. |
| Kubernetes | RBAC ve namespace kapsamı ihtiyaç kadar sınırlandırılır. |
| Dashboard | Yönetim arayüzü internete kimliksiz açılmaz. |
| Çok ekipli küme | Route, middleware ve TLS Secret sahipliği açıkça tanımlanır. |
Docker socket’i salt okunur mount etmek, API üzerindeki bütün işlemleri otomatik olarak güvenli yapmaz. Erişim modeli ayrıca sınırlandırılmalıdır. Benzer şekilde birden fazla ekibin ortak middleware değiştirebilmesi başka uygulamaların trafiğini etkileyebilir; paylaşılan bileşenlerde inceleme ve yetki ayrımı gerekir.
Mono’nun geçiş değerlendirmesi
Mevcut route’lar, sertifikalar ve uygulama protokolleri çıkarıldıktan sonra pilot servis seçilir. Başarı ölçütleri yalnızca HTTP 200 değildir: gerçek istemci IP’si, oturum açma, yönlendirme, WebSocket ve backend arızası kontrol edilir. Nginx tabanlı bir controller’dan geçişte annotation’ların birebir karşılığı olduğu varsayılmaz. Her kural test edilerek taşınır; geri dönüşte DNS ve istemci önbelleklerinin etkisi hesaba katılır.
