Hi all,
As more and more images have been transformed to multi-arch-images. For those platforms only support single runtime (e.g. only support arm64/amd64 runtime environment), we can send the single arch information to containerd to request matched image. But, when the platform supports multi-arch runtimes (e.g. support arm64 and arm32 runtime environments), how can we handle multi-arch images?
Because both arm64 and arm32 container images can run on these platforms. In current code, containerd gets GOARCH from Go runtime. But the GOARCH could not represent the actual ability of the platform. For example, if you installed Golang-aarch64 on a platform that supports arm64/arm32 runtimes. The Go runtime only reports arm64 to containerd. The containerd will only find the arm64 images for this platform, but will ignore all arm32 images. In some areas, this will be an issue. For example, telecom carriers like AT&T will use arm64 servers to run lots containers for IoT services. If it can't find suitable arm64 images, it doesn't mind to run arm32 containers for IoT.
In order to solve this issue, can we pass a list of supported runtime architectures to containerd? For example, if platform supports arm64v8 and arm32v7 Runtime, we can send both to containerd. We can see this figure:
In consideration of performance, we can define priorities for these architectures to match images. On a arm64 server, we can define the highest priority for arm64. But we have divergence of handling the images when the priority matched image is missing. If we send both arm64v8 and arm32v7 to containerd to pull busybox image from repository. After parsing the image manifest file, we have following options:
- If this image supports arm64v8, that’s good, containerd will pull it for us.
- If this image supports neither arm64v8 nor arm32v7. That’s OK. containerd can exit.
- If this image support arm32v7 but doesn’t support arm64v8. How should we handle this case?
- Option#1: containerd should fall back to pull the arm32v7 image automatically and print some message to notify user
- Option#2: we should notify the user in advance and provide a choice to user to select 'Yes' or 'No' to download such compatible images.
@stevvooe @estesp @mattspencer-arm @Pennyzct @stevecapperlinaro
Regards,
Wei Chen
Hi all,
As more and more images have been transformed to multi-arch-images. For those platforms only support single runtime (e.g. only support arm64/amd64 runtime environment), we can send the single arch information to containerd to request matched image. But, when the platform supports multi-arch runtimes (e.g. support arm64 and arm32 runtime environments), how can we handle multi-arch images?
Because both arm64 and arm32 container images can run on these platforms. In current code, containerd gets GOARCH from Go runtime. But the GOARCH could not represent the actual ability of the platform. For example, if you installed Golang-aarch64 on a platform that supports arm64/arm32 runtimes. The Go runtime only reports arm64 to containerd. The containerd will only find the arm64 images for this platform, but will ignore all arm32 images. In some areas, this will be an issue. For example, telecom carriers like AT&T will use arm64 servers to run lots containers for IoT services. If it can't find suitable arm64 images, it doesn't mind to run arm32 containers for IoT.
In order to solve this issue, can we pass a list of supported runtime architectures to containerd? For example, if platform supports arm64v8 and arm32v7 Runtime, we can send both to containerd. We can see this figure:
In consideration of performance, we can define priorities for these architectures to match images. On a arm64 server, we can define the highest priority for arm64. But we have divergence of handling the images when the priority matched image is missing. If we send both arm64v8 and arm32v7 to containerd to pull busybox image from repository. After parsing the image manifest file, we have following options:
@stevvooe @estesp @mattspencer-arm @Pennyzct @stevecapperlinaro
Regards,
Wei Chen