Quarkus Kubernetes Operator测试时出现NoSuchFieldError问题求助

Hey there, let's break down this issue and work through solutions. That NoSuchFieldError: _visitables is a classic sign of dependency version mismatch, specifically with the Sundr libraries that the Quarkus Operator SDK relies on under the hood. Since your operator works fine in standalone mode but fails in tests, the problem is almost certainly tied to conflicting dependencies introduced by your test setup.

Here's a step-by-step guide to fix this:

1. First, address the deprecation warning (optional but recommended) #

While not the root cause of your error, the WARN message at the top is easy to fix and avoids future issues:

Use of deprecated check-crd-and-validate-local-model property. Use crd.validate instead.

Update your application.properties (or equivalent config file) to replace the deprecated property:

# Replace this deprecated line
# quarkus.operator-sdk.check-crd-and-validate-local-model=true

# With this
quarkus.operator-sdk.crd.validate=true

2. Verify Quarkus and Operator SDK version compatibility #

First, make sure your core Quarkus version and the quarkiverse-operator-sdk extension are fully compatible. Mismatched versions here often introduce conflicting underlying dependencies like Sundr.

Check that you're using a version pair listed in the official compatibility matrix (you can find this in the Quarkus Operator SDK docs without external links—just ensure major/minor versions align, e.g., Quarkus 2.x with Operator SDK 2.x).

3. Diagnose dependency conflicts with Sundr #

Since the error originates from io.sundr classes, run a dependency tree check to spot conflicting versions:

• For Maven:

  mvn dependency:tree -Dincludes=io.sundr
  

• For Gradle:

  ./gradlew dependencies --configuration testRuntimeClasspath | grep sundr
  

Look for multiple versions of Sundr artifacts (like sundr-core, sundr-adapter-reflect) in the output—this means a test dependency is pulling in an older/newer incompatible version.

4. Lock the correct Sundr version #

Once you identify the conflicting version, force your build to use the version compatible with your Operator SDK. Add a dependency management block to your build file to lock in the right version:

Maven example (add to pom.xml): #

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.sundr</groupId>
      <artifactId>sundr-core</artifactId>
      <!-- Use the version your Operator SDK relies on (check dependency tree output) -->
      <version>0.90.4</version>
    </dependency>
    <dependency>
      <groupId>io.sundr</groupId>
      <artifactId>sundr-adapter-reflect</artifactId>
      <version>0.90.4</version>
    </dependency>
  </dependencies>
</dependencyManagement>

Gradle example (add to build.gradle): #

dependencyManagement {
  dependencies {
    dependency 'io.sundr:sundr-core:0.90.4'
    dependency 'io.sundr:sundr-adapter-reflect:0.90.4'
  }
}

5. Check test-specific dependencies #

Test dependencies (like JUnit extensions, Testcontainers, or old fabric8 libraries) often sneak in conflicting versions. For example:

• If you're using io.fabric8:kubernetes-client in tests, ensure its version matches the one used by the Operator SDK.
• Remove any redundant or outdated test dependencies that might be pulling in old Sundr versions.

6. Clean build caches #

Old cached dependencies can cause unexpected conflicts. Clear your local build cache and rebuild:

• Maven:

  mvn clean install -U
  

• Gradle:

  ./gradlew clean build --refresh-dependencies
  

Why this works #

Your standalone runtime uses a consistent set of dependencies, but test configurations often add extra libraries that introduce version conflicts. By locking the correct Sundr version and resolving these conflicts, you'll align the test environment's classpath with the working runtime environment.

内容的提问来源于stack exchange，提问作者Gabi