@ed123456: SF Mesh in azure , being a multitenant offering , the services are not allowed direct access to the Nodes and also in general cannot query the system services directly. So if your services were making any such calls, then containerizing them and pushing them into Mesh would most likely break them.
To provide the capability to move your existing SF apps to SF Mesh is something we plan to support in the future, closer to GA timeframe. This is an important capability for us and is in the near term backlog.
All mesh applications can be deployed to a SF cluster. The main challenge for anyone moving a mesh application running in Mesh to a SF cluster, would be to move the state, it will have to be backed up and restored to the cluster.. If the state is external, then movement would be trivial. The resource model is understood by both mesh and SF cluster. So porting the applications back and forth would not be an issue.
@csinger: The CPU and Mem indicate to the system the size of the container that the code package needs to run. SF mesh allows you partial cores, so if need only .5 Cores and .5 GB of memory, then you request only for that. The customer gets charged for what they request. After deploying, if you observe that your service needs more cores or memory you can scale up or down, by adjusting that the values or if you need more service (container) instances your scale out or in by adjusting the replica count for that service. What you do not need to worry about is the provisioning the azure capacity to scale up or out, system does that for you.
Later in the year, you can also specify custom autoscale rules for your services, so that you can scale in or out as the load decreases or increases upto a limit that you set.