Como você define requests e limits de CPU e memória para uma carga de trabalho?

Defina os requests a partir do uso observado, normalmente perto da mediana para CPU e perto do pico para memória, porque os requests guiam o scheduling e a capacidade. Coloque o limit de memória perto do request, já que ultrapassá-lo faz o container ser morto, e seja cauteloso com limits de CPU porque eles causam throttling que aparece como latência inexplicada. Revise os números com dados reais em vez de copiá-los entre serviços.

Requests são o que o scheduler usa para posicionar o pod e o que você efetivamente paga, e limits são o teto que o runtime impõe. Os dois recursos se comportam de forma completamente diferente. CPU é compressível, então bater no limit de CPU significa que o container é throttled, e isso aparece como picos de latência sem causa óbvia, o que é horrível de depurar. Memória não é compressível, então ultrapassar o limit de memória significa que o container é morto na hora. Isso leva aos meus padrões: definir o request de CPU pelo uso mediano observado com alguma folga, e eu normalmente sou cauteloso com limits de CPU em serviços sensíveis a latência, ou eu os defino com generosidade. Para memória eu coloco o request perto do pico realista e o limit perto dele, para um vazamento falhar rápido e de forma visível em vez de comer o nó em silêncio. Eu tiro os números de umas duas semanas de percentis de uso real, não de copiar de outro serviço, e reviso depois de testes de carga. O outro lado é que requests inflados são o principal motivo de clusters parecerem vazios e ainda assim não conseguirem agendar nada.