cgroups v2 – kontrola zasobów Linux od podstaw do zaawansowanych zastosowań
cgroups v2 – kontrola zasobów Linux od podstaw do zaawansowanych zastosowań
Współczesne systemy Linux coraz częściej działają jako platformy uruchamiające wiele różnych usług jednocześnie:
- kontenery Docker,
- klastry Kubernetes,
- bazy danych,
- serwery aplikacyjne,
- środowiska CI/CD,
- maszyny wirtualne.
Problem pojawia się wtedy, gdy jedna aplikacja zaczyna zużywać zbyt dużo zasobów.
Przykład:
Serwer produkcyjny
├── nginx
├── PostgreSQL
├── aplikacja Java
├── kontenery Docker
└── monitoring
Jeżeli jeden proces zacznie zużywać:
- 100% CPU,
- całą pamięć RAM,
- ogromną ilość I/O,
może doprowadzić do degradacji całego systemu.
Linux od dawna posiada mechanizm kontroli zasobów:
Control Groups (cgroups).
Nowsza generacja tego rozwiązania:
cgroups v2
stała się podstawą zarządzania zasobami w nowoczesnych środowiskach Linux.
Czym są cgroups?
cgroups (Control Groups) to mechanizm jądra Linux pozwalający grupować procesy i kontrolować ich wykorzystanie zasobów.
Najprościej:
cgroups pozwala administratorowi powiedzieć systemowi:
Ta grupa procesów może używać maksymalnie określonej ilości CPU, RAM lub dysku.
Schemat:
id="4h7m2z"
Procesy Linux
↓
Control Group
↓
Limity zasobów
↓
Kernel Linux
Przykład praktyczny
Bez cgroups:
Aplikacja A
↓
Zużywa 90% RAM
↓
System zaczyna zabijać procesy
Z cgroups:
Aplikacja A
↓
Limit RAM: 2 GB
↓
Po przekroczeniu limitu:
OOM Control
Pozostałe usługi nadal działają.
Historia cgroups
cgroups v1
Pierwsza wersja została wprowadzona przez Google i dodana do kernela Linux w 2008 roku.
Problem:
Każdy kontroler działał osobno.
Przykład:
CPU controller
Memory controller
Block IO controller
Network controller
Każdy miał własną hierarchię.
W dużych środowiskach powodowało to:
- komplikacje,
- problemy z zarządzaniem,
- trudniejszą integrację.
cgroups v2 – nowa architektura
cgroups v2 została zaprojektowana jako jednolity model.
Najważniejsze zmiany:
- jedna wspólna hierarchia,
- spójne zarządzanie procesami,
- lepsza integracja z systemd,
- prostsze limity zasobów.
Schemat:
id="q1r8tk"
cgroup v2
/
|
+-- system.slice
|
+-- user.slice
|
+-- docker.slice
Gdzie używane jest cgroups v2?
Obecnie jest fundamentem:
Docker
Kontenery korzystają z cgroups do:
- limitowania pamięci,
- CPU,
- I/O.
Kubernetes
Kubernetes wykorzystuje cgroups do:
- requests,
- limits,
- QoS klas.
systemd
systemd zarządza usługami poprzez cgroups.
Przykład:
id="2s5j9k"
systemd
|
+-- nginx.service
+-- mysql.service
+-- docker.service
Każda usługa posiada własną grupę procesów.
Jak sprawdzić, czy system używa cgroups v2?
Najprościej:
mount | grep cgroup
Przy cgroups v2 zobaczymy:
cgroup2 on /sys/fs/cgroup
Można również sprawdzić:
stat -fc %T /sys/fs/cgroup
Wynik:
cgroup2fs
oznacza aktywne cgroups v2.
Architektura cgroups v2
Główne elementy:
Hierarchia
Procesy są organizowane w drzewo.
Przykład:
id="v3n7xp"
/
├── system.slice
│ ├── ssh.service
│ └── nginx.service
│
└── user.slice
└── user-1000.slice
Kontrolery zasobów
Najważniejsze:
- CPU,
- Memory,
- IO,
- PIDs,
- Devices,
- Network.
CPU Control w cgroups v2
Pozwala kontrolować wykorzystanie procesora.
Przykład:
Aplikacja:
backup.service
otrzymuje:
CPU max 50%
W systemd:
[Service]
CPUQuota=50%
Efekt:
nawet jeżeli proces próbuje użyć całego CPU:
kernel ograniczy jego udział.
Memory Controller
Jeden z najważniejszych mechanizmów.
Możliwe limity:
- maksymalna pamięć,
- minimalna gwarantowana pamięć,
- reakcja na presję pamięci.
Przykład:
memory.max
2G
Proces nie przekroczy 2 GB RAM.
Memory Pressure
Nowością cgroups v2 jest lepsze monitorowanie presji pamięci.
System może wykrywać:
- brak wolnej pamięci,
- intensywne używanie swap,
- problemy aplikacji.
OOM w cgroups v2
Jeżeli proces przekroczy limit:
id="n4p8wq"
Aplikacja
↓
Memory limit
↓
OOM killer
↓
Proces zakończony
Nie musi ucierpieć cały system.
I/O Controller
Kontroluje dostęp do dysku.
Przykład:
Baza danych:
80% I/O
Backup:
20% I/O
Dzięki temu zadanie kopii nie blokuje produkcyjnej bazy.
PID Controller
Chroni system przed tworzeniem zbyt wielu procesów.
Przykład:
pids.max=500
Jeżeli aplikacja próbuje stworzyć 10000 procesów:
kernel blokuje kolejne.
cgroups v2 i systemd
To jeden z najważniejszych tematów.
W nowoczesnym Linux:
systemd automatycznie tworzy cgroups.
Przykład:
systemd
↓
system.slice
↓
nginx.service
↓
proces nginx
Sprawdzenie:
systemctl status nginx
Można zobaczyć:
Control Group:
/system.slice/nginx.service
Zarządzanie zasobami przez systemd
Przykład ograniczenia pamięci:
systemctl edit nginx
Dodajemy:
[Service]
MemoryMax=1G
Następnie:
systemctl daemon-reload
systemctl restart nginx
Od teraz nginx posiada limit:
RAM ≤ 1 GB
cgroups v2 i Docker
Docker wykorzystuje cgroups automatycznie.
Przykład:
Uruchomienie kontenera z limitem RAM:
docker run --memory=512m nginx
Docker tworzy:
id="1k4n8p"
docker container
↓
cgroup
↓
memory.max=512MB
cgroups v2 i Kubernetes
Kubernetes opiera swoje limity kontenerów właśnie na cgroups.
Przykład:
resources:
limits:
memory: "1Gi"
cpu: "1"
Kubernetes przekazuje te informacje do runtime:
Pod
↓
Container Runtime
↓
cgroups v2
↓
Kernel
QoS Classes w Kubernetes
Dzięki cgroups Kubernetes może określić priorytet:
Guaranteed
Najwyższa gwarancja zasobów.
Burstable
Możliwe zwiększenie użycia.
BestEffort
Najniższy priorytet.
cgroups v2 a bezpieczeństwo
Kontrola zasobów to również bezpieczeństwo.
Przykłady:
Ochrona przed fork bomb
Atak:
:(){ :|:& };:
Tworzy tysiące procesów.
cgroups:
pids.max=500
ogranicza skutki.
Izolacja usług
Jeżeli jedna usługa zostanie przejęta:
Atakujący
↓
Aplikacja
↓
Limit CPU/RAM
↓
Mniejszy wpływ na system
Zaawansowana diagnostyka cgroups v2
Lista aktywnych cgroups
systemd-cgls
Przykład:
├─system.slice
│ ├─nginx.service
│ └─mysql.service
Statystyki zasobów
systemd-cgtop
Pokazuje:
- CPU,
- RAM,
- I/O.
Informacje ręczne
Katalog:
/sys/fs/cgroup/
Przykład:
cat memory.current
cgroups v2 vs nice i ulimit
Często są mylone.
nice
Zmienia priorytet CPU.
Nie ustala twardego limitu.
ulimit
Dotyczy pojedynczego procesu użytkownika.
cgroups
Kontroluje całe grupy procesów.
Przykład:
Kontener Docker
↓
100 procesów
↓
jeden limit RAM
Najczęstsze problemy z cgroups v2
Kontener nie ma dostępu do zasobów
Przyczyna:
- błędna konfiguracja runtime,
- brak wsparcia cgroups v2.
Docker działa inaczej po migracji z v1
Niektóre starsze aplikacje zakładają strukturę v1.
Problemy z systemd
Najczęściej:
- ręczne zmiany w /sys/fs/cgroup,
- konflikt zarządzania.
Dobre praktyki administratora
1. Używaj systemd zamiast ręcznej edycji cgroup
systemd zapewnia:
- poprawne zależności,
- trwałość konfiguracji,
- łatwiejsze zarządzanie.
2. Ustalaj limity dla usług krytycznych
Przykład:
PostgreSQL
MemoryMax=16G
CPUQuota=400%
3. Monitoruj wykorzystanie zasobów
Narzędzia:
- systemd-cgtop,
- Prometheus,
- Grafana,
- node_exporter.
Podsumowanie
cgroups v2 jest jednym z fundamentów współczesnego Linux.
To mechanizm, który pozwala kontrolować:
- CPU,
- pamięć RAM,
- dyski,
- liczbę procesów,
- izolację usług.
Dzisiaj trudno wyobrazić sobie nowoczesną infrastrukturę bez cgroups:
- Docker używa go do kontenerów,
- Kubernetes wykorzystuje go do zarządzania workloadami,
- systemd używa go do kontroli usług.
Dla administratora Linux znajomość cgroups v2 oznacza możliwość projektowania stabilniejszych i bezpieczniejszych systemów.
W praktyce:
systemd zarządza usługami, a cgroups v2 kontroluje ich zasoby.
Razem tworzą podstawę działania współczesnych serwerów Linux.
Linux Immutable Systems: Jak działają nierozpisywalne systemy takie jak Ubuntu Core i Fedora Silverblue W świecie Linuksa coraz większą popularność Czytaj dalej
Docker security – największe błędy administratorów Konteneryzacja w systemie Linux stała się standardem w DevOps, chmurze i hostingu aplikacji. Narzędzie Czytaj dalej
