feature: create Flatcar OS Snapshot (OS Image) on Vultr cloud

[aviral-agarwal]

Change Description

• This PR adds a vultr-flatcar-stable target to Image Builder so Flatcar-based snapshots/OS images can be built on Vultr for use with Cluster API.

• It keeps the Vultr Ubuntu flow unchanged while adding the Flatcar-specific pieces needed for communicator user selection, Ansible user selection, and build-time userdata handling.

• The Flatcar-on-Vultr flow closely follows the Flatcar AWS build path, with the Vultr-specific adjustments needed for userdata, SSH, and Ansible.

• Is this change including a new Provider or a new OS? (y/n): y, new OS (Flatcar) for existing provider (Vultr cloud)

• If yes, has the Provider/OS matrix been updated in the readme? (y/n): y

Changed Files

images/capi/Makefile

• Added flatcar-stable to the Vultr target list so Image Builder exposes build-vultr-flatcar-stable and validate-vultr-flatcar-stable.
• Added hack/ensure-jq.sh to deps-vultr because the Vultr build path now preprocesses userdata.
• Updated the Vultr build rule to read userdata_file from the target var file, check that the file exists, validate that it is JSON, base64-encode it, and pass it to Packer as userdata_base64.
• This keeps the target var file readable while matching Vultr's requirement that userdata be sent as base64 instead of raw JSON.
• flatcar-stable is intentional because Vultr exposes Flatcar channels through separate os_id values rather than one generic Flatcar image.

images/capi/packer/vultr/packer.json

• Made ssh_username configurable and kept the default as root, so existing Ubuntu targets continue to work while Flatcar can override the communicator user to core.
• Added ansible_user, kept its default as packer, and switched the Ansible provisioner to use it so Flatcar can log in to Ansible as core without changing Ubuntu behavior.
• Added a Flatcar-only bootstrap shell provisioner before Ansible to run bootstrap-flatcar.sh and prepare the VM for the main playbook.
• Switched Vultr builder userdata wiring to userdata_base64 and declared both userdata_base64 and userdata_file explicitly so target files can keep readable input while the build passes the encoded form required by Vultr.
• ssh_username and ansible_user are separate on purpose so the communicator user and the Ansible login user can be tuned independently if a provider needs that split.

images/capi/packer/vultr/flatcar-stable.json

• Added a new Vultr Flatcar Stable var file using the native Vultr Flatcar Stable os_id.
• Set both ssh_username and ansible_user to core, following the existing Flatcar pattern used elsewhere in Image Builder.
• Added the Flatcar-specific runtime values needed for Python pathing, filesystem prefixes, and Kubernetes/CNI source type so the shared provisioning flow writes to the correct paths inside Flatcar.
• Added userdata_file pointing to the Flatcar Ignition bootstrap file so the Make-based Vultr build flow can convert it to userdata_base64 at build time.
• This file keeps only target-specific overrides; shared Kubernetes and node defaults still come from the common packer/config/*.json files.

README.md

• Updated the Provider / OS Matrix to mark Flatcar as available on Vultr.
• This keeps the top-level support matrix aligned with the new vultr-flatcar-stable target added by this PR.

docs/book/src/capi/providers/vultr.md

• Added flatcar-stable.json to the Vultr provider configuration table.
• This documents the new target alongside the existing Vultr Ubuntu targets so the provider page matches the supported build inputs.

Validation

• Ubuntu and Flatcar snapshots created from this code were both used successfully to create Kubernetes clusters on Vultr.
• During validation with a newer Vultr Packer plugin, we hit a schema mismatch in images/capi/packer/vultr/packer.json: the current template uses tag, while newer plugin versions expect tags. This PR documents the issue but does not change plugin pinning or migrate the template schema.
• Hence, during validation, the Vultr Packer plugin was fixed at "2.5.0" (still under existing condition of ">2.5.0")

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign jsturtevant for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @aviral-agarwal!

It looks like this is your first PR to kubernetes-sigs/image-builder 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/image-builder has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @aviral-agarwal. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[drew-viles]

Hi, thanks!

It looks like this provider doesn't have any goss checks. Is there any reason to omit these or can you get them added in and make sure they pass?

[mboersma]

/ok-to-test

I think you may need to run make json-sort.

[aviral-agarwal]

Thanks for the direction @mboersma
json-sort has been executed and fixed in the PR branch. Passed the test as well

@drew-viles
I do believe the goss checks should be implemented as standard and good practice.

Can't say for sure why Vultr omitted the checks to begin with.
At the same time, some providers, like DigitalOcean are not implementing them as well

However, this PR focuses on flatcar implementation for Vultr
Since the two are different tracks, how about I open a new PR for adding goss checks for Vultr?

[drew-viles]

@aviral-agarwal Yeah that's a fair comment. Can you resolve the issues around the checks and we can look at getting this merged

[k8s-ci-robot]

@aviral-agarwal: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-azure-sigs	403d048	link	true	/test pull-azure-sigs

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[aviral-agarwal]

/@drew-viles Sure

Rebased the PR branch on latest main branch

I checked the failing check pull-azure-sigs and following are my observations

• It appears to be failing in existing Azure test paths, not in the Vultr code changed by this PR.
• It seems to be failing for other PRs as well, which include some of the latest commits (like ✨ Upgrade Kubernetes image to 1.36 #1993)

Based on that evidence, the current pull-azure-sigs failure does not appear to be caused by the Vultr Flatcar changes in this PR.

The two failing targets in that job are

sig-ubuntu-2604

• https://storage.googleapis.com/kubernetes-ci-logs/pr-logs/pull/kubernetes-sigs_image-builder/2021/pull-azure-sigs/2062586878128820224/artifacts/azure-sigs/ubuntu-2604.log
• Ubuntu 26.04 fails during TASK [kubernetes : Add the Kubernetes repo] with NO_PUBKEY EB3E94ADBE1229CF and The repository 'https://packages.microsoft.com/ubuntu/18.04/prod bionic InRelease' is not signed.

sig-windows-2022-containerd-cvm

• https://storage.googleapis.com/kubernetes-ci-logs/pr-logs/pull/kubernetes-sigs_image-builder/2021/pull-azure-sigs/2062586878128820224/artifacts/azure-sigs/windows-2022-containerd-cvm.log
• Windows 2022 CVM fails during Goss with 'chmod' is not recognized as an internal or external command and The system cannot execute the specified program.

[k8s-ci-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.