fix: fix spurious logging for non-CSI volumes

[jmdeal]

Fixes #1069

Description
Today, if we fail to resolve a CSI driver from a bound PV, we attempt to resolve it from the storage class on the PVC. This can lead to spurious error logs when the volume is not managed by a CSI driver or supported in-tree equivalent (currently only EBS). What we should do is bail early if the PVC is bound and no volume could be discovered.

Some notes on logging:

• The bound PVC + no driver case isn't logged to avoid repetitive logging for a non-issue, I'd consider logging it if we had a trace log level but it feels too verbose even for debug.
• Logs that were previously errors have been reduced to debug messages. Neither of the cases are fatal errors that disrupt Karpenter's ability to schedule but they should still be surfaced because they could indicate to the customer they have a misconfiguration.
  • The case where the PVC doesn't exist is still kept as an error since it shouldn't be a valid state (i.e. would have needed to be removed with the finalizer patched off). I'm not certain what this one should be though, definitely would like some other opinions here.
• The log messages have been adjusted to ensure that it is clear Karpenter is not updating values on in-cluster resources, rather it is updating it's own cluster state.

How was this change tested?
make test / manual

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[coveralls]

Pull Request Test Coverage Report for Build 8179376213

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 1 of 4 (25.0%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.06%) to 81.07%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/scheduling/volumeusage.go	1	4	25.0%

Files with Coverage Reduction	New Missed Lines	%
pkg/scheduling/volumeusage.go	2	73.6%

Totals
Change from base Build 8175773696:	0.06%
Covered Lines:	8171
Relevant Lines:	10079

---

💛 - Coveralls

[jonathan-innis]

The bound PVC + no driver case isn't logged to avoid repetitive logging for a non-issue

I also think that the bound PVC + no driver case isn't really an issue. There are real use-cases for not using CSI and using something like local storage to provision your volumes for your pods.

[jonathan-innis]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jmdeal, jonathan-innis

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jonathan-innis]

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

[jmdeal]

there are real use-cases for not using CSI and using something like local storage to provision your volumes for your pods.

Agreed, that's what I meant by a non-issue. I'd consider logging it if we had a trace because it could potentially mean something is corrupted but there are too many valid use-cases to justify logging in debug.