sobre o ambiente, todos rodam o ambiente de desenvolvimento com kubernetes? e porquê?
o ideal seria utilizar um dockerfile para desenvolvimento + docker-compose para orquestrar caso seja necessário subir mais de um container e os apontamentos dos volumes serem feitos de forma relativa e não absoluta isso garante compatibilidade independente do S.O.
a Questão da redflag por optar por um S.O acredito que isso não diz muita coisa, no fim cada desenvolvedor tem que que utilizar as ferramentas que vão lhe propor maior produtividade e maior compatibilidade com a stack e as ferramentas da empresa, e se ele preferir usar windows e nao comprometer os critérios mencionados anteriormente que o faça.
O porquê do Kubernetes em ambiente de desenvolvimento ao invés do Docker?
Porque que se eu tenho uma aplicação que roda em Kubernetes, com certeza ela vai rodar no Docker, já no caso inverso não se aplica automaticamente.
No Docker você pode, por exemplo, usar dependencias de serviços - no Kubernetes você precisa de um teste de Readiness e Liveness, geralmente um endpoint /healthcheck. É simples de resolver? Sim, mas precisa ser feito e testado, constantemente.
Se voce precisar testar um ambiente com N replicas pra certificar que um serviço está tolerante a falhas, também não consegue. Então tchau teste de resilência e up/downscaling, 100% da responsabilidade fica na mao do DevOps e SRE que vão receber deploys quebrados. Como você saberia se aplicação escala? Docker-compose nao possui HPA, então não saberia, só quando quebrasse no pipeline. Por experiência nos ultimos projetos, quanto mais distante é a realidade do ambiente de produção ao que os devs trabalham = mais bugs.
Ainda na esfera dos testes, os devs não conseguiriam testar de maneira facil atualização com 0 downtime.
O Kubernetes só coloca em produção um novo POD que passar pelo teste de Liveness e Readiness, caso contrario o POD antigo continua operacional. E isso eleva o nível do time para construir processos de migrations/deploys melhores, porque a nova versão só entra em produção depois que o serviço está plenamente operacional.
Pra uma aplicação que não seja de missão crítica até concordo com o uso do docker-compose, no nosso caso não é uma opção, aonde um minuto de downtime é um prejuizo na escala de milhares reais ou talvez dezenas de milhares.