Change Worker Group Flavor Configuration
The MFKE service does not support directly updating the flavor configuration of workers in an existing Worker Group. Instead, you need to create a new Worker Group with the desired flavor configuration. This is covered in item 9 of the MFKE service FAQs.
How to change the flavor of a Worker Group in MFKE
Step 1: Create a new Worker Group
- Create a new Worker Group with the flavor configuration you want.
- Ensure the nodes in the new pool are stable and have joined the cluster.
Step 2: After creating the new Worker Group, migrate applications from the old Worker Group to the new one
You can migrate applications using one of the following approaches:
Case 1: Application is deployed using nodeSelector
- Assign the same label from the old Worker Group to the new Worker Group.
- Delete the old Worker Group from the cluster. The application pods will be recreated on the new Worker Group. Once the new application pods are created successfully, the application pods on the old Worker Group will be deleted. When all applications on the old Worker Group are fully evicted, the workers in the old pool will be drained and removed from the cluster.
Case 2: Application does not use nodeSelector
- Run the cordon command to prevent nodes in the old Worker Group from accepting new pods.
- Perform a rollout restart to restart the application pods so new ones are created on the new Worker Group, and old pods on the old workers are terminated.
- After the application pods have fully migrated to the new Worker Group, delete the old Worker Group from the portal.
Note: The cluster drain and deletion of the old Worker Group process may not complete automatically in some cases, such as:
- The application uses Pod Disruption Budget (PDB), which limits the number of pods that can be deleted at once.
- The application uses block Persistent Volume Claims (PVC).
- In these cases, you need to manually check and evict any remaining pods to ensure all applications have migrated to the new Worker Group.
ヒント
Recommendations:
- Perform this change during off-peak hours to minimize impact on real users.
- Monitor pod and application status after migration to ensure everything is stable.