Distribuir a carga de trabalho entre os Kubernetes

Question

Eu criei uma Implantação que pode conter entre 2 e ~ 25 contêineres, todos trabalhando em uma fatia de uma única unidade lógica de trabalho maior. Os contêineres usarão um pico de 700MB a 4GB de RAM e minha abordagem inicial era solicitar 1G, limitar 4G. Na pior das hipóteses (onde há mais de 4 GB do que 700 MB), este desce um nó (ou não agendará para começar) mesmo quando 3 ou 400% livres recursos agregados estão disponíveis em outros lugares.

Observar um contêiner ou dois se aproximando lentamente da RAM e do OOM, em vez de fazer com que o planejador retire o contêiner e mude a localização parece ser uma preocupação muito óbvia com a estabilidade.

Tendo cavado literalmente anos de debates, a documentação e o próprio código. Não está claro em qual nível de abstração sob abstração o planejador espalha os contêineres na inicialização ou se há alguma ação proativa com a qual o K8S se incomoda quando o trabalho é implementado.

Se um ReplicaSet (eu acredito que seja o novo e melhorado ReplicationController) só irá reanimar os containers até matar o host, você tem que criar pedidos de pior cenário para cada pod sob sua responsabilidade. Para o maior número de tarefas que executamos como Implantação, isso introduz um 50% + desperdício de RAM perdido para superprovisionamento 'apenas no caso' .

Isn't keeping around over-provisioned resources one of problems we're trying to solve here?

Eu usei alguns agendadores / gerenciadores de recursos ao longo dos anos e não lembro de um caso em que um jobstep - container - seja qual for a analogia seria permitido comprometer o host em vez de ser forçado a migrar ou apenas imediatamente marcado inelegível para agendamento ..

Embora os documentos admoestem a ideia, pods nus ou 1 pod: 1 ReplicaSet parecem ser a única maneira de manter o trabalho distribuído (assumindo o controle de contêineres e cometendo suicídio com frequência suficiente para que o quadro geral de recursos seja reconsiderado).

Também devo mencionar que este é o mecanismo do Google Container Engine (v1.2.2) hospedado e receber o que parecia ser várias páginas de sinalizadores com os quais é possível iniciar o K8S, não está claro se esse é um problema inerente > erro do usuário ou apenas como o GCE configurou o K8S. Eu realmente estou esperando por erro do usuário em um presente.

    

Answer 1

Para responder a minha própria pergunta com base em algumas pessoas bastante úteis no canal slack do Kubernetes.

- Minha experiência de falha de um nó devido à OOM'ing do contêiner é provavelmente devida a um efeito secundário, pois o gerenciador de recursos foi projetado para evitar isso. O culpado sugerido foi, na verdade, o subsistema de E / S tornar-se sobrecarregado ao ponto de desestabilizar o nó, o que, após algumas medições, parece muito provável.

In GKE, the OS, Docker, K8S, and any temporary directories the pods request are all on one non-local 100GB (by default, I believe) ext4 filesystem.

A maioria dos pods que criamos estava pedindo e escrevendo para diretórios temporários e o I / O coletivo sobrecarrega o sistema a ponto de não responder e, no nosso caso, travar o próprio sistema operacional .

- Um teste inicial, configurando meu próprio K8S com o SO em seu próprio disco ext4, docker e espaço efêmero em seus próprios pools do ZFS e os mesmos manifestos de implantação fazem stress, mas não chega perto de travar o sistema operacional.

- Uma solução alternativa proposta mas ainda não testada é usar Jobs e gerenciar as dependências entre eles com algum processo de coordenação, presumivelmente porque isso espalharia os contêineres individuais pelo cluster. Isso pode funcionar, mas me parece um problema subjacente.

Embora eu ainda não tenha medido a atribuição de discos permanentes para o espaço de rascunho que estávamos usando emptyDir para, presumo que isso também diminuiria a carga no disco primário e poderia ser suficiente para mascarar o problema.

Infelizmente, a configuração padrão do GKE assume que o sda será capaz de lidar com toda a carga do sistema operacional, logs do K8S, Docker e scratch space que aparentemente devem funcionar para a maioria das pessoas, pois não encontrei outro problema como o nosso.

Vindo do bare metal, eu esperava evitar alguns detalhes de baixo nível em ter o cluster gerenciado, mas tanto o dataproc quanto o GKE, até agora pelo menos me inclinei a construir os clusters.

Espero que isso ajude alguém cuja carga de trabalho seja adequada ao padrão de trabalho ou que use principalmente discos provisionados.

Surpreende-me que qualquer prática recomendada tenha esperado muito da unidade de inicialização e sinalize isso com o suporte, pois mesmo o mecanismo de computação "regular" parece desencorajar isso, considerando os tamanhos de unidade de inicialização padrão.