-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Pod template task adapter #13896
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
Pod template task adapter #13896
Conversation
...s-overlord-extensions/src/main/java/org/apache/druid/k8s/overlord/common/K8sTaskAdapter.java
Fixed
Show fixed
Hide fixed
...rd-extensions/src/main/java/org/apache/druid/k8s/overlord/common/PodTemplateTaskAdapter.java
Fixed
Show fixed
Hide fixed
| .addToAnnotations(getJobAnnotations(taskRunnerConfig, task)) | ||
| .endMetadata() | ||
| .withNewSpec() | ||
| .withTemplate(podTemplate.getTemplate()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this work with sidecars injected by a controller? Something like istio for example where you have a control plane which injects a sidecar container into your template. I think what would happen is your job would run and then never really complete....because the istio container would never shut down, you would only exit the main container. I don't know an easy way to do this unless you can do some more templating in yaml, but maybe at the very least I would call this out: If you have a service mesh, which injects sidecars (like istio) this approach may not work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing you can do (since the template overrides the run command) is include something after the main run command that kills the istio pod.
e.g.
java ... CliPeon...
exit_code=$(echo $?); curl -fsI -X POST http://localhost:15020/quitquitquit && exit $exit_code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user can write their pod spec in any way that they like in order to conform to the peculiarities of their Kubernetes infra. As @georgew5656 mentioned there are a few ways to handle sidecars, from our perspective Druid need not be opinionated about how one would handle starting, stopping and configuring them.
|
Could you update the README for this extension on how to use this? That would help a lot in reviewing this. I am a bit unclear how this is initialized, what properties need to be set, vs configurations, etc... |
| ); | ||
| return command; | ||
| } | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you explain how the CliPeon is going to work with this approach? How is AbstractTask going to look as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No changes are required to CliPeon or AbstractTask. With the PodTemplateTaskAdapter everything is up to the user to specify. Our plan moving forward will be for sane defaults to be set within helm but those changes will be made in a future PR.
This PR just introduces the That said, the user will specify |
georgew5656
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this generally looks good to me, I left one clarification comment and one small nit
| public interface TaskAdapter | ||
| { | ||
|
|
||
| V fromTask(Task task, PeonCommandContext context) throws IOException; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think there was some idea that we would want to leave open the option of non K8s Task Runners (e.g. fargate) which would imply the need for non K8s TaskAdapters, is there a need to override this class? wouldn't K8sTaskAdapter implements TaskAdapter<Job, Pod> still work here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Realizing TaskAdapter is actually a K8s only concept so this comment is not relevant.
I do think TaskAdapter being only for k8s to be a little confusing though, i think it would make more sense if the current TaskAdapter was called K8sTaskAdapter and the current K8sTaskAdapter was called K8sFromOverlordTaskAdapter or something similar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would implement Fargate within a FargateTaskRunner. The TaskAdapter concept is a KubernetesTaskRunner only concept not a Druid one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why would Fargate be implemented through a different runner? doesn't fargate offer k8s api?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unfamiliar with the api that Fargate provides. If it does offer a k8s api then yes we could continue to use the KubernetesTaskRunner.
| MapperConfig config = mapper.getDeserializationConfig(); | ||
| AnnotatedClass cls = AnnotatedClassResolver.resolveWithoutSuperTypes(config, Task.class); | ||
| Collection<NamedType> taskSubtypes = mapper.getSubtypeResolver().collectAndResolveSubtypesByClass(config, cls); | ||
| for (NamedType namedType : taskSubtypes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a use case that we'd want multiple specs for a single task type? like e.g. a bigger index_kafka job vs a smaller index_kafka job? I don't think that needs to be supported in this PR but it would be good to still have the option to implement something like that in the future.
I guess with this implementation you could just set druid.indexer.runner.k8s.podTemplate.index_parallel_custom or something, and assuming there's some field on the task (customJobTemplate or similar) that specifies to use this template, to reference that field?
abhishekagarwal87
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except some minor comments
...rd-extensions/src/main/java/org/apache/druid/k8s/overlord/common/PodTemplateTaskAdapter.java
Show resolved
Hide resolved
| public static String TYPE = "PodTemplate"; | ||
|
|
||
| private static final Logger log = new Logger(PodTemplateTaskAdapter.class); | ||
| private static final String TASK_PROPERTY = IndexingServiceModuleHelper.INDEXER_RUNNER_PROPERTY_PREFIX + ".k8s.podTemplate.%s"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you going to document this in a follow up PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, these will be documented in the next PR that hooks the PodTemplateTaskAdapter up.
| public interface TaskAdapter | ||
| { | ||
|
|
||
| V fromTask(Task task, PeonCommandContext context) throws IOException; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why would Fargate be implemented through a different runner? doesn't fargate offer k8s api?
...-extensions/src/test/java/org/apache/druid/k8s/overlord/KubernetesTaskRunnerFactoryTest.java
Show resolved
Hide resolved
|
|
||
| KubernetesTaskRunner runner = factory.build(); | ||
|
|
||
| Assert.assertNotNull(runner); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment as above here.
...rd-extensions/src/main/java/org/apache/druid/k8s/overlord/common/PodTemplateTaskAdapter.java
Show resolved
Hide resolved
| @Test | ||
| public void test_fromTask_withoutBasePodTemplateInRuntimeProperites_raisesIAE() | ||
| { | ||
| Assert.assertThrows(IAE.class, () -> new PodTemplateTaskAdapter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also verify that the correct error message is included in the exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do add error message verification as well.
Kubernetes pod template task adapter for the Kubernetes task runner
Purpose
The existing Kubernetes task runner generates a pod spec for the peons by copying the pod spec of the master pod. While the existing implementation offers some configurability, it is not enough for some users who will need to run Peons with a completely different pod spec from the master pod.
Changes
Note
This PR only introduces the
PodTemplateTaskAdapterit will be wired up in a forthcoming within theKubernetesTaskRunnerFactoryKey changed/added classes in this PR
PodTemplateTaskAdapterK8sTaskAdapterThis PR has: