Amoro container image managemnt

[baiyangtx]

In the next major version (0.6.0), Amoro will fully support integration with Kubernetes, and here we will discuss how to maintain official images.

Currently, Amoro has some Docker images such as arctic163/ams, but this image is only for Quick Start demonstration and is not intended for production use.

In this image, to facilitate Quick Start demonstration, the Docker image includes not only the AMS release version but also the Flink 1.15 binary package, making the overall image size relatively large.

The current issue is whether to maintain separate official images for AMS and Optimizer.

• Option 1: Maintain all-in-one images as the current plan. Rename arctic163/ams to arctic163/amoro, which includes AMS server and the Flink 1.1x binary distribution package. In the future deployment on Kubernetes, both AMS and Flink Optimizer nodes will use this image.

The advantage of this approach is fewer images, but the image size is larger, and if Spark Optimizer is added in the future, the image size will increase further.

• Option 2: Completely separate maintenance. AMS, Flink Optimizer, and Standalone Optimizer will use different images named arctic163/ams, arctic163/optimizer, and arctic163/optimizer-flink1.15. The advantage of this approach is smaller image size and clearer functional division. However, currently, AMS depends on the Flink binary distribution package to start Flink Job, making this approach more suitable for manual deployment of Flink Optimizer.

In Kubernetes deployment, an init container may be needed to use the arctic163/optimizer-flink1.15 image as the init container of the arctic163/ams image to install Flink binary distribution package.

• Option 3: Considering that the community is promoting maintenance of Optimizer directly through the Kubernetes API ([Feature]: Implement KubernetesOptimizerContainer to support running Optimizer natively on K8S. #1958), it may be possible to combine AMS and Standalone Optimizer into one image named arctic163/amoro and arctic163/optimizer-flink1.16. This approach can use a single image if KubernetesOptimizerContainer is used. At the same time, the arctic163/amoro standalone deployment method can replace the existing Quick Start.

Which option do you prefer? Or if you have better suggestions, you can express them in your comments.

[baiyangtx]

Personally, I prefer option 3. Although I have implemented the feature of Flink-native-kubernetes-optimizer, I prefer the integrated solution of directly managing pods through the Kubernetes API, which saves resources and makes it easier to control the underlying implementation.

Therefore, in the Kubernetes production environment, one amoro image is already sufficient.

In many software, nodes with different roles use the same image, such as Flink's jobmanager/taskmanager, Spark's master/executor, and the relationship between Amoro's ams/optimizer is somewhat similar, so I think it is feasible to deploy a production-ready cluster with a single image.

In addition, the standalone plugins are also lightweight enough, so maintaining them together with AMS will not incur too much cost.

These are the reasons why I prefer option 3.

[czy006]

I don't agree with the first, which will cause the image to expand rapidly over time; the second I think, is an option and can be provided, but it is not the default set it; the third is best by default.

[zhoujinsong]

In my opinion, option 3 is more suitable for Amoro's current needs, but we may need to maintain additional images for QuickStart, which currently includes AMS and Flink environments.

[baiyangtx]

Maybe we could switch quick start from hadoop to mimio ? so we will only maintain one image for QuickStart.

[HuangFru]

I agree with maintaining additional images for QuickStart. If the standalone plugins are lightweight enough, we can build QuickStart's image based on the image with AMS and Standalone Optimizer.

[baiyangtx]

the official image will be released in 0.6.0.