Konteyner kaynaklarını (CPU ve bellek) nasıl yönetirsiniz?

Question

Accepted Answer

Varsayılan olarak, konteynerler **sınırsız host kaynakları** kullanabilir — bu da bir konteynerin diğerlerini açlıkta bırakması veya host'u kilitlemesi riskini taşır. Docker, **kaynak limitleri** (CPU, bellek) ayarlamanıza izin vererek tüketimi kontrol etmek, stabilite ve üretim ortamında adil kaynak paylaşımı için önemlidir.

## Sorun: sınırsız kaynak kullanımı

```text
BY DEFAULT a container can consume ALL available host CPU and memory:
  → a buggy/busy container (memory leak, runaway loop) can starve other containers
    or crash the entire host (out of memory)
→ In production (multiple containers per host), LIMIT resources to isolate them.
```

## Bellek ve CPU limitlerini ayarlama

```bash
# memory limits
docker run -m 512m myapp              # hard limit: 512 MB (container killed if exceeded — OOM)
docker run -m 512m --memory-reservation 256m myapp   # soft limit + hard limit

# CPU limits
docker run --cpus="1.5" myapp         # limit to 1.5 CPU cores
docker run --cpu-shares=512 myapp     # relative weight (priority under contention)
```

```yaml
# in docker-compose.yml (or for orchestrators)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # maximum
        reservations: { cpus: '0.5', memory: 256M } # guaranteed minimum
```

Bellek limitleri (`-m`) kullanımı sınırlandırır (konteyner hard limiti aşarsa **OOM-killed** olur); CPU limitleri (`--cpus`) CPU kullanımını sınırlandırır. **Reservations** bir minimumu garanti eder.

## İzleme ve ayarlamalar

```text
✓ docker stats → live CPU/memory usage per container (to right-size limits)
✓ Set limits based on the app's actual needs (measure, then add headroom)
✓ OOMKilled (in docker inspect) → the container hit its memory limit → raise it or fix a leak
✓ Orchestrators (Kubernetes) use requests/limits similarly — essential for scheduling
```

## Neden önemli

Konteyner kaynak yönetimini anlamak **konteynerleri üretim ortamında güvenilir bir şekilde çalıştırmak** için önemlidir, bu nedenle değerli operasyonel bilgidir.

Temel sorun — varsayılan olarak, **konteynerler tüm kullanılabilir host kaynaklarını tüketebilir** — gerçek bir risktir: tek bir hatalı veya meşgul konteyner (bellek sızıntısı veya kaçak süreç ile) **diğer konteynerleri açlıkta bırakabilir veya tüm host'u kilitleyebilir** (bellek yetersizliği), host'u kararsız hale getirerek.

**Kaynak limitleri** (bellek ve CPU) ayarlamak bunu **konteynerlerin kaynak tüketimini izole ederek** önler, bir konteynerin diğerlerini veya host'u kilitlemesini engeller — çok sayıda konteynerin host başına çalıştırıldığında stabilite için gereklidir (üretim ortamında norm).

**Bellek limitlerini** (konteynerin hard limiti aşarsa OOM-killed olması durumu) ve **CPU limitlerini**, artı **reservations'ları** (minimumlara garanti vererek) nasıl ayarlayacağını anlamak, kaynak kontrolü ve adil paylaşımı sağlamak için pratik mekanizmadır.

**İzleme ve ayarlamaları** bilmek — gerçek kullanımı gözlemlemek ve limitleri uygun şekilde boyutlandırmak için `docker stats` kullanmak, sorunları teşhis etmek için `OOMKilled` (bir konteynerin bellek limitine ulaşması) durumunu tanımak — gerçek ihtiyaçlara göre uygun limitleri ayarlamak için önemlidir.

Bu, orkestrasyon ile de bağlantılıdır: **Kubernetes benzer kaynak talepleri/limitleri kullanır** ki bu planlama ve stabilite için gereklidir, dolayısıyla konsepti anlamak orkestrasyon sağlanan ortamlara aktarılır.

Birden fazla konteyneri güvenilir bir şekilde çalıştırmak kaynak çekişmesini ve kaçak tüketimi önlemeyi gerekli kıldığından ve kaynak limitleri (bellek ve CPU tavanları, reservations, izleme) konteynerleri izole etmek ve host stabilitesini korumak için mekanizma olduğundan, konteyner kaynak yönetimini anlamak üretim konteyner dağıtımları için değerli, pratik-önemli bilgidir — stabil çok-konteyner host'lar için gereklidir ve bir konsept olarak Kubernetes gibi orkestrasyon sağlanan ortamlara doğrudan genişletilir, burada kaynak belirtimi temeldir.