This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(60.8, 51%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3END%3C/text%3E%3C/svg%3E)
Context: [Regarding cost reduction for compute]. In AKS cluster, recently observed that compute resources are under-utilised and so my plan is:
To create a new node pool(with lower cpu and memory, and so lower cost basically) and attach to the same AKS cluster. And then
cordon the old node pool and then drain it, so the workload will move to new node pool (Thanks to nodeSelector)
Question:
What about the k8s resources like statefulset for eg. Redis etc which are in old node pool and are having PV and PVC . Do we have to take backup of those pvc and restore etc for new node pool? (As per my thinking, kubernetes will take care of detaching and attaching pvc considering all this activity will be within single kubernetes cluster only)
Hello @Ninad Desai ,
You are right! Kubernetes will take care of detaching and attaching PV and PVC considering all this activity will be within single Kubernetes cluster only. You don’t need to backup.
(If the response was helpful please don't forget to upvote and/or accept as answer, thank you)
@Prrudram-MSFT I had a pod deployed as a stateful set which uses a pv and pvc in my nodepoolA and with the help of affinity and toleration I changed the stateful set deployment to be in nodepoolB. Unfortunately the kubernetes scheduler failed to schedule my pod in nodepoolB and was in Pending state with reason 0/3 nodes are available: 1 node(s) had volume node affinity conflict, 2 node(s) didn't match Pod's node affinity/selector. The error "volume node affinity conflict" happens when the persistent volume claims that the pod is using, are scheduled on different zones, rather than on one zone, and so the actual pod was not able to be scheduled because it cannot connect to the volume from another zone.
So I believe Kubernetes does not have the capability of doing it. Please let me know how to tackle this issue.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(83.2, 35%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ%3C/text%3E%3C/svg%3E)
Hey @Krishnanunni M-FT
I got the same issue. Did you solve it?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(0, 8%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAB%3C/text%3E%3C/svg%3E)
Hi @Krishnanunni M-FT , we are facing the same issue, is there a way to over come the volume node affinity conflict without having data loss?