Key Parameters Evaluated During a Cluster Upgrade
PreviousDisabling MetalLB Addon in "InstallAddonError" Status Fails to Delete Resources on the ClusterNextETCD Backup Error in the Management Plane UI
Last updated
It is expected that the master nodes should upgrade one by one.
When the master node upgrade is triggered, the process should complete the upgrade of one master node and ensure it is in a Ready state before moving on to the next node.
However, in some cases, this sequential upgrade logic breaks and all master nodes report NotReady status due to ongoing upgrade on them.
Platform9 Managed Kubernetes - v5.9 and Higher
As per the current cluster upgrade workflow, the following parameters are considered for a node upgrade to proceed:
qbert checks if the sunpike hostState is set to ok. This data is stored on the node at the location /var/opt/pf9/kube_status, where a field calledpf9_kube_node_stateindicates the status. If pf9_kube_node_state is set to ok, qbert considers the host as converged.
Checks if the API server on the master node is responsive.
An RFE with the ID PMK-6607 is already in place to update the cluster upgrade workflow to respect node status [Ready/NotReady] before proceeding with upgrade.
The RFE is targeted for future releases.
Last updated
