InitializeCloudFromConfig: failed to sync regional zones map for the first time: list zones: ClientSecretCredential: unable to resolve an endpoint: server response error

[m-soltani]

What happened:

fail to initialize cloud from secret xxx : list Zones: ClientSecretCredential: Unable to resolve an endpoint: context deadline exceeded

What you expected to happen:

cloud provider SDK is able to initialize successfully.

How to reproduce it (as minimally and precisely as possible):

Follow tutorial from rancher website, create a single node RKE2 cluster and configure azure cloud provider using provided YML files.

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): "v1.33.3+rke2r1"
• Cloud provider or hardware configuration: Azure VM (single cluster setup for dev/test using RKE2)
• OS (e.g: cat /etc/os-release):
  NAME="SLES"
  VERSION="15-SP2"
  VERSION_ID="15.2"
  PRETTY_NAME="SUSE Linux Enterprise Server 15 SP2"
  ID="sles"
  ID_LIKE="suse"
  ANSI_COLOR="0;32"
  CPE_NAME="cpe:/o:suse:sles:15:sp2
• Kernel (e.g. uname -a): x86_64 x86_64 x86_64 GNU/Linux
• Install tools:
• Network plugin and version (if this is a network-related bug): Canal
• Others:
  ClientId, ClientSecret are verified to be working, and I am able to obtain Azure Access token from management control plane.
• cloud-provider-azure: Installed version 1.33.3 using Helm Chart

[m-soltani]

Interestingly, I could setup the azuredisk-csi-driver helm chart with the same method, using the same kubernetes credentials successfully.

The component can successfully create and attach/detach azure disks to/from the Azure VM node. I assume these components use the same Azure GO SDKs.

[ZakariaSabour]

Hello @m-soltani, I have faced the same error here on AzureChina environment and with the azure.json config file. If you are using the same azureEnvironment it could be linked to the same issue

[m-soltani]

@ZakariaSabour: thanks for pointing out to the issue, I actually saw that before submitting this
I use AzurePublicCloud provider in this case.

[feiskyer]

should be fixed in #9418. @m-soltani are you still seeing the issue with latest versions?

[m-soltani]

@feiskyer I see the issue with 1.33.3 which is not the latest 1.34.1, I will try the new version and let you know.

[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