etcd needs at least three nodes
This is true of any distributed system that has a leader/master to maintain consistency if you require it to be fault tolerant. In fact, you need an odd number of nodes to ensure that if the cluster cannot get evenly split in two (due to network outage for example) as when this happens neither side can elect a leader and the whole cluster will become unavailable. Three happens to be the minimum number that is able to tolerate a single node going down without affecting the uptime of the cluster.
If you do not require a highly available system you can get away with a single node but non highly available solutions are not recommended for production use for obvious reasons - you are always free to ignore this advice if your system is smaller enough and you understand the risks of the system falling over or cannot justify the expense of the extra nodes.
etcd should not be installed on controller nodes but on separate VMs
This is also a stability/scalability issue - you are free to mix controller nodes with compute nodes in most distributed systems but they can struggle in this setup when under high load. If you don't have enough nodes to create a three node cluster then you don't have enough nodes to stress the systems to a point where this will matter.
Both of these issues can be addressed when your system grows to a point where the nodes start to struggle or you can warrant the cost of setting up the extra nodes.
You could start off with one node for a MVP but both kubernetes and etcds guides are geared towards a distributed setup and you only really benefit from them being setup in a cluster. You may also encounter issues trying to grow it from one node to three nodes. If you can afford a three node setup then I would start off with that and just have all the nodes start with all of the services splitting them out when you want to grow the setup further.