Upgrade Kubernetes clients and related dependencies in kubernetes-overlord-extensions and druid-kubernetes-extensions#19071
Conversation
|
|
||
| public DruidKubernetesVertxHttpClientFactory(final DruidKubernetesVertxHttpClientConfig httpClientConfig) | ||
| private static final Logger LOG = new Logger(DruidKubernetesVertxHttpClientFactory.class); | ||
| private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper(); |
There was a problem hiding this comment.
I suppose it's fine not to use the server's ObjectMapper here, but it would still be cleaner to, I think. It avoids having this static lying around when it isn't going to be used after server startup.
| <groupId>com.squareup.okhttp3</groupId> | ||
| <artifactId>okhttp</artifactId> | ||
| <version>4.12.0</version> | ||
| <version>5.3.2</version> |
There was a problem hiding this comment.
Anything to worry about with this major upgrade?
The same okhttp-4.12.0 is also used in druid-kubernetes-extensions. Possible to keep these consistent and update that one too?
There was a problem hiding this comment.
for this extension in particular, no. It is a minimum req for the the upgraded fabric8 library. We just pull the dependency explicitly to configure some dispatcher stuff under the hood.
re multiple okhttp versions, I think I'm going to pivot this PR to be a bit wider to keep this in sync. in the druid-kubernetes-extensions, we have fallen way behind on the native k8s client version. If we update that we can support okhttp 5 across both. the upgrade seems straightforward and testing locally has been positive
There was a problem hiding this comment.
eh maybe I spoke too soon on that io.kubernetes update being simple... that might force a bunch of other major dep updates as part of the dependency enforcer. I will maybe go back to the drawing board on this
There was a problem hiding this comment.
ok, after a song and dance it seems like getting aligned on okhttp 5.3.2 is doable by bumping the kubernetes client for both k8s extensions. It sure would be nice if we had a single client that we used for k8s instead of both io.kubernetes + fabric8. Maybe if all goes well with this fabric8 bump we can shed the okhttp and native jdk http clients plus use fabric8 in both k8s related extensions. Would probably save a lot of annoyances in the future.
also get a bunch of other licenses in line
capistrant
changed the title
kubernetes-overlord-extensions and druid-kubernetes-extensions
2 participants
Description
Summary
This PR bumps Kubernetes-related dependencies across both
druid-kubernetes-extensionsanddruid-kubernetes-overlord-extensions, centralizes version management in the parent pom, and adds a newWebClientOptionspass-through feature for the vert.x HTTP client.Dependency version bumps
Managed in the parent
pom.xml:io.fabric8:kubernetes-clientadditionalConfig(WebClientOptions)hook (#7384)io.kubernetes:client-java-legacyvariant avoidsvalidateJsonElementstrict validation regression in 20+com.squareup.okhttp3:okhttporg.jetbrains.kotlin:kotlin-stdlibcommons-codec:commons-codecorg.apache.commons:commons-lang3com.google.code.gson:gsoncom.amazonaws:aws-java-sdkdruid-kubernetes-extensionschangeskubernetes.client.versionproperty anddependencyManagementblock removed; versions now flow from the parent pomDefaultK8sApiClientupdated for the 25.x-legacy positional-parameter API signatures. Pod patch operations now usePatchUtils.patch()withV1Patch.PATCH_FORMAT_JSON_PATCHto set the correctContent-Typeheader (fixes 415 Unsupported Media Type)client-java-proto+protobuf-java: proto brings in protobuf-java 4.x which Druid does not yet support project-wide; the extension uses JSON wire format onlyadal4j: Azure AD auth library (and its transitive nimbus OIDC/JWT stack) not used by this extensionjakarta.ws.rs-api:4.0: conflicts with thejavax.ws.rs1.x used elsewhere in Druidokhttpas explicit dependency due to being flagged by dep analyzer (previously undeclared transitive)druid-kubernetes-overlord-extensionschangesWebClientOptionspass-through (new feature):DruidKubernetesVertxHttpClientFactorynow extendsVertxHttpClientFactoryand overridesadditionalConfig(WebClientOptions)to apply a genericMap<String, Object>of operator-configured properties. This is powered by the new hook in fabric8 7.6.0.DruidKubernetesVertxHttpClientConfig: addedwebClientOptionsmap fieldKubernetesOverlordModule: injects@Json ObjectMapperfor theWebClientOptionsmap-to-POJO deserializationvertx-uri-templatedependency (required at runtime by fabric8 7.6.0)DruidKubernetesVertxHttpClientConfigTest,DruidKubernetesVertxHttpClientFactoryTestOther
embedded-tests/pom.xml: removed hardcodedclient-java-apiversion (now managed by parent)licenses.yaml: updated versions for all changed dependencies, added new entries forjakarta.annotation-api,swagger-annotations(protobuf-extensions),okhttp/okio(overlord-extensions)docs/development/extensions-core/k8s-jobs.mdMotivation
Connection keep-alive control: Druid clusters using the vert.x HTTP client for
kubernetes-overlord-extensionscan experience connection errors when an intermediate network component (AWS ALB, Kong, service mesh, etc.) closes idle connections before the client does. TheWebClientOptionspass-through lets operators set client-side keep-alive timeouts lower than the server-side timeout.Dependency hygiene: The
io.kubernetes:client-javaandokhttpversions were managed locally in the kubernetes-extensions module, diverging from the rest of the project. Centralizing in the parent pom and upgrading to current versions improves consistency and resolves transitive dependency conflicts.Usage of new vert.x http connection pool configuration overrides
Add properties to your Overlord runtime configuration using the prefix
druid.indexer.runner.k8sAndWorker.http.vertx.webClientOptions.<property>:Any property with a public setter on
WebClientOptionsor its parent classes is supported. Invalid property names will cause the Overlord to fail on startup with a clear error message.Release note
Bumped
fabric8/kubernetes-clientfrom 7.5.2 to 7.6.0 andio.kubernetes/client-javafrom 19.0.0 to 25.0.0-legacy across both Kubernetes extensions. Upgradedokhttpfrom 4.x to 5.3.2 (centralized in parent pom). Several transitive dependency versions bumped to satisfy enforcer upper bounds:commons-codec1.20.0,commons-lang33.20.0,gson2.13.2,kotlin-stdlib2.2.21,aws-java-sdk1.12.793.Added a new
WebClientOptionspass-through for the vert.x HTTP client inkubernetes-overlord-extensions. Operators can now configure any property on the underlying Vert.xWebClientOptionsobject (connection pool size, keep-alive timeouts, idle timeouts, etc.) via Druid runtime properties. This is particularly useful for environments with intermediate load balancers that close idle connections. Most Druid deployments will not need this configuration.Key changed/added classes in this PR
DefaultK8sApiClient— migrated to client-java 25.x-legacy API +PatchUtilsDruidKubernetesVertxHttpClientFactory— now extendsVertxHttpClientFactory, addedWebClientOptionspass-throughDruidKubernetesVertxHttpClientConfig— addedwebClientOptionsmapKubernetesOverlordModule—@Json ObjectMapperinjection for vert.x factoryThis PR has: