Exibição da senha do proxy na inicialização do minikube

[CalobTech]

 
Os comandos necessários para reproduzir o problema: minikube start
 
A saída completa do comando que apresentou falha:

minikube start
😄 minikube v1.34.0 on Fedora 41 (vbox/amd64)
✨ Using the podman driver based on existing profile
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🚜 Pulling base image v0.0.45 ...
E1230 16:45:08.621848 40114 cache.go:189] Error downloading kic artifacts: not yet implemented, see issue #8426
🔄 Restarting existing podman container for "minikube" ...
🌐 Found network options:
▪ HTTP_PROXY=http://CalobTech:*****@proxy.intranet:9090
▪ HTTPS_PROXY=http://CalobTech:*****@proxy.intranet:9090
▪ NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,192.168.59.0/24,192.168.49.0/24,192.168.39.0/24
▪ HTTP_PROXY=http://CalobTech:*****@proxy.intranet:9090
▪ HTTPS_PROXY=http://CalobTech:*****@proxy.intranet:9090
▪ NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,192.168.59.0/24,192.168.49.0/24,192.168.39.0/24
❗ Failing to connect to https://registry.k8s.io/ from both inside the minikube container and host machine
💡 To pull new external images, you may need to configure a proxy: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/
🐳 Preparing Kubernetes v1.31.0 on Docker 27.2.0 ...
▪ env HTTP_PROXY=http://CalobTech:[email protected]:9090
▪ env HTTPS_PROXY=http://CalobTech:[email protected]:9090
▪ env NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,192.168.59.0/24,192.168.49.0/24,192.168.39.0/24
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: default-storageclass, storage-provisioner
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

A saída do comando minikube logs:

A versão do sistema operacional usado:
Fedora 41 x86-64

[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