Port forward ignores errOut for some errors

[manterfield]

This is a potentially a user error, but it's not obvious to me what I could have done differently. When I create a port forward via portforward.New() with appropriate writers for out and errOut there's cases where the errOut is ignored.

Specifically where I get an error like so:

E1007 16:49:40.319613   54503 portforward.go:409] an error occurred forwarding 62307 -> 8999: error forwarding port 8999 to pod SOME_UUID, uid : failed to execute portforward in network namespace "/var/run/netns/cni-SOME_UUID": failed to connect to localhost:8917 inside namespace "SOME_UUID", IPv4: dial tcp4 127.0.0.1:8999: connect: connection timed out IPv6 dial tcp6 [::1]:8999: connect: cannot assign requested address 

The first part an error occurred forwarding appears to come from here

Problem is I'm actually passing a custom writer to errOut, which should ensure all errors are ran through my structured logger (otherwise I get non-json output in the middle of my structured logs, which screws up the parsing of them).

---

I did find a hacky workaround after attempting to following the code, which is to call:

klog.LogToStderr(false)
klog.SetLogger(logger)

before running portforward.

Ideally I wouldn't introduce these packages into my code, but I couldn't see another way to do it.
The above method has the drawback that I have to depend on klog, go-logr and go-logr/zerologr in addition to my actual logger, zerolog. Those exist purely to prevent one unstructured error log from appearing.

If I've missed a better/cleaner way to do this, I'd love to see an example if possible.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[manterfield]

/remove-lifecycle rotten