როგორ აკონტროლებთ კონტეინერის რესურსებს (CPU და მეხსიერება)?

Question

Accepted Answer

ნაგულისხმევად, კონტეინერებმა შეუძლიათ გამოიყენონ **შეზღუდული მასპინძელი რესურსები** — რაც ერთი კონტეინერის სხვების დამშიდოვების ან მასპინძელის დამხობის რისკს ქმნის. 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`) ზღუდავენ გამოყენებას (კონტეინერი **OOM-დაბიჯდება**, თუ ის აკმაყოფილებს მკაცრ ლიმიტს); 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
```

## რატომ მნიშვნელოვანია ეს

კონტეინერის რესურსის მენეჯმენტის გაგება მნიშვნელოვანია **კონტეინერების საიმედოდ production-ში შესახებ**, ამიტომ ეს ღირებული ოპერაციული ცოდნაა.

ძირითადი პრობლემა — ნაგულისხმევად, **კონტეინერებმა შეუძლიათ მოხმარონ ყველა ხელმისაწვდომი მასპინძელი რესურსი** — ეს რეალური რისკია: ერთი არასწორი ან დატვირთული კონტეინერი (მეხსიერების გაჟონვით ან ჩიხი პროცესით) შეუძლია **სხვა კონტეინერების დამშიდოვება ან მთელი მასპინძელი დამხობა** (მეხსიერების ბოლომდე), რაც მასპინძელს არასტაბილური აკეთებს.

**რესურსების ლიმიტების** დაყენება (მეხსიერება და CPU) ამას ხელს უშლის **კონტეინერების რესურსის მოხმარების იზოლირებით**, უზრუნველყოფს, რომ ერთი კონტეინერი არ შეუძლია სხვები ან მასპინძელი დაამხოს — ეს აუცილებელია სტაბილურობის თვალსაზრისით, როდესაც რამდენიმე კონტეინერი ხელმისაწვდომია მასპინძელზე (ნორმა production-ში).

**მეხსიერების ლიმიტების** დაყენების გაგება (კონტეინერი OOM-დაბიჯდება, თუ ის აკმაყოფილებს მკაცრ ლიმიტს) და **CPU ლიმიტები**, პლუს **რეზერვაციები** (მინიმუმების გარანტირება), არის პრაქტიკული მექანიზმი რესურსების კონტროლისა და სამართლიანი გაზიარებისთვის.

**მონიტორინგი და ოპტიმიზაციის** ცოდნა — `docker stats` გამოყენებით რეალური მოხმარების დაკვირვება და ლიმიტების სწორი განსაზღვრა, `OOMKilled`-ის აღიარება (კონტეინერი მეხსიერების ლიმიტს ხვდება) პრობლემების დიაგნოსტიკისთვის — მნიშვნელოვანია სწორი ლიმიტების დაყენებისთვის რეალური მოთხოვნილებების მიხედვით.

ეს ასევე უკავშირდება ორქესტრირებას: **Kubernetes იყენებს მსგავსი რესურსის მოთხოვნები/ლიმიტები**, რომლებიც აუცილებელია დაგეგმვასა და სტაბილურობისთვის, ამიტომ კონცეფციის გაგება ორქესტრირებულ გარემოში გადაინარჩუნება.

რადგან კონტეინერების მრავალობის საიმედო გაშვება მოითხოვს რესურსების კონფლიქტის პრევენციას და ჩიხი მოხმარების პრევენციას, და რადგან რესურსების ლიმიტები (მეხსიერება და CPU ლიმიტები, რეზერვაციები, მონიტორინგი) არის კონტეინერების იზოლირებისა და მასპინძელი სტაბილურობის დაცვის მექანიზმი, კონტეინერის რესურსის მენეჯმენტის გაგება ღირებული, პრაქტიკულად მნიშვნელოვანი ცოდნაა production კონტეინერის განლაგებისთვის — აუცილებელი მდგრადი მაქსიმალური-კონტეინერი მასპინძელში და კონცეფცია, რომელიც უშუალოდ გადაგვყავს ორქესტრირებულ გარემოში, როგორც Kubernetes, სადაც რესურსების სპეციფიკაცია ფუნდამენტალურია.