OpenAI: Kubernetes com 7.500 nós

01 · CONTEXTO E CARGA

Um cluster enorme para uma carga incomum

Em um post público, a OpenAI descreveu clusters de Kubernetes com 7.500 nós. Ela mesma diz que escalar um único cluster a esse tamanho raramente é feito e exige cuidado especial.

A carga explica as escolhas. Em muitos jobs, um único pod ocupa o nó inteiro; por isso há muitos nós, mas pouca pressão sobre o escalonador. Essa pressão, porém, vem em picos: um job novo pode criar centenas de pods de uma vez e depois a rotatividade volta a ser baixa.

Se um pod participante de um job morre, o job inteiro para e precisa ser reiniciado, e ele retoma do último checkpoint. Os pods falam direto pelo IP, com MPI via SSH, e não por service endpoints.

02 · API SERVER E ETCD

O plano de controle como componente crítico

A OpenAI trata os API servers e o etcd como componentes críticos para um cluster saudável. Os API servers rodam fora do cluster, e tanto eles quanto o etcd ficam em nós dedicados.

1. No diagrama, os pesquisadores falam com os API servers, que são o ponto central do plano de controle.

2. Os eventos do Kubernetes ficam em um cluster etcd separado do principal; depois dessa separação, a equipe diz não ter tido problemas notáveis com o etcd.

3. Nos maiores clusters há 5 API servers e 5 nós de etcd, para repartir a carga e limitar o impacto se um deles cair.

4. A taxa de respostas 429 e 5xx dos API servers é um sinal de alto nível de problemas, e a equipe alerta sobre ela.

5. A memória de cada API server tende a crescer linearmente com o número de nós; no cluster de 7.500 nós, chega a até 70GB de heap por API server.

6. Os API servers são stateless e fáceis de rodar em grupo auto-recuperável; para o etcd não há automação de auto-recuperação, porque os incidentes foram raros.

Separar o estado (etcd) da camada sem estado (API server) permite tratar cada parte de um jeito: réplicas descartáveis na frente e um armazenamento que merece cuidado maior atrás. É o mesmo raciocínio de escalar na horizontal o que é stateless e proteger com mais rigor o que guarda estado replicado por consenso.

03 · CARGA QUE CRESCE COM O CLUSTER

WATCHes, DaemonSets e o API server

Uma das maiores fontes de carga no API server foi o WATCH em Endpoints. Todo nó do cluster é membro de serviços como kubelet e node-exporter, e quando um nó entra ou sai o WATCH dispara.

1. Todo nó é membro desses serviços; quando um nó entra ou sai, o WATCH dispara no API server.

2. O WATCH em Endpoints foi uma das grandes fontes de carga do API server.

3. Os EndpointSlices reduziram essa carga em 1000x.

4. A equipe evita que DaemonSets interajam com o API server.

5. Quando cada nó precisa acompanhar mudanças, um serviço de cache intermediário parece um bom padrão para evitar gargalos no cluster inteiro.

04 · GANG SCHEDULING

Tudo ou nada no agendamento

Em experimentos com StatefulSets, para os otimizadores todos os membros precisam estar agendados antes de qualquer treino, e o MPI é sensível a mudanças na composição do grupo.

Se dois experimentos pedem toda a capacidade, em vez de agendar um deles por inteiro o Kubernetes pode agendar só metade dos pods de cada um, e nenhum dos dois progride.

1. Dois experimentos pedem, cada um, toda a capacidade do cluster ao escalonador.

2. O Kubernetes pode agendar só metade dos pods de cada experimento.

3. O resultado é um impasse: nenhum dos dois experimentos consegue progredir.

4. A solução adotada foi o plugin Coscheduling no escalonador.

A equipe tentou soluções com escalonador customizado. O Kubernetes 1.18 trouxe uma arquitetura de plugins no escalonador central, o que facilitou adicionar esse tipo de recurso de forma nativa.

05 · ISOLAMENTO E LIÇÕES

Clusters isolados e o que se repete

Na rede, os pesquisadores se conectam a um hub e a partir dele acessam cada cluster, os spokes. Os clusters não conversam entre si, o que mantém o isolamento de falhas.