4 ms·
It's always been my understanding that with things like k8s and other orchestration stuff, you're supposed to spin up before you need the capacity? You set a th
by ehutch79 4y ago
It's always been my understanding that with things like k8s and other orchestration stuff, you're supposed to spin up before you need the capacity? You set a threshold, like 75% capacity, and if you're over that for a bit, you spin up a new container(s) to get you back to under effectively 75% capacity.
Is that not how this works?
- paulgb 4y agoYes, that's the scaling model that works best for Kubernetes if the use case supports it. Our use case precludes it, because we are focused on uses where containers need to be spun up on a per-user (or per-group-of-users) basis as they use an application.
- swid 4y agoPrecludes feels like the word word here. Nothing prevents you from satisfying your use case and spinning up vms before they are needed. I wrote the student vm system for udacity, and I spun up student vms before they needed them, with some last mile loading to finalize the files they need. The student VMs were not using k8s, although a small piece of the infrastructure did. I worried most about untrusted users working in a complex environment with the ability to harm the experience of other users, and just used GCE. For me, boot time was < 5 minutes, so if you can predict the next five minutes of demand, you can boot those machines early. If you are wrong you will pay extra or someone will wait extra time, but still less than the full boot time. Generally it takes less than 10 seconds to access a vm with your coursework on in.
- blincoln 4y agoCan you not have a queue of whatever type of containers the users are likely to be using already ready to go, like the GP suggests?
- acoard 4y agoKeep a pool of eg 5 pods that are warm and good to go. When a user needs one, the pod pulls in necessary config data which should be quick as it's already initialized.