Improve documentation around PULUMI_K8S_DELETE_UNREACHABLE

[jkodroff]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

When I run pulumi refresh, I get the following error message, which includes how to fix the problem with an env var:

  kubernetes:core/v1:Service (default/wpdev-wordpress):
    warning: configured Kubernetes cluster is unreachable: unable to load schema information from the API server: Get "https://pulumi-rmciy6s0.hcp.westus2.azmk8s.io:443/openapi/v2?timeout=32s": dial tcp: lookup pulumi-rmciy6s0.hcp.westus2.azmk8s.io: no such host
    error: Preview failed: failed to read resource state due to unreachable cluster. If the cluster has been deleted, you can edit the pulumi state to remove this resource or retry with the PULUMI_K8S_DELETE_UNREACHABLE environment variable set to true.

However, when running pulumi destroy, I get this error message which indicates that the only way to fix the issue is to edit the state file (and doesn't even mention the pulumi state command):

  kubernetes:apps/v1:Deployment (default/wpdev-wordpress):
    error: configured Kubernetes cluster is unreachable: unable to load schema information from the API server: Get "https://pulumi-rmciy6s0.hcp.westus2.azmk8s.io:443/openapi/v2?timeout=32s": dial tcp: lookup pulumi-rmciy6s0.hcp.westus2.azmk8s.io: no such host
    If the cluster has been deleted, you can edit the pulumi state to remove this resource

Considering that PULUMI_K8S_DELETE_UNREACHABLE is way easier to use (and prrrrrrobably what most people want?), it would be cool if we could improve the visibility of this option in a few ways:

1. Make sure the provider config includes the env var option: https://www.pulumi.com/registry/packages/kubernetes/api-docs/provider/#deleteunreachable_nodejs
2. Make the error messages the same between refresh and destroy.
3. In the error message, also mention that the configuration can be set directly in the provider declaration for future reference (although I'm not sure if it'll help anyone whose stack has already been updated and the cluster has been subsequently deleted).

Affected area/feature

[lblackstone]

#2312 fixes item 1.