İçeriğe geç

Teknik derinlik

Kubernetes Ingress DDoS Sıkılaştırma

Son güncelleme: Ağustos 2026 · Kenarda limitler, faturaya sınır · Okuma süresi ~14 dk

Sınırlı bir havuzdan çekim yapılıyor; yalnız ölçeklemenin cevaplayamayacağı yükün tükettiği pod ve düğüm kaynaklarını temsil ediyor.

Kubernetes DDoS açısından iki şeyi değiştiriyor. Bağlantı ve istek limitlerinin yeri, boğaz noktası olan ingress denetleyicisidir; ve otomatik ölçekleme, sınırları çizilmediği sürece bir erişilebilirlik problemini bir fatura problemine çevirir. Bir saldırıyı emmek için ölçeklenen bir küme, saldırıyı azaltmamış, satın almıştır.

Saldırı altında Kubernetes’i sabit bir ağdan ayıran iki şey var, ve ikisi de konteyner çalışma zamanıyla ilgili değil.

Birincisi, ingress denetleyicisinin olağandışı biçimde temiz bir boğaz noktası olması. Tek bir bileşen, bildirimle yapılandırılıyor, ve dışarıdan gelen her istek oradan geçiyor. İkincisi, kümenin büyüyebilme yeteneğinin bir varlık kadar bir yükümlülük de olması. Meşru bir sıçramayı emen esneklik, bir saldırıyı da emer ve bedelini öder.

0. Temel ölçüler

# What the ingress controller is currently handling
kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- \
  curl -s localhost:10254/metrics | grep -E 'nginx_ingress_controller_(requests|connections)'

# Current replica counts and what the HPA thinks
kubectl get hpa -A
kubectl top pods -A --sort-by=cpu | head -20
kubectl top nodes

# Which workloads have no limits at all — the blast-radius question
kubectl get pods -A -o json | jq -r '
  .items[] | select(.spec.containers[].resources.limits == null)
  | "\(.metadata.namespace)/\(.metadata.name)"' | head

1. Ingress denetleyicisi: bağlantı ve istek limitleri

ingress-nginx açıklamalarıyla, ki bunlar nginx sıkılaştırma rehberinde işlenen direktiflerin aynısına karşılık geliyor:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    # Requests per second per source address, with a burst allowance.
    nginx.ingress.kubernetes.io/limit-rps: "50"
    nginx.ingress.kubernetes.io/limit-burst-multiplier: "3"
    # Concurrent connections per source.
    nginx.ingress.kubernetes.io/limit-connections: "20"
    # Bound the request body so an upload path is not a memory attack.
    nginx.ingress.kubernetes.io/proxy-body-size: "8m"
    # The slow-HTTP answer: bound how long a client may take.
    nginx.ingress.kubernetes.io/client-body-timeout: "10"
    nginx.ingress.kubernetes.io/client-header-timeout: "10"
spec:
  ingressClassName: nginx
  rules:
    - host: example.test
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

Denetleyici geneli varsayılanların yeri her Ingress değil ConfigMap’tir:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  # Worker connection ceiling and keepalive behaviour
  max-worker-connections: "65536"
  keep-alive: "30"
  keep-alive-requests: "100"
  # Slow-HTTP bounds applied globally
  client-body-timeout: "10"
  client-header-timeout: "10"
  # Do not let a single upstream hold connections indefinitely
  upstream-keepalive-timeout: "30"
  # Log the rate-limit rejections so false positives are visible
  log-format-escape-json: "true"

Limitin sandığınız yerde ateşlendiğini doğrulayın:

# Should start returning 503 from the ingress, not from the app
for i in $(seq 1 200); do
  curl -s -o /dev/null -w '%{http_code}\n' https://example.test/ &
done | sort | uniq -c

2. Otomatik ölçeklemeyi bilinçli olarak sınırlamak

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  # The number that decides what an attack costs you. Choose it as a
  # budget decision, not as a capacity guess.
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      # Do not let a burst produce an instant tenfold scale-out.
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300

Bu sayfadaki en sonuçlu satır maxReplicas. Yüksek bırakıldığında ya da hiç konmadığında küme, bir saldırıya ona hizmet edecek kapasiteyi satın alarak cevap verir. Servis ayakta kalır ve zarar faturaya taşınır. Bu zaman zaman doğru takastır, ve her seferinde birinin bilerek verdiği bir karar olmalıdır.

3. Etki alanı denetimi olarak kaynak limitleri

resources:
  requests:
    cpu: 200m
    memory: 256Mi
  limits:
    # A pod without a memory limit under flood can take neighbours with it.
    cpu: "1"
    memory: 512Mi
# Namespace-wide floor so a workload cannot be deployed without limits
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: budget
spec:
  hard:
    requests.cpu: "40"
    requests.memory: 80Gi
    pods: "150"

ResourceQuota, maxReplicas kuralının küme düzeyindeki karşılığıdır. Bir ad alanının, kendi ölçekleyicisi ne isterse istesin, ne kadar tüketebileceğini sınırlar.

4. Ingress’in kendisini ayakta tutmak

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
# Ingress controllers deserve guaranteed resources of their own —
# the component that sheds load must not be the one that is starved.
resources:
  requests:
    cpu: "1"
    memory: 1Gi
  limits:
    cpu: "2"
    memory: 2Gi

Yükü atan bileşenin, aç kalan bileşen olmaması gerekir.

5. Ağ politikası: yanal açığı daraltmak

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-ingress-only
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx

Bu bir seli durdurmuyor. Bir iş yüküne ulaşmış bir selin diğerlerine ulaşmasını durduruyor, ki bu bir olay ile küme geneli bir olay arasındaki farktır.

6. İzleme

# Rejections at the ingress, by status
kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- \
  curl -s localhost:10254/metrics \
  | grep 'nginx_ingress_controller_requests' | grep -E 'status="(429|503)"'

# Whether the HPA is at its ceiling — the moment cost becomes the constraint
kubectl get hpa web -o jsonpath='{.status.currentReplicas}/{.spec.maxReplicas}{"\n"}'

# Pods being OOM-killed under load
kubectl get events -A --field-selector reason=OOMKilling

Alarm kurulmaya değer ölçüt HPA’nın tavanda olması. Kümenin emmeyi bırakıp atmaya başladığı an odur, ve kullanıcı şikâyetlerinden çok daha erken bir işarettir.

Güvenli devreye alma sırası

  1. Önce kaynak limitleri ve bir LimitRange ekleyin. En düşük risk, anında etki alanı faydası.
  2. maxReplicas değerini bir bütçe kararı olarak bilinçle koyun.
  3. Ingress timeout’larını ekleyin.
  4. Oran limitlerini gevşek bir ayarla ekleyin ve tam bir iş tepesi boyunca 429 oranını izleyin.
  5. Yalnız ölçümün desteklediği kadarını sıkın.

Geri alma

kubectl rollout undo deployment/web
kubectl -n ingress-nginx rollout undo deployment/ingress-nginx-controller
# Annotations are per-Ingress; remove the limit annotations to revert instantly
kubectl annotate ingress web nginx.ingress.kubernetes.io/limit-rps-

Dürüst sınır

Ingress denetleyicisi yalnız kendisine ulaşanı reddedebilir, ve ona ulaşan şey bulut yük dengeleyicinizi çoktan geçmiş ve giriş ile çıkış bant genişliği tahsisinizi çoktan harcamıştır. Bir küme doymaya karşı bir savunma değildir; doymanın altındaki her şey için ne yapılacağına karar verilecek, iyi ölçümlenmiş bir yerdir. Hacmi cevaplayan katman üst katmandır, ki mimari karşılaştırması bunu işliyor.

Sık sorulan sorular

Otomatik ölçekleme DDoS'a karşı koruyor mu?
Bir kesintiyi bir faturaya çeviriyor, ki bu bazen doğru takastır ve hiçbir zaman azaltma değildir. Ölçekleme, saldırı trafiğini ona hizmet edecek kapasiteyi satın alarak karşılar, ve elinde botnet olan bir saldırganın işletme maliyeti kümenin büyüme maliyetinden çok daha düşüktür. Azami kopya sayısını bilinçli olarak sınırlayın ve tavanın ne olduğuna faturada değil önceden karar verin.
Bir Kubernetes kümesinde hız sınırlama nereye konmalı?
Ingress denetleyicisine, çünkü bir isteği gören ve bir pod tüketmeden reddedebilen ilk bileşen odur. Uygulamanın içinde uygulanan limitler, herhangi bir şey reddedilmeden önce ingress, servis ve pod boyunca bir istek yolu maliyeti üretir.
Kaynak limitinin DDoS ile ne ilgisi var?
Etki alanını sınırlar. Bellek limiti olmayan ve sel altındaki bir pod, bir düğümün yanına yerleşmiş ilgisiz iş yüklerini etkileyecek kadarını tüketebilir, ve tek servisi hedefleyen bir saldırı küme geneli bir olaya dönüşür. Limitler ile istekler yalnız kapasite planlama aracı değil, aynı zamanda erişilebilirlik denetimidir.
Öndeki bulut yük dengeleyici bir şey yapıyor mu?
Bir miktar hacim emiyor ve bağlantıları sonlandırıyor, ki bu yardım eder. Genellikle yapmadığı şey, uygulamanızın maliyet yapısını anlamaktır; dolayısıyla bir uygulama katmanı seli oradan trafik görünümünde geçer. Yönetilen yük dengeleyicinin bir DDoS katmanı olduğunu varsaymak yerine sağlayıcınızın hangi paketinin neyi kapsadığını ayrıca kontrol edin.

Yayım: Ağustos 2026 · Son gözden geçirme: Ağustos 2026

Gözden geçirme, yukarıdaki kaynakların o tarihte yeniden okunduğu anlamına gelir; metin ancak esaslı bir değişiklik olduğunda yenilenir.

Bu rehber, üreticiler yeni modeller ve fiyatlandırma açıkladıkça güncellenir. Üreticileri nasıl karşılaştırıyoruz