Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upgrade kubernetes extension k8s client api jar to v16 #13175

Closed

Conversation

coryverta
Copy link

@coryverta coryverta commented Oct 3, 2022

Applies to #12904.

Description

  • Upgrade the k8s client API jar to v16.0.0
  • Adopt the API changes required in the kubernetes extension

Kubernetes client API jar v.11.0.0 contains several critical security vulnerabilities. Adopting v16 requires two small changes to the existing code:

  1. a new constructor parameter has been added to the ApiClient
  2. the ApiClient config now requires the date formatter used to parse the timestamps in the k8s metadata.
  3. pod metadata can be null, which creates an NPE attempting to extract information. This is treated the same as if the pod itself were null, an existing condition.

The date parsing in particular is necessary to handle the possible date format differences.

  • pom change to bump the k8s client jar version
  • constructor change - ApiClient now requires an additional parameter
  • APIClient config change - requires a custom data parser to support he data format used by druid.

This PR has:

  • been self-reviewed.
  • added documentation for new or modified features or behaviors.
  • added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
  • added or updated version, license, or notice information in licenses.yaml
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
  • added integration tests.
  • been tested in a test Druid cluster.

@coryverta coryverta changed the base branch from master to 24.0.1 October 3, 2022 22:21
import java.text.SimpleDateFormat;
import java.util.Collections;
import java.util.List;
import java.util.TimeZone;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't change the import order. This is unnecessary.
And this is not the Druid' code style.
If you're using intellij, see: https://github.com/apache/druid/blob/master/dev/intellij-setup.md

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return Config.defaultClient();
final SimpleDateFormat dateFormat = new SimpleDateFormat(
"yyyyMMdd'T'HHmmss.SSS'Z'");
dateFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the timezone specified as UTC? What if users deploy Druid by setting -Duser.timezone to some other zones?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I parsed out the exact timestamps that are read from the pod metadata. Where in the codebase is the formatter that sets that? I can simply use that format to match whatever the user has configured. I'll look and see if I can find it, but if you happen to know where to look I'd appreciate it.

Copy link
Member

@FrankChen021 FrankChen021 Oct 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the formatter is used to parse the date string that are returned from K8S server side? And the string is always in UTC format? If so, the change makes senses.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the kind of thing that should be always UTC, since it's a server thing, not a user-facing or data-related timestamp.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to confirm that this always originates in K8s, and is always consistent. It is likely better to allow this format string to be configured by the user, but to default the most common format.

@gianm
Copy link
Contributor

gianm commented Oct 4, 2022

Thanks for the contribution! @coryverta, for posterity could you please note what issue you were running into that this change fixed?

One note. This will not actually fully address #12904, since there's some additional housekeeping needed to actually move something out of experimental status: doc updates and the like. IMO, it's best to do that separately anyway, perhaps one release from now so we have some more chance for production experience to roll in.

@coryverta coryverta changed the title 12904 - upgrade kubernetes extension k8s client api jar to v16 upgrade kubernetes extension k8s client api jar to v16 Oct 4, 2022
@coryverta
Copy link
Author

@gianm I updated the PR docs to indicate that this applies to #12904 but does not fix it as there is additional work to be done.

Copy link
Contributor

@gianm gianm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coryverta I just noticed that this PR is raised against apache:24.0.1. Could you please re-raise it against master? We do all patches to master first, then port them to release branches as needed.

There is also some kind of compilation problem: https://lgtm.com/projects/g/apache/druid/logs/rev/pr-a2a67ae736a7253b7f263af823cc7f3b945d068f/lang:java/stage:Build%20merge_5c1b4c6978cbb2f6649e6f1310d8cdeb58469eab

[2022-10-04 20:17:36] [build-stdout] [2022-10-04 20:17:36] [autobuild] [ERROR] /opt/src/extensions-core/kubernetes-extensions/src/main/java/org/apache/druid/k8s/discovery/DefaultK8sApiClient.java:[68,16] method patchNamespacedPod in class io.kubernetes.client.openapi.apis.CoreV1Api cannot be applied to given types;
[2022-10-04 20:17:36] [build-stdout] [2022-10-04 20:17:36] [autobuild]   required: java.lang.String,java.lang.String,io.kubernetes.client.custom.V1Patch,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.Boolean
[2022-10-04 20:17:36] [build-stdout] [2022-10-04 20:17:36] [autobuild]   found: java.lang.String,java.lang.String,io.kubernetes.client.custom.V1Patch,java.lang.String,<nulltype>,<nulltype>,<nulltype>
[2022-10-04 20:17:36] [build-stdout] [2022-10-04 20:17:36] [autobuild]   reason: actual and formal argument lists differ in length
[2022-10-04 20:17:36] [build-stdout] [2022-10-04 20:17:36] [autobuild] [INFO] 1 error

Something wrong with the new client version, perhaps?

@coryverta
Copy link
Author

NOTE: there is an underlying bug in the v16 kubernetes client API jar that is conflated with a bug involving pod deletions. I will close this specific PR and replace it with two, one that addresses the underlying bugs in the existing extendsion against client api v11.0.3, and then a follow-up to adopt v16.

@coryverta coryverta closed this Oct 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Promote druid-kubernetes-extensions out of experimental status
3 participants