Enabling auto-pause addon immediately breaks api server

[planetf1]

What Happened?

Setting up minikube (as instaleld by podman desktop 1.13.1) - Enabling auto-pause plugin
results in a broken API server:

➜ bee-stack git:(kubernetes) ✗ minikube start
😄 minikube v1.34.0 on Darwin 15.2 (arm64)
✨ Using the podman (experimental) driver based on existing profile
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🚜 Pulling base image v0.0.45 ...
E1104 17:23:03.093509 50934 cache.go:189] Error downloading kic artifacts: not yet implemented, see issue #8426
🏃 Updating the running podman "minikube" container ...
🎁 Preparing Kubernetes v1.31.0 on CRI-O 1.24.6 ...
E1104 17:23:06.975357 50934 start.go:132] Unable to get host IP: RoutableHostIPFromInside is currently only implemented for linux
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
➜ bee-stack git:(kubernetes) ✗ kubectl get pods
No resources found in default namespace.
➜ bee-stack git:(kubernetes) ✗ minikube addons enable auto-pause <<<
💡 auto-pause is an addon maintained by minikube. For any concerns contact minikube on GitHub.
You can view the list of minikube maintainers at: https://github.com/kubernetes/minikube/blob/master/OWNERS
▪ Using image gcr.io/k8s-minikube/auto-pause-hook:v0.0.5
▪ auto-pause addon is an alpha feature and still in early development. Please file issues to help us make it better.
▪ https://github.com/kubernetes/minikube/labels/co/auto-pause
🌟 The 'auto-pause' addon is enabled
➜ bee-stack git:(kubernetes) ✗ kubectl get pods
E1104 17:23:30.931617 51338 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:45863/api?timeout=32s": read tcp 127.0.0.1:62309->127.0.0.1:45863: read: connection reset by peer - error from a previous attempt: read tcp 127.0.0.1:62294->127.0.0.1:45863: read: connection reset by peer
E1104 17:23:40.966391 51338 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:45863/api?timeout=32s": read tcp 127.0.0.1:62481->127.0.0.1:45863: read: connection reset by peer - error from a previous attempt: read tcp 127.0.0.1:62464->127.0.0.1:45863: read: connection reset by peer
miniE1104 17:23:50.989026 51338 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:45863/api?timeout=32s": read tcp 127.0.0.1:62632->127.0.0.1:45863: read: connection reset by peer - error from a previous attempt: read tcp 127.0.0.1:62619->127.0.0.1:45863: read: connection reset by peer
kube version
E1104 17:24:01.008808 51338 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:45863/api?timeout=32s": read tcp 127.0.0.1:62782->127.0.0.1:45863: read: connection reset by peer - error from a previous attempt: read tcp 127.0.0.1:62768->127.0.0.1:45863: read: connection reset by peer
E1104 17:24:11.025428 51338 memcache.go:265] couldn't get current server API group list: Get "https://127.0.0.1:45863/api?timeout=32s": read tcp 127.0.0.1:62931->127.0.0.1:45863: read: connection reset by peer - error from a previous attempt: read tcp 127.0.0.1:62922->127.0.0.1:45863: read: connection reset by peer
error: Get "https://127.0.0.1:45863/api?timeout=32s": read tcp 127.0.0.1:62931->127.0.0.1:45863: read: connection reset by peer - error from a previous attempt: read tcp 127.0.0.1:62922->127.0.0.1:45863: read: connection reset by peer
➜ bee-stack git:(kubernetes) ✗ minikube version
minikube version: v1.34.0
commit: 210b148
➜ bee-stack git:(kubernetes) ✗

Attach the log file

log.txt

Operating System

macOS (Default)

Driver

Podman

[Ritikaa96]

This issue is similar to #17559
seems like the issue came back again.
It was supposed to be resolved with #17866

[Ritikaa96]

given if you have tried with the latest version , this shouldnt arise.
/co auto-pause

[Ritikaa96]

/kind bug

[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

[k8s-triage-robot]

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

This bot triages 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:

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

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

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

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.