Gerenciar recursos do Docker com Cgroups

No mês passado eu falei na ApacheCon sobre Cgroups. Parece que muito poucos usuários de Linux (incluindo este que vos fala até não muito tempo atrás) estão familiarizados com os Cgroups e seu poder. Isso é uma pena, porque os Cgroups são muito poderosos, e permitem que você aloque recursos em seus servidores de uma maneira muito mais granular do que qualquer outra ferramenta disponível no kit de ferramentas do Linux. Além disso, é integrado diretamente ao kernel e vem pronto para uso com a maioria das distribuições Linux.

Neste artigo, vou abordar como usar Cgroups com o Docker, como uma espécie de acompanhamento de outra palestra que dei no Docker Meetup em Austin, Texas.

Este artigo exige alguma compreensão básica de Cgroups. Se você é completamente novo no assunto Cgroups, recomendo que dê uma olhada no meu conjunto de slides da ApacheCon, bem como nos recursos ao final. Mas não se preocupe, não vamos nos aprofundar muito. Se você apenas passar os olhos pelos slides, deverá ser capaz de compreender os conceitos básicos.

Docker e Cgroups

O Docker vem com dois drivers diferentes: LXC e libcontainer. O driver LXC é o driver legado, e o libcontainer é o driver novo e padrão. Na maioria dos casos, o libcontainer é o driver preferido, pois é onde a inovação acontece (por exemplo, docker exec não funciona com o driver LXC).

No entanto, é importante notar que existem dois drivers diferentes, pois nem todos os recursos do Cgroup foram portados para o libcontainer ainda (ou pelo menos expostos ao Docker). Ao usar o driver LXC, você simplesmente passa os argumentos do LXC diretamente, enquanto com o libcontainer existem argumentos explícitos de política do Cgroup expostos ao Docker. Você precisará definir explicitamente um driver ao iniciar o daemon do Docker, portanto não poderá executar os dois drivers simultaneamente.

Aqui está um exemplo de como você pode verificar:

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

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

Aqui está uma visão geral de alguns dos recursos do Cgroup e como eles se mapeiam entre os dois drivers:

Recurso	Libcontainer	LXC
Compartilhamento relativo de CPU	-c, –cpu-shares	–lxc-conf=”lxc.cgroup.cpu.shares”
Bloquear em um núcleo de CPU	–cpuset-cpus	–lxc-conf=”lxc.cgroup.cpuset.cpus”
Limitar memória	-m, –memory	–lxc-conf=”lxc.cgroup.cpuset.mems”

LXC

Se você quiser usar o driver LXC para o Docker, primeiro precisará ativá-lo. O método para fazer isso varia dependendo da sua distribuição Linux, mas aqui estão as instruções sobre como ativar o driver LXC no Ubuntu 14.04.

Como mencionado acima, você está abrindo mão de vários recursos ao fazer isso. Portanto, a menos que você realmente precise de uma funcionalidade que ainda não esteja exposta no Docker usando o libcontainer, você deve realmente continuar com o driver padrão.

Algumas políticas úteis do Cgroup que ainda não foram expostas no libcontainer incluem a limitação de E/S (I/O throttling, abordada nos slides da apresentação), que pode ser muito útil para certas aplicações.

Se você decidiu usar o driver LXC, adicionar argumentos é simples. Tudo o que você precisa fazer é adicionar o argumento --lxc-conf e passar a política do Cgroup que você gostaria de definir.

Libcontainer

Como você pode ver na tabela acima, as políticas básicas do Cgroup já estão expostas na versão atual do Docker (1.6 no momento em que este artigo foi escrito).

Usar essas políticas é muito simples. Se você, por exemplo, quiser bloquear um contêiner Docker no primeiro núcleo de CPU, você adicionaria --cpuset-cpus=0 ao seu comando docker run.

Você também pode usar o argumento --cgroup-parent com o libcontainer e definir manualmente restrições de recursos mais granulares. Você então o mapearia para esse grupo usando o argumento.

Demonstração: Docker com Cgroups

No screencast abaixo, usaremos dois contêineres Docker (‘low_prio’ e ‘high_prio’). Usamos o contêiner base ‘busybox’ e executamos md5sum /dev/urandom para simular um processo faminto por CPU. Por padrão, isso consumiria todos os recursos de CPU disponíveis. No entanto, aplicaremos duas políticas de Cgroup para gerenciar os recursos. Primeiro, usamos ‘cpuset.cpus’ para travar os contêineres no mesmo núcleo de CPU (núcleo 0).

Em seguida, usamos ‘cpu.shares’ para atribuir uma cota relativa de CPU. Damos ao contêiner ‘low_prio’ o valor de 20 e ao ‘high_prio’ o valor de 80. Isso significa que 20% da CPU será alocada para o contêiner ‘low_prio’ e 80% da CPU será alocada para o contêiner ‘high_prio’. Observe, no entanto, que a cota relativa é uma escala arbitrária (poderíamos muito bem ter usado 2 e 8 como valores).

Depois de demonstrarmos que o gerenciamento de recursos realmente funciona, iniciamos o mesmo conjunto de contêineres sem nenhuma política de Cgroup para ver como eles se comportam.

Como referência, aqui estão os comandos usados para iniciar os contêineres.

[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]

Resumo

Se você estiver gerenciando vários contêineres Docker no mesmo host, usar Cgroups para gerenciar os recursos entre os contêineres faz muito sentido. Por exemplo, talvez você tenha algumas tarefas de processamento em segundo plano em execução em um contêiner e outro contêiner servindo conteúdo ao usuário. Nesse caso, você pode usar seu novo conhecimento para garantir que você priorize os contêineres voltados para o usuário antes das tarefas em segundo plano.