A team of data scientists infrequently needs to use a Google Kubernetes Engine (GKE) cluster that you manage. They require GPUs for some long-running, non- restartable jobs. You want to minimize cost. What should you do?
A.
Enable node auto-provisioning on the GKE cluster.
B.
Create a VerticalPodAutscaler for those workloads.
C.
Create a node pool with preemptible VMs and GPUs attached to those VMs.
D.
Create a node pool of instances with GPUs, and enable autoscaling on this node pool with a minimum size of 1.
Incorrect options are
B. VerticalPodAutscaler scales PODS based on the app you deploy.
For handle infrequently GPU access, you need infrequently GPU nodes
VerticalAutscaler Pod deployed on a non GPU node it useless,
[We cant have the node always have GPU for infrequent requests]
C. Preemptible VMs cant last long
D. For infrequent access, you don't want to have a permanent homogenous cluster.
The correct option is "A"
auto-provisioning = Attaches and deletes node pools to cluster based on the requirements.
Hence creating a GPU node pool, and auto-scaling would be better
https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning
A is not correct because you can't add a GPU node to an existing GKE cluster
Limitations
Before using GPUs on GKE, keep in mind the following limitations:
You cannot add GPUs to existing node pools.
GPU nodes cannot be live migrated during maintenance events.
GPUs are only supported with general-purpose N1 machine types.
GPUs are not supported in Windows Server node pools
REF: https://cloud.google.com/kubernetes-engine/docs/how-to/gpus#limitations
So the answer should be D
Your reference says existing "node pools" not GKE cluster. Auto-provisioning creates new "node pools": https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning
https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning
Node auto-provisioning creates node pools based on the following information:
CPU, memory and ephemeral storage resource requests.
GPU requests
Pending Pods' node affinities and label selectors.
Pending Pods' node taints and tolerations.
I do agree A is the answer. Since this is for infrequent needs, autoscaling in letter D is not cost effective as it will always run min. of 1 instance. If we need to infrequently use a cluster, the nodes should be able to adjust based on the current need.
"With node auto-provisioning, new node pools are created and deleted automatically." https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning
If the answer was "Create auto-provisioning node pool" or demand is not about GPU resources I'll agree with A too, but there is a limitation about existing node pools and GPU, so enabling of auto-provisioning will not create GPU nodes. Need to create separate GPU pool then enable auto-provisioning for it.
I think using NAP is the correct answer.
→Node Auto Provisioning (NAP a.k.a., Nodepool Auto Provisioning)
There is an introduction of NAP described below on the blog.
>The above recommendations optimize for cost. NAP, for instance, reduces costs by taking down nodes during underutilized periods.
https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-creating-a-highly-available-gke-cluster
they "require GPUs" - so after checking in Udemy practice tests there is similar question there. And the D answer seems to be the best fit for our scenario here.
"This option is the most optimal solution for the requirement. Rather than recreating all nodes, you create a new node pool with GPU enabled. You then modify the pod specification to target particular GPU types by adding node selector to your workload's Pod specification. You still have a single cluster, so you pay Kubernetes cluster management fee for just one cluster, thus minimizing the cost." Still better option than creating new GKE cluster with GPUs.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/gpus
Ref: https://cloud.google.com/kubernetes-engine/pricing
It's A. Shit gets only auto-provisioned when your devs actually deploy something that requires a GPU. It doesn't run permanently by default thus saves costs since it only gets provisioned when neededn.
You are not able to add GPUs to existing node pools. This significantly impacts the viability of option A.
My reasoning for D: A dedicated GPU node pool allows configuring those nodes with specific instance types, disk sizes, etc., ensuring the best fit for the long-running jobs. While it incurs some cost even with a minimum size of 1, it might still be more cost-efficient than full auto-provisioning if the jobs are infrequent but require a predictable baseline capacity. Separating GPU and non-GPU workloads can improve resource scheduling and prevent potential conflicts.
In my opinion, more sense has A, but then i read again and again the answer - "Enable node auto-provisioning" with GPU will not works due to limitation "You cannot add GPUs to existing node pools". If "A" was like "Create GPU node pool with enabled auto-provisioning" this will be correct answer, in in our case should be D
The most cost-effective option for your scenario would be **C. Create a node pool with preemptible VMs and GPUs attached to those VMs**.
Preemptible VMs are Google Cloud's excess compute capacity. They are up to 80% cheaper than regular instances, making them a cost-effective choice for fault-tolerant workloads that do not require continuous availability³.
However, please note that preemptible VMs are subject to availability and can be preempted if Google Cloud requires access to those resources, but they will be a good choice if the jobs can tolerate occasional preemptions³.
While options A, B, and D could also be used in certain scenarios, they may not provide the same level of cost-effectiveness for long-running, non-restartable jobs that require GPUs⁵. Always consider the nature of your workloads and their tolerance for interruptions when choosing the right solution.
It is A
Node auto-provisioning creates node pools based on the following information:
CPU, memory, and ephemeral storage resource requests.
GPU requests.
Pending Pods' node affinities and label selectors.
Pending Pods' node taints and tolerations.
https://cloud.google.com/kubernetes-engine/docs/concepts/node-auto-provisioning
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Polok
Highly Voted 4 years, 5 months ago[Removed]
Highly Voted 3 years, 7 months agokimharsh
3 years agorachee
2 years, 11 months agoRidhanya
2 years, 11 months agowjtb
2 years, 5 months agodttncl
3 years, 1 month agongeorgiev2
9 months, 1 week agokyo
3 years, 4 months agoJCH760310
2 years, 11 months agoRKS_2021
Most Recent 2 months agoRKS_2021
2 months agoTimfdklfajlksdjlakf
2 months, 4 weeks agoTimfdklfajlksdjlakf
3 months agoccpmad
6 months agoSheqos
8 months, 1 week agoPiperMe
8 months, 3 weeks agongeorgiev2
9 months, 1 week agoJB28
10 months, 2 weeks agokaby1987
10 months, 4 weeks agoyash_1199
11 months agoogerber
11 months, 3 weeks agokelliot
12 months agovipinnn00980
12 months agosinceronny
11 months agothewalker
1 year ago