Unable to Access Kind Cluster from Pester Instance on Windows VM.

[jonnguyen1]

Super odd situation here, and I'm wondering if anyone has some insight on this. I have a WSL instance running on a windows vm (interestingly enough, this does not repro on my physical machine), where I've installed docker in linux (not through docker desktop). And I've manually started the docker service with service docker start. I then created a kind cluster. I'm trying to run this particular test, but its failing to connect to the kind cluster.

    It 'Should be able to call wsl' {
      Write-Host "Testing"

      $output = wsl -d 'Ubuntu' -u root -e bash -c "kubectl get pods -A"
      Write-Host $output
    }

Calling wsl kubectl get pods works fine outside of pester tests, but is failing with this error in the tests. Note: IP is control plane of kind cluster
The connection to the server 127.0.0.1:34889 was refused - did you specify the right host or port?
Is there some type of proxy server set up by Pester?

I'm also observing this issue when calling kind. This container seems to be the control plane container.
Error response from daemon: container acbbe7561c75c80469b733a6e43ccbc22eace82b0dc117c0def12f918aea4fd8 is not running

Any help is appreciated. Thank you!

[jonnguyen1]

For whatever reason, it looks like pester is causing a restart in my kind cluster, and it doesn't get reprovisioned until after pester exits.

In Pester

CONTAINER ID   IMAGE                  COMMAND                  CREATED              STATUS                       PORTS     NAMES
696355031db2   kindest/node:v1.32.2   "/usr/local/bin/entr…"   About a minute ago   Exited (128) 5 seconds ago             kind-control-plane

After 30 sec sleep

CONTAINER ID   IMAGE                  COMMAND                  CREATED         STATUS                  PORTS                                                                               NAMES
696355031db2   kindest/node:v1.32.2   "/usr/local/bin/entr…"   2 minutes ago   Up Less than a second   127.0.0.1:41081->6443/tcp, 127.0.0.1:55000->30007/tcp, 127.0.0.1:65000->30008/tcp   kind-control-plane

(Different run, but this time I slept for 90 seconds). Note: Same exact status

CONTAINER ID   IMAGE                  COMMAND                  CREATED         STATUS                  PORTS                                                                               NAMES
696355031db2   kindest/node:v1.32.2   "/usr/local/bin/entr…"   2 minutes ago   Up Less than a second   127.0.0.1:41081->6443/tcp, 127.0.0.1:55000->30007/tcp, 127.0.0.1:65000->30008/tcp   kind-control-plane

After pester test exits, seems kind cluster stabilizes. (This is the same for both the 30 sec and 90 sec sleeps).

CONTAINER ID   IMAGE                  COMMAND                  CREATED         STATUS          PORTS                                                                               NAMES
38125a728e37   kindest/node:v1.32.2   "/usr/local/bin/entr…"   3 minutes ago   Up 12 seconds   127.0.0.1:41301->6443/tcp, 127.0.0.1:55000->30007/tcp, 127.0.0.1:65000->30008/tcp   kind-control-plane

I would expect that a 90 sec sleep would have a different status than 30 sec sleep, but I guess pester may be preventing kind cluster from working? And once it exits, it can startup again. This would explain the same results 

[jonnguyen1]

From Kubectl describe

  Type    Reason          Age   From     Message
  ----    ------          ----  ----     -------
  Normal  SandboxChanged  35s   kubelet  Pod sandbox changed, it will be killed and re-created.

[nohwnd]

Pester is just a powershell script, we don’t setup any proxy servers, and I don’t see a way pester could escape the isolation of a container and prevent your cluster from running correctly. If your Pester is running on the host, and automating the cluster (e.g. for the purpose of testing a containerized web server) then it is totally possible it stops and restarts containers, but that is all your test code. Pester does not ship any docker specific tools. Please tell us more about your setup and scenario, from the description above I am really unsure what you are asking and what the issue is.

…

-j

________________________________ Od: jonnguyen1 ***@***.***> Odesláno: Saturday, April 5, 2025 12:30:08 AM Komu: pester/Pester ***@***.***> Kopie: Subscribed ***@***.***> Předmět: Re: [pester/Pester] Unable to Access Kind Cluster from Pester Instance on Windows VM. (Discussion #2627) For whatever reason, it looks like pester is causing a restart in my kind cluster, and it doesn't get reprovisioned until after pester exits. In Pester CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 696355031db2 kindest/node:v1.32.2 "/usr/local/bin/entr…" About a minute ago Exited (128) 5 seconds ago kind-control-plane After 30 sec sleep CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 696355031db2 kindest/node:v1.32.2 "/usr/local/bin/entr…" 2 minutes ago Up Less than a second 127.0.0.1:41081->6443/tcp, 127.0.0.1:55000->30007/tcp, 127.0.0.1:65000->30008/tcp kind-control-plane (Different run, but this time I slept for 90 seconds). Note: Same exact status CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 696355031db2 kindest/node:v1.32.2 "/usr/local/bin/entr…" 2 minutes ago Up Less than a second 127.0.0.1:41081->6443/tcp, 127.0.0.1:55000->30007/tcp, 127.0.0.1:65000->30008/tcp kind-control-plane After pester test exits, seems kind cluster stabilizes. (This is the same for both the 30 sec and 90 sec sleeps). CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 38125a728e37 kindest/node:v1.32.2 "/usr/local/bin/entr…" 3 minutes ago Up 12 seconds 127.0.0.1:41301->6443/tcp, 127.0.0.1:55000->30007/tcp, 127.0.0.1:65000->30008/tcp kind-control-plane I would expect that a 90 sec sleep would have a different status than 30 sec sleep, but I guess pester may be preventing kind cluster from working? And once it exits, it can startup again. This would explain the same results — Reply to this email directly, view it on GitHub<#2627 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABLYLYLTGCXPIYOJHYHPFBD2X4BXBAVCNFSM6AAAAAB2PSIMDSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZTGA4TGNI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jonnguyen1]

My setup is like this:

• I have a windows 11 enterprise n virtual machine provisioned to run my test on.
• I've installed wsl and a docker daemon to create a very basic kind cluster
• I'm calling Invoke-Pester in a powershell script, which runs a test that essentially just calls 'kubectl get pods -A' (I've added some debugging with docker ps -a and sleeps). There are no commands that interact with the kind cluster itself.
• The issue is that this is failing as the pods have started to restart when Pester was called, and adding "Start-Sleep" doesn't help the pods come online.
• Through my investigation, I've observed that the pod sandbox is changing, which is what I'm assuming is killing the kind cluster. The ask here is if Pester can affect anything regarding the sandbox (perhaps resource usage?).
• I've noted that once pester test exits, the kind cluster successfully comes up again.

[nohwnd]

Pester is a PowerShell module, it does not start proxies, it does not touch docker or WSL, and it has no way to restart your containers. The only thing it does is run your test code.

To confirm it is not Pester, take the same wsl -d Ubuntu -u root -e bash -c 'kubectl get pods -A' call and run it in a loop from a plain script without Pester. If the cluster restarts there as well, it is the VM, most likely memory pressure from running WSL, docker and the kind node together.

If it only happens under Pester, please share a minimal repro and we can look again.