Eu criei uma implantação que pode conter entre 2 e aproximadamente 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-4GB de RAM e minha abordagem inicial foi solicitar 1G, limitar 4G. No pior cenário (onde há mais 4 GB do que 700 MB), isso desativa um nó (ou não agenda para começar) mesmo quando 3 ou 400% de recursos agregados gratuitos estão disponíveis em outro lugar.
Observar um ou dois contêineres subindo lentamente na RAM e OOM no nó, em vez de fazer o agendador retirar o contêiner e realocá-lo, parece uma preocupação bastante evidente com a estabilidade.
Tendo cavado literalmente anos de debates sobre git, a documentação e o próprio código. Não está claro em qual nível de abstração após abstração o agendador espalha contêineres no lançamento ou se há alguma etapa proativa com a qual o K8S se incomoda depois que o trabalho é implantado.
Se um ReplicaSet (acredito que seja o novo e aprimorado ReplicationController) apenas reanimará os contêineres até matar o host, você terá que criar solicitações de cenários difíceis de pior caso para cada pod sob sua alçada. Para o maior dos trabalhos que executamos como uma implantação, isso introduz um desperdício de RAM de 50% ou mais devido ao superprovisionamento "por via das dúvidas" .
Manter recursos superprovisionados não é um dos problemas que estamos tentando resolver aqui?
Eu usei alguns agendadores/gerenciadores de recursos ao longo dos anos e não me lembro de um caso em que uma etapa de trabalho - contêiner - qualquer que seja a analogia seria permitida para comprometer o próprio host em vez de ser migrado à força ou simplesmente marcado inelegível para agendamento..
Mesmo que os documentos aconselhem a ideia, pods nus ou 1 pod:1 ReplicaSet parecem ser a única maneira de manter o trabalho distribuído (assumindo o ponto de verificação de contêineres e cometendo suicídio com frequência suficiente para que a imagem geral do recurso seja reconsiderada).
Também devo mencionar que este é o Google Container Engine hospedado (v1.2.2) e, considerando o que parecia ser várias páginas de sinalizadores com as 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 K8S. Estou realmente esperando por um erro do usuário neste.
Para responder à minha própria pergunta com base em algumas pessoas bastante úteis no canal slack do Kubernetes.
-- Minha experiência de um nó falhando devido ao OOM'ing do contêiner provavelmente se deve 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 ficando sobrecarregado a ponto de desestabilizar o nó que, após algumas medições, parece muito provável.
A maioria dos pods que criamos estava solicitando e gravando em diretórios temporários e a E/S coletiva sobrecarrega o sistema a ponto de deixar de responder e, em nosso caso, travar o próprio sistema operacional.
-- Um teste inicial, configurando meu próprio K8S com o sistema operacional em sua própria unidade ext4, docker e espaço efêmero em seus próprios pools ZFS e os mesmos manifestos de implantação causam estresse, mas não chegam perto de travar o sistema operacional.
-- Uma solução alternativa que foi 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 encobrir um problema subjacente.
Embora eu ainda não tenha medido a atribuição de discos permanentes para o espaço temporário para o qual estávamos usando emptyDir, presumo que isso também diminuiria a carga no disco primário e pode ser suficiente para mascarar o problema.
Infelizmente, a configuração padrão do GKE pressupõe que o sda será capaz de lidar com toda a carga do sistema operacional, logs do K8S, Docker e espaço temporário, o que aparentemente deve funcionar para a maioria das pessoas, pois não consegui encontrar outro problema como o nosso.
Vindo do bare metal, eu esperava evitar alguns detalhes de baixo nível ao gerenciar o cluster, mas tanto o dataproc quanto o GKE, pelo menos até agora, me inclinaram fortemente para a criação dos clusters por conta própria.
Espero que isso ajude alguém cuja carga de trabalho seja compatível com o padrão de trabalho ou que use principalmente discos provisionados.
Estou surpreso que qualquer prática recomendada tenha esperado tanto da unidade de inicialização e sinalizará isso com suporte, pois até mesmo o mecanismo de computação 'regular' parece desencorajar isso, dados os tamanhos padrão da unidade de inicialização.