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.