Upgrade Verification and Access#

Info

Typical upgrade durations, determined through controlled testing in an AWS environment for Ubuntu 22.04 LTS, manager and worker nodes (m5.2xlarge: 8 vCPU, 32GB RAM):

Node Configuration	Detail	Duration
5-node cluster	3 managers, 2 workers	10:19.87 minutes
10-node cluster	3 managers, 7 workers	11:26.64 minutes

These estimates are offered for general guidance, however, as actual upgrade durations will vary based on hardware performance (CPU/memory/disk), workload density, network throughput, and storage backend performance. For precise planning purposes, Mirantis strongly recommends that you run a test upgrade in a staging environment that mirrors your production specifications.

On completion of the mkectl upgrade command, a kubeconfig file for the default admin user is generated and stored at ~/.mke/mke.kubeconf.

Set a KUBECONFIG environment variable.
```
export KUBECONFIG=~/.mke/mke.kubeconf
```

Verify the MKE 4 cluster node readiness, cluster health, and workload status:

Verify node readiness:
```
kubectl get nodes
```
- Healthy nodes should report STATUS=Ready.
```
kubectl describe node <node-name> | grep -i conditions: -A 10
```
- Confirm the following conditions:
  - Ready=True
  - MemoryPressure/NetworkUnavailable/DiskPressure=False
Verify workload status:
```
kubectl get pods --all-namespaces
```
- Check columns for STATUS=Running and READY
```
kubectl get deployments,statefulsets --all-namespaces
```
- Confirm that AVAILABLE matches DESIRED replicas.

Review the logs:

kubectl get pods -n mke                # MKE namespace is mke
kubectl logs <pod-name> -n mke         # Check logs for mke system pods
kubectl logs <pod-name> -n <namespace> # Or any other application pods

Verify cluster health:

kubectl top nodes # Resource usage
kubectl top pods -A

If applicable, verify your Windows worker nodes.

Confirm that the Windows worker nodes are in Ready state and that they report the correct operating system:

kubectl get nodes -o wide

Windows worker nodes will show a Windows Server OS-IMAGE column.

NAME                                            STATUS   ROLES           AGE     VERSION       INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-0-139.ca-central-1.compute.internal   Ready    <none>          3h15m   v1.35.4+k0s   172.31.0.139   <none>        Windows Server 2022 Datacenter   10.0.20348.5256   containerd://1.7.31
ip-172-31-0-160.ca-central-1.compute.internal   Ready    control-plane   3h34m   v1.35.4+k0s   172.31.0.160   <none>        Ubuntu 22.04.5 LTS               6.8.0-1057-aws    containerd://1.7.31
ip-172-31-0-212.ca-central-1.compute.internal   Ready    <none>          3h34m   v1.35.4+k0s   172.31.0.212   <none>        Ubuntu 22.04.5 LTS               6.8.0-1057-aws    containerd://1.7.31
ip-172-31-0-251.ca-central-1.compute.internal   Ready    <none>          3h15m   v1.35.4+k0s   172.31.0.251   <none>        Windows Server 2022 Datacenter   10.0.20348.5256   containerd://1.7.31

If gMSA is enabled, confirm the health of the gMSA addon:
```
kubectl get pods -n windows-gmsa
```
At least one windows-gmsa Pod should be in Running state, and the windows-gmsa mutating and validating webhook configurations should be present.

Confirm that the Windows workloads are running. To do this, schedule the Windows Pods using the kubernetes.io/os: windows node selector, and then verify that the Pods are scheduled on your Windows node:
```
kubectl get pods -A -o wide --field-selector spec.nodeName=<windows-node>
```

At this point, you will no longer be able to access the source MKE 3 cluster through the previously created client bundle. You will also no longer be able to access the docker swarm cluster.