[
https://issues.apache.org/jira/browse/FLINK-15641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17078989#comment-17078989
]
Yang Wang commented on FLINK-15641:
-----------------------------------
[~felixzheng] [~ouyangwuli] Let's move the discussion about init-container
under FLINK-15641. I will first share my thoughts about how to the init
container works.
# The users are not aware of init container. When they are using a "flink
run/run-application" to submit a per-job cluster, they need to specify the
location of user jars, dependencies. The schema could "file://", "hdfs://",
"s3://", etc. If it is a remote path, then we need to start the init container
to download these jars and share them with JM/TM container via volume.
# Once the JM lanched, all the jars and dependencies should exit locally.
There will be an embedded client to submit the job.
# The job graph is not downloaded by init container, it is generated by
embedded client and will store in the high-availability storage if configured.
It is to avoid duplicate regeneration after JM failover.
> Support to start init container
> -------------------------------
>
> Key: FLINK-15641
> URL: https://issues.apache.org/jira/browse/FLINK-15641
> Project: Flink
> Issue Type: Sub-task
> Components: Deployment / Kubernetes
> Reporter: Yang Wang
> Priority: Major
>
> >> Why do we need init container?
> The init container could be used to prepare the use jars and dependencies.
> Then we could always set the user image to Flink official image both for
> standalone per-job on K8s or native K8s per-job. When the JobManager and
> TaskManager container launched, the user jars will already exist there. I
> think many users are running standalone per-job cluster in production by
> using this way.
> The init container only works for K8s cluster.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
