Zarządzaj zasobami Dockera za pomocą Cgroups

W zeszłym miesiącu wygłosiłem prelekcję na ApacheCon o Cgroups. Wygląda na to, że bardzo niewielu użytkowników Linuksa (w tym ja sam do niedawna) zna Cgroups i ich możliwości. Szkoda, ponieważ Cgroups są bardzo potężne i pozwalają na alokację zasobów na serwerach w znacznie bardziej szczegółowy sposób niż jakiekolwiek inne narzędzie dostępne w pakiecie Linuksa. Co więcej, jest ono wbudowane bezpośrednio w jądro i jest dostarczane domyślnie z większością dystrybucji Linuksa.

W tym artykule omówię, jak używać Cgroups z Dockerem, co stanowi poniekąd kontynuację innej prelekcji, którą wygłosiłem na Docker Meetup w Austin w Teksasie.

Ten artykuł wymaga podstawowej wiedzy na temat Cgroups. Jeśli Cgroups to dla Ciebie zupełna nowość, polecam zapoznanie się z moją prezentacją z ApacheCon, a także z materiałami na końcu. Nie martw się jednak, nie będziemy zagłębiać się zbyt mocno. Jeśli tylko przejrzysz slajdy, powinieneś bez problemu zrozumieć podstawowe pojęcia.

Docker i Cgroups

Docker jest wyposażony w dwa różne sterowniki: LXC i libcontainer. Sterownik LXC jest sterownikiem przestarzałym (legacy), a libcontainer to nowy i domyślny sterownik. W większości przypadków preferowanym sterownikiem jest libcontainer, ponieważ to tam wprowadzane są innowacje (na przykład docker exec nie działa ze sterownikiem LXC).

Należy jednak pamiętać, że istnieją dwa różne sterowniki, ponieważ nie wszystkie możliwości Cgroup zostały jeszcze przeniesione do libcontainer (lub przynajmniej udostępnione w Dockerze). Podczas korzystania ze sterownika LXC po prostu przekazuje się argumenty LXC bezpośrednio, podczas gdy w przypadku libcontainer istnieją jawne argumenty polityki Cgroup udostępnione dla Dockera. Będziesz musiał jawnie ustawić sterownik podczas uruchamiania demona Docker, więc nie możesz uruchomić obu sterowników jednocześnie.

Oto przykład, jak można to sprawdzić:

[bash light=”true”] # Ze sterownikiem LXC
$ docker run -d –name=’lxc_test’ \
–lxc-conf="lxc.cgroup.cpu.shares=50" \
busybox

# Ze sterownikiem libcontainer
$ docker run -d –name=’libcontainer_test’ \
–cpu-shares=50 \
busybox
[/bash]

Oto przegląd niektórych funkcji Cgroup i ich mapowania między dwoma sterownikami:

Funkcja	Libcontainer	LXC
Względny udział procesora (CPU share)	-c, –cpu-shares	–lxc-conf=”lxc.cgroup.cpu.shares”
Przypisanie do rdzenia procesora	–cpuset-cpus	–lxc-conf=”lxc.cgroup.cpuset.cpus”
Ograniczenie pamięci	-m, –memory	–lxc-conf=”lxc.cgroup.cpuset.mems”

LXC

Jeśli chcesz używać sterownika LXC dla Dockera, najpierw musisz go włączyć. Metoda wykonania tego będzie się różnić w zależności od dystrybucji Linuksa, ale oto instrukcje dotyczące tego, jak włączyć sterownik LXC w systemie Ubuntu 14.04.

Jak wspomniano powyżej, decydując się na to, rezygnujesz z wielu funkcji. Dlatego, o ile naprawdę nie potrzebujesz funkcjonalności, która nie została jeszcze udostępniona w Dockerze przy użyciu libcontainer, powinieneś trzymać się domyślnego sterownika.

Niektóre przydatne polityki Cgroup, które nie zostały jeszcze udostępnione w libcontainer, obejmują dławienie wejścia/wyjścia (I/O throttling, omówione w prezentacji), co może być bardzo przydatne w przypadku niektórych aplikacji.

Jeśli zdecydowałeś się na użycie sterownika LXC, dodawanie argumentów jest proste. Wszystko, co musisz zrobić, to dodać argument --lxc-conf i przekazać politykę Cgroup, którą chcesz ustawić.

Libcontainer

Jak widać w powyższej tabeli, podstawowe polityki Cgroup są już udostępnione w obecnej wersji Dockera (1.6 w momencie pisania tego tekstu).

Korzystanie z tych polityk jest bardzo proste. Jeśli na przykład chcesz przypisać kontener Dockera do pierwszego rdzenia procesora, należy dodać --cpuset-cpus=0 do swojego polecenia docker run.

Możesz również użyć argumentu --cgroup-parent z libcontainer i ręcznie ustawić bardziej szczegółowe ograniczenia zasobów. Następnie zmapowałbyś go do tej grupy za pomocą tego argumentu.

Demo: Docker z Cgroups

W poniższym nagraniu ekranu użyjemy dwóch kontenerów Docker (‘low_prio’ i ‘high_prio’). Używamy bazowego kontenera ‘busybox’ i uruchamiamy md5sum /dev/urandom , aby zasymulować proces mocno obciążający procesor. Domyślnie zużyłoby to wszystkie dostępne zasoby procesora. Zastosujemy jednak dwie polityki Cgroup, aby zarządzać zasobami. Najpierw użyjemy ‘cpuset.cpus’, aby przypisać kontenery do tego samego rdzenia procesora (rdzeń 0).

Następnie użyjemy ‘cpu.shares’, aby przypisać względny udział procesora. Kontenerowi ‘low_prio’ przypiszemy wartość 20, a ‘high_prio’ wartość 80. Oznacza to, że 20% procesora zostanie przydzielone kontenerowi ‘low_prio’, a 80% procesora kontenerowi ‘high_prio’. Należy jednak pamiętać, że względny udział jest skalą dowolną (równie dobrze moglibyśmy użyć wartości 2 i 8).

Po zademonstrowaniu, że zarządzanie zasobami rzeczywiście działa, uruchomimy ten sam zestaw kontenerów bez żadnych polityk Cgroup, aby zobaczyć, jak się zachowają.

Dla odniesienia, oto polecenia użyte do uruchomienia kontenerów.

[bash light=”true”] $ docker run -d \
–name=’low_prio’ \
–cpuset-cpus=0 \
–cpu-shares=20 \
busybox md5sum /dev/urandom
$ docker run -d \
–name=’high_prio’ \
–cpuset-cpus=0 \
–cpu-shares=80 \
busybox md5sum /dev/urandom
[/bash]

Podsumowanie

Jeśli zarządzasz wieloma kontenerami Docker na tym samym hoście, używanie Cgroups do zarządzania zasobami między kontenerami ma ogromny sens. Na przykład, być może w jednym kontenerze działają zadania przetwarzania w tle, a inny kontener obsługuje treści dla użytkowników. W takim przypadku możesz wykorzystać nowo nabytą wiedzę, aby upewnić się, że nadasz priorytet kontenerom obsługującym użytkowników przed zadaniami w tle.