fix: Switched to multi-node builds to support Kaniko multi-platform builds

[rayshoo]

Fixes: #9861

Description
Kaniko cannot generate multi-platform images from a single node.

• amd64 builds must run on amd64 nodes.
• arm64 builds must run on arm64 nodes.

Although the skaffold.yaml config schema suggests multi-platform support, the resulting images actually only contained a single platform.
If the first build was amd64, subsequent images (even marked as arm64) were still amd64.
This behavior is essentially a bug.
The fix allows building images separately on the correct architecture nodes and then combining them into a genuine multi-platform image. Verified by testing.

User facing changes (remove if N/A)

1. Modified the loop in pkg/skaffold/build/platform.go#L59 to reflect each architecture as a node selector, since the architectures are already being passed individually.
2. Fixed an issue where the IMAGE_TAG environment variable was always suffixed with the first build architecture.

[gemini-code-assist]

Summary of Changes

Hello @rayshoo, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves critical issues related to multi-platform image builds within Kaniko. The changes ensure that images are genuinely multi-platform by correctly orchestrating builds on architecture-specific nodes and accurately managing environment variables during the build process. This improves the reliability and correctness of multi-architecture container image generation.

Highlights

• Multi-platform Image Build Correction: Ensured that multi-platform images are correctly built by running architecture-specific builds on the appropriate nodes, resolving an issue where Kaniko previously produced single-platform images despite configuration.
• IMAGE_TAG Environment Variable Fix: Addressed a bug where the IMAGE_TAG environment variable was always incorrectly suffixed with the first build architecture, by ensuring that build artifact environment variables are properly handled and isolated during evaluation.
• Explicit Node Selector Assignment: Modified the Kaniko pod specification to explicitly set node selectors for architecture and operating system, guaranteeing that builds are scheduled on the intended architecture nodes.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly fixes a bug in multi-platform image builds with Kaniko, where build configurations were incorrectly shared across different architecture builds. The changes introduce a copy of the artifact configuration for each platform-specific build in pkg/skaffold/build/cluster/kaniko.go, which properly isolates environment variables and prevents state leakage between builds. Additionally, the modification in pkg/skaffold/build/cluster/pod.go to unconditionally set the node selector for OS and architecture ensures that Kaniko pods are scheduled on nodes that match the target platform. These changes are well-implemented and effectively address the described issue.

[rayshoo]

When building an arm64 image with Kaniko, if the base image is a multi-platform image (e.g., FROM baseimage), Kaniko would pull the amd64 image instead of the arm64 one. Although the build completed successfully, the resulting image failed to run properly. To resolve this, I added Kaniko’s --custom-platform flag, which ensured that the correct architecture’s image was pulled during the build. After this change, the image built and ran successfully on the intended architecture.