VMs in all clouds are always tied to specific machines. If that machine fails unexpectedly then those VMs will restart. If it is a controlled reboot (e.g. host update) then they may not restart...
What image were you running? Our internal monitoring indicates that it is generally significantly faster than that, but image pull is almost always the long pole for container startup time.
Each container has hypervisor level isolation. We are not relying on kernel level isolation for security isolation between different user's containers.
Disclosure: lead eng for azure containers and kubernetes founder here...
a) For the longest time, I've wanted a "TTL" extension for Kubernetes objects, maybe this is a good excuse to build it. But concretely, since you are paying for the VMs in the cluster (IaaS) the Pods you deploy are "free" (until you run out of cluster capacity, of course)
b) The right way to do this is Kubernetes namespaces. You can specify a different Namespace in each user's draft config file that will place each developer's containers in a different namespace.
Now that I write that, though, that seems like too much work. We should probably automagically build a unique namespace for you...
They're by no means perfect, but we try to be super open about our development process.
Many of the github issues also have comprehensive discussions of topics, searching the repo for topics you're interested in will often surface interesting discussions.
If you want to get more deeply involved, I'd suggest the Kubernetes community meeting (Thurs, 10am Pacific)
Software Engineer (Cloud) | Microsoft (Azure) | Seattle, WA
Come work on Azure Resource Manager, the core API gateway and template engine for all of Azure. We're a large-scale, distributed, highly reliable service that enables deployment across all resources in the Azure stack. Development in C# with an agile (scrum + backlog) methodology. Position is onsite in Redmond, WA.
For more information, email bburns [at] microsoft [dot] com