rolling-update: log reason for InstanceGroup needing update

[shreyaabaranwal]

Fixes #14122

When kops rolling-update cluster runs, InstanceGroups can end up in
NeedsUpdate state for several different reasons (launch
template/config drift, detached instances, the
kops.k8s.io/needs-update annotation, provider-specific tags/labels,
etc.), but there was no user-facing indication of why a particular
InstanceGroup or instance needed an update.

As suggested by @olemarkus in the issue, this adds a fmt.Printf()
line at each point where an instance is marked NeedsUpdate,
stating the specific reason. Existing klog calls are left
untouched where they're already at the right verbosity (e.g. the
klog.V(4) launch-template-version logs in aws_cloud.go) — this
is purely additive, no logic changes.

This is inspired by #16079 (@guerzon, 2023), which took the same
approach but never got a maintainer review and was closed by the
stale-bot after 90 days of inactivity — not a technical rejection.

Providers covered:

• AWS (launch config/template drift, detached instances)
• GCP (instance template drift)
• Hetzner (needs-update label)
• OpenStack (generation mismatch / error state)
• Scaleway (needs-update tag)
• Spotinst (instance created before last group update) - new coverage, missing from the original PR

Karpenter-managed instance groups are intentionally not touched:
that code path (buildKarpenterGroup) no longer has a NeedsUpdate
branch - Karpenter nodes are tracked via the generic
kops.k8s.io/needs-update annotation path instead.

[kubernetes-prow]

Hi @shreyaabaranwal. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign rifelpet for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[guerzon]

Thanks for the shoutout @shreyaabaranwal. I wish you have better luck in getting someone notice your PR :)

[shreyaabaranwal]

Thanks @guerzon! Your PR was a great reference- the approach you took was spot on, it just needed a bit more visibility. Hopefully this one gets there with the extra provider coverage. Appreciate you stopping by 🙂