Ulaşım
- Adres:Batıkent Mh. 8910 Sk. 6. Etap 1H No: 18 Yeni Toki Eyyübiye / Şanlıurfa (Yeni Alım Satım Karşısı)
- Telefon:0 (545) 528 88 93
- eMail: info@alestaweb.com
Kubernetes cluster'ınızda pod'lar sürekli OOMKilled statusuyla mı crash oluyor? Exit Code 137 görüp ne yapacağınızı bilemiyor musunuz? Hiç panik yapmayın! Alesta Web olarak bu Kubernetes memory error sorununu adım adım çözeceğiz. Bu rehberde OOMKilled hatasının nedenlerini, teşhis yöntemlerini ve 6 kesin çözümü bulacaksınız.
Alesta Web ekibi olarak Kubernetes ortamlarında en sık karşılaştığımız hatalardan biri OOMKilled statusudur. Peki bu hata tam olarak ne anlama geliyor?
OOMKilled, "Out of Memory Killed" ifadesinin kısaltmasıdır. Linux kernel, bir container'ın kendisine ayrılan memory limitini aştığında bu container'ı zorla sonlandırır. Bu durum Exit Code 137 ile işaretlenir (128 + 9 = SIGKILL sinyali).
$ kubectl get pods NAME READY STATUS RESTARTS AGE my-app-7b9f8c4d5-x2k4j 0/1 OOMKilled 5 10m $ kubectl describe pod my-app-7b9f8c4d5-x2k4j ... Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Wed, 15 Jan 2026 10:30:00 +0300 Finished: Wed, 15 Jan 2026 10:32:15 +0300
Kubernetes, cgroups (control groups) adlı Linux kernel özelliğini kullanarak container'ların kaynak kullanımını sınırlar. Her container bir cgroup'a atanır ve bu cgroup'un belirli bir memory limiti vardır. Container bu limiti aşmaya çalıştığında, kernel OOM (Out of Memory) durumu tetikler ve container'ı öldürür.
Alesta Web deneyimlerine göre, OOMKilled hatası genellikle yanlış yapılandırılmış memory limit'lerden veya uygulama içindeki memory leak'lerden kaynaklanır. İyi haber şu ki, bu sorun çözülebilir!
Kubernetes OOMKilled hatasının 4 ana nedeni vardır. Alesta Web olarak bu nedenleri tek tek inceleyelim:
En yaygın neden budur. Uygulamanız gerçekte ihtiyaç duyduğundan daha düşük bir memory limit ile çalışıyor olabilir. Örneğin, uygulamanız 512MB bellek kullanıyorken limit 256MB olarak ayarlanmışsa, OOMKilled kaçınılmazdır.
Uygulama kodundaki memory leak'ler zamanla bellek kullanımının artmasına neden olur. Başlangıçta sorunsuz çalışan container, birkaç saat veya gün sonra OOMKilled ile sonlanabilir.
Ani trafik artışları, uygulamanın normalden çok daha fazla bellek tüketmesine yol açabilir. Özellikle e-ticaret siteleri ve API servisleri bu durumdan etkilenir.
Java uygulamalarında JVM heap size container limit'inden bağımsız çalışabilir. Bu durum container'ın limitini aşmasına neden olur.
Memory limit'i request'ten çok yüksek tutmak, node'larda overcommitment'a yol açar. Bu durum birden fazla pod'un aynı anda OOMKilled olmasına neden olabilir (cascading failure).
Alesta Web olarak OOMKilled hatasını teşhis etmek için kullandığımız komutları paylaşıyoruz:
# Pod'un son durumunu görüntüle kubectl describe pod <pod-name> | grep -A 5 "Last State" # Çıktı örneği: Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Wed, 15 Jan 2026 10:30:00 +0300 Finished: Wed, 15 Jan 2026 10:32:15 +0300
# Anlık memory kullanımı
kubectl top pod <pod-name>
# Tüm pod'ların memory kullanımı
kubectl top pods --all-namespaces | sort -k4 -h
# Container'ın memory limit'ini görüntüle
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'
# Namespace'deki tüm event'ler kubectl get events --namespace=<namespace> --sort-by='.lastTimestamp' # OOM ile ilgili event'ler kubectl get events --field-selector reason=OOMKilling
Exit Code 137 her zaman OOMKilled anlamına gelmez. Bazen manuel olarak gönderilen SIGKILL (kill -9) de aynı kodu üretir. Ancak kubectl describe çıktısında "Reason: OOMKilled" görüyorsanız, sorun kesinlikle memory ile ilgilidir.
En basit ve hızlı çözüm, container'ın memory limitini artırmaktır. Alesta Web olarak bu yöntemi çoğu durumda öneriyoruz.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: my-app
image: my-app:latest
resources:
requests:
memory: "256Mi" # Başlangıç isteği
cpu: "250m"
limits:
memory: "512Mi" # Maksimum limit (artırıldı!)
cpu: "500m"
# Mevcut limit'i görüntüle
kubectl get deployment my-app -o jsonpath='{.spec.template.spec.containers[0].resources}'
# Deployment'ı düzenle
kubectl edit deployment my-app
# Veya patch ile güncelle
kubectl patch deployment my-app --type='json' -p='[
{"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/memory", "value": "512Mi"}
]'
Memory limitini artırmadan önce, uygulamanızın gerçek memory kullanımını en az 24 saat izleyin. Prometheus veya Kubernetes Metrics Server kullanarak peak (en yüksek) değeri belirleyin ve limitinizi bu değerin %20-30 üzerinde tutun.
Kubernetes best practice'lerine göre, memory limit'i request'e eşit veya yakın tutmalısınız. Alesta Web ekibi olarak bu yaklaşımı şiddetle öneriyoruz.
resources:
requests:
memory: "512Mi" # Request = Limit (Best Practice!)
cpu: "250m"
limits:
memory: "512Mi" # Aynı değer
cpu: "1000m" # CPU için limit daha yüksek olabilir
Neden request = limit olmalı?
Request > Limit ayarı Kubernetes tarafından kabul edilmez ve deployment reddedilir. Her zaman request ≤ limit kuralına uyun.
Java uygulamaları container'larda çalışırken özel dikkat gerektirir. Alesta Web olarak Java 10+ sürümlerinde container-aware JVM ayarlarını kullanmanızı öneriyoruz.
# Dockerfile içinde JAVA_OPTS ayarı
ENV JAVA_OPTS="-XX:+UseContainerSupport \
-XX:MaxRAMPercentage=75.0 \
-XX:InitialRAMPercentage=50.0 \
-XX:+ExitOnOutOfMemoryError"
# Veya Kubernetes deployment'ta
containers:
- name: java-app
image: openjdk:17-slim
env:
- name: JAVA_OPTS
value: "-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0"
command: ["java", "$(JAVA_OPTS)", "-jar", "app.jar"]
| JVM Flag | Açıklama / Description |
|---|---|
-XX:+UseContainerSupport |
Container limitlerini algılar (Java 10+ default) |
-XX:MaxRAMPercentage=75.0 |
Container memory'nin %75'ini heap olarak kullan |
-XX:+ExitOnOutOfMemoryError |
OOM durumunda hızlı restart için çık |
Java 8 kullanıyorsanız, -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap flag'lerini eklemeniz gerekir. Ancak mümkünse Java 17+ LTS sürümüne geçmenizi öneriyoruz.
Kubernetes Vertical Pod Autoscaler (VPA), pod'ların CPU ve memory request/limit değerlerini otomatik olarak ayarlar. Alesta Web olarak production ortamlarında VPA kullanımını öneriyoruz.
# VPA'yı cluster'a yükle git clone https://github.com/kubernetes/autoscaler.git cd autoscaler/vertical-pod-autoscaler ./hack/vpa-up.sh # VPA durumunu kontrol et kubectl get pods -n kube-system | grep vpa
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: my-app-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: my-app
updatePolicy:
updateMode: "Auto" # Otomatik güncelleme
resourcePolicy:
containerPolicies:
- containerName: '*'
minAllowed:
memory: "128Mi"
maxAllowed:
memory: "2Gi"
controlledResources: ["memory"]
VPA Update Modları:
OOMKilled hatası tekrarlıyorsa, uygulamanızda memory leak olabilir. Alesta Web olarak memory leak tespiti için şu adımları öneriyoruz:
# Heap snapshot almak için node --inspect app.js # Chrome DevTools ile bağlan: chrome://inspect # Memory tab'ında heap snapshot al # Veya clinic.js kullan npm install -g clinic clinic doctor -- node app.js
# memory_profiler kullan
pip install memory_profiler
# Fonksiyon bazlı profiling
@profile
def my_function():
# kod buraya
# Çalıştır
python -m memory_profiler app.py
import _ "net/http/pprof"
// pprof endpoint'ini etkinleştir
go func() {
http.ListenAndServe(":6060", nil)
}()
// Heap profile al
go tool pprof http://localhost:6060/debug/pprof/heap
Memory leak'ler genellikle kapatılmayan database connection'lardan, cache'lenmiş ama temizlenmeyen objelerden veya event listener'ların kaldırılmamasından kaynaklanır.
OOMKilled hatalarını önlemenin en iyi yolu, proaktif monitoring ve alerting kurmaktır. Alesta Web olarak Prometheus + Grafana stack'ini öneriyoruz.
groups:
- name: kubernetes-memory-alerts
rules:
- alert: ContainerMemoryUsageHigh
expr: |
(container_memory_usage_bytes / container_spec_memory_limit_bytes) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "Container memory kullanımı %80'i aştı"
description: "{{ $labels.pod }} pod'u memory limitinin %{{ $value }}'ini kullanıyor"
- alert: PodOOMKilled
expr: |
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
for: 0m
labels:
severity: critical
annotations:
summary: "Pod OOMKilled ile sonlandı!"
description: "{{ $labels.pod }} pod'u OOMKilled durumunda"
# Memory kullanım yüzdesi
(container_memory_usage_bytes{pod=~"my-app.*"} / container_spec_memory_limit_bytes{pod=~"my-app.*"}) * 100
# OOMKilled event sayısı (son 24 saat)
sum(increase(kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}[24h]))
# Memory kullanım trendi
rate(container_memory_usage_bytes{pod=~"my-app.*"}[5m])
Memory kullanımı %70'i geçtiğinde warning, %85'i geçtiğinde critical alert gönderin. Böylece OOMKilled olmadan önce müdahale şansınız olur.
Bu makalede kullanılan bilgiler aşağıdaki güvenilir kaynaklardan derlenmiştir (information compiled from the following reliable sources):
Alesta Web olarak tüm bilgileri production ortamlarında test ettik ve doğruladık.
Artık Kubernetes OOMKilled hatası (Exit Code 137 memory error) geride kaldı! Alesta Web olarak bu rehberde 6 farklı çözüm yöntemini detaylı şekilde anlattık.
Hızlı Özet / Quick Summary:
Faydalı Linkler / Useful Links:
© 2026 AlestaWeb - Tüm hakları saklıdır. | alestaweb.com