Πώς διαχειρίζεστε τους πόρους του container (CPU και μνήμη);

Question

Accepted Answer

Από προεπιλογή, τα containers μπορούν να χρησιμοποιήσουν **απεριόριστους πόρους του host** — κάτι που ενέχει τον κίνδυνο ένα container να στερήσει πόρους από άλλα ή να κρασάρει το host. Το Docker σας επιτρέπει να ορίσετε **όρια πόρων** (CPU, μνήμη) για να ελέγχετε την κατανάλωση, κάτι σημαντικό για την σταθερότητα και τη δίκαιη κατανομή πόρων σε production.

## Το πρόβλημα: απεριόριστη χρήση πόρων

```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.
```

## Ορισμός ορίων μνήμης και CPU

```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
```

Τα όρια μνήμης (`-m`) περιορίζουν την χρήση (το container θα **OOM-killed** εάν υπερβεί το σκληρό όριο). Τα όρια CPU (`--cpus`) περιορίζουν την χρήση CPU. Οι **κρατήσεις** εγγυώνται ένα ελάχιστο.

## Παρακολούθηση και ρύθμιση

```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
```

## Γιατί έχει σημασία

Η κατανόηση της διαχείρισης πόρων container είναι σημαντική για **την αξιόπιστη εκτέλεση containers σε production**, οπότε αποτελεί πολύτιμη επιχειρησιακή γνώση.

Το κύριο ζήτημα — από προεπιλογή, **τα containers μπορούν να καταναλώσουν όλους τους διαθέσιμους πόρους του host** — είναι ένας πραγματικός κίνδυνος: ένα μόνο ελαττωματικό ή απασχολημένο container (με memory leak ή runaway process) μπορεί να **στερήσει πόρους από άλλα containers ή να κρασάρει ολόκληρο το host** (out of memory), κάνοντας το host ασταθές.

Ο ορισμός **ορίων πόρων** (μνήμης και CPU) το αποτρέπει αυτό **απομονώνοντας την κατανάλωση πόρων των containers**, διασφαλίζοντας ότι ένα container δεν μπορεί να κατρακυλήσει άλλα ή το host — απαραίτητο για τη σταθερότητα κατά την εκτέλεση πολλών containers ανά host (το πρότυπο σε production).

Η κατανόηση του τρόπου ορισμού **ορίων μνήμης** (με το container να είναι OOM-killed εάν υπερβεί το σκληρό όριο) και **ορίων CPU**, συν **κρατήσεων** (που εγγυώνται τα ελάχιστα), είναι ο πρακτικός μηχανισμός για τον έλεγχο και τη δίκαιη κατανομή πόρων.

Η γνώση του τρόπου **παρακολούθησης και ρύθμισης** — χρησιμοποιώντας `docker stats` για παρατήρηση της πραγματικής χρήσης και σωστού διαστασιολόγησης ορίων, αναγνώρισης `OOMKilled` (ένα container που χτυπά το όριό του σε μνήμη) για διάγνωση προβλημάτων — είναι σημαντική για τον ορισμό κατάλληλων ορίων με βάση τις πραγματικές ανάγκες.

Αυτό συνδέεται επίσης με την ορχήστρωση: **το Kubernetes χρησιμοποιεί παρόμοια resource requests/limits** που είναι απαραίτητα για την χρονοδιαγραμμάτιση και τη σταθερότητα, οπότε η κατανόηση της έννοιας μεταφέρεται σε ενορχηστρωμένα περιβάλλοντα.

Επειδή η αξιόπιστη εκτέλεση πολλών containers απαιτεί την αποτροπή της διαμάχης πόρων και της runaway κατανάλωσης, και επειδή τα όρια πόρων (caps μνήμης και CPU, κρατήσεις, παρακολούθηση) είναι ο μηχανισμός για την απομόνωση containers και την προστασία της σταθερότητας του host, η κατανόηση της διαχείρισης πόρων container είναι πολύτιμη, πρακτικά σημαντική γνώση για production container deployments — απαραίτητη για σταθερά multi-container hosts και μια έννοια που επεκτείνεται άμεσα σε ενορχηστρωμένα περιβάλλοντα όπως το Kubernetes, όπου η ενορχήστρωση πόρων είναι θεμελιώδης.