etcd needs at least three nodes
Isso vale para qualquer sistema distribuído que tenha um líder / mestre para manter a consistência se você precisar que ele seja tolerante a falhas. Na verdade, você precisa de um número ímpar de nós para garantir que, se o cluster não puder ser dividido uniformemente em dois (devido à interrupção da rede, por exemplo), quando isso acontecer, nenhum dos lados poderá eleger um líder e todo o cluster ficará indisponível. Três é o número mínimo que é capaz de tolerar um único nó descendo sem afetar o tempo de atividade do cluster.
Se você não precisa de um sistema altamente disponível, pode usar um único nó, mas soluções não altamente disponíveis não são recomendadas para uso em produção por razões óbvias - você está sempre livre para ignorar este conselho se o sistema for menor o suficiente e você entende os riscos do sistema cair ou não pode justificar a despesa dos nós extras.
etcd should not be installed on controller nodes but on separate VMs
Este também é um problema de estabilidade / escalabilidade - você é livre para misturar nós controladores com nós de computação na maioria dos sistemas distribuídos, mas eles podem ter dificuldades nessa configuração quando estiverem sob alta carga. Se você não tiver nós suficientes para criar um cluster de três nós, não terá nós suficientes para enfatizar os sistemas a um ponto em que isso seja importante.
Esses dois problemas podem ser resolvidos quando o sistema cresce até o ponto em que os nós começam a se debater ou você pode garantir o custo de configurar os nós extras.
Você poderia começar com um nó para um MVP, mas os guias do kubernetes e do etcds são voltados para uma configuração distribuída e você só se beneficia da configuração deles em um cluster. Você também pode encontrar problemas tentando crescer de um nó para três nós. Se você puder pagar por uma configuração de três nós, eu começaria com isso e teria todos os nós iniciados com todos os serviços, dividindo-os quando você quiser aumentar ainda mais a configuração.