When we try to upgrade by default AKS will to upgrade nodes by increasing the existing node capacity. So one extra node will be spinup with kubernetes version you are planning to upgrade. Then using rolling strategy it will try to upgrade the nodes one by one. It will move all the pods to new extra node and deletes the old node. This cycle continues until all nodes are updated with latest version. If we have replicaset or deployment then there should be no downtime ideally. We can also use the concept of podAntiAffinity so that no 2 pods will be in same node, and there will be no downtime

If you are using higher level controllers such as deployment and running multiple replicas of the pod then you are not going to have a downtime in your application because kubernetes will guarantee that replicas of pod get distributed between different kubernetes nodes and when a particular node is cordoned/drained for upgrade or maintenance you still have other replica of the pod running in other nodes.

If you use pod directly then you are going to have downtime in your application while upgrade is happening.

Reading documetation we can find:

During the upgrade process, AKS adds a new node to the cluster that runs the specified Kubernetes version, then carefully cordon and drains one of the old nodes to minimize disruption to running applications. When the new node is confirmed as running application pods, the old node is deleted.

They will not be rebooted, only replaced with new ones.