Description
We're seeing startup errors with the Quarkus Operator SDK / Java Operator SDK when switching to K8s v1.31.0 using an extended testcontainers K3sContainer. Your containers have a different wait strategy, so I switched to your project as base container as a possible solution. So far no luck, we still run into the same issues.
Since Quarkus is using your project for their K8s Dev Services, I had a look how the out-of-the-box behavior looks like. From my observations the Dev Services are started first, then the QOSDK operator is started. Probably in combination with your "wait for ready node" wait strategy this might block the operator start until the K8s Dev Services are really functional.
With our custom container we're using @QuarkusTest in combination with @WithTestResource (formerly @QuarkusTestResource) which seems to be started concurrently with the operator. So the operator starts its watchers/informers while K8s is still initializing. My current hypothesis is that due to this different lifecycle (the operator is already started) it doesn't matter which base container I use and if its waiting correctly until K8s is ready to go or not.
Now I'm interested if your project will run into the same issue with K8s v1.31.0 (I assume not) and of course eventually the QOSDK project. I didn't check the whole code base yet, but I assume the Quarkus K8s Dev Service is using the version numbers from this project, so the first step is to bump the K8s versions here.