-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Add support for Ignition-based bootstrap data and Flatcar Container Linux #2271
✨ Add support for Ignition-based bootstrap data and Flatcar Container Linux #2271
Conversation
Welcome @invidian! |
Hi @invidian. 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 Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't find the time to do a full review, have some comments for now :)
/ok-to-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really looking forward to this change!!
Some initial comments but will take a proper look
@invidian - we should have some e2e tests around this. Perhaps to keep the change smaller we could do that in a follow-up PR? |
From PR description:
However, if you think e2e tests could be added at later stage, that would be awesome :) |
I'll take a look at this early next week. I would really like e2e tests for this as these pieces are non-trivial and have been a frequent source of bugs. Will this work with vanilla Flatcar AMIs or do we need to build some? |
@randomvariable We need |
This is all in Image Builder, isn't it? If so, we can start publishing them in the same account as the rest of the AMIs. |
Yes, it's all in upstream Image Builder. |
@randomvariable I just pushed passing e2e tests. Right now they require custom CAPI images and manifests, as mentioned before. We run tests locally and they all pass. |
@invidian Thanks. I'll take a look, we'll aim to get this into v0.6.5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit concerned about the amount of changes we need to make to an infrastructure
provider to support a new bootstrapper. Have you all thought if this is the best way forward?
As a preparation for using it as an alternative backend to Secret Manager for OS-es, which do not support Secret Manager, like Flatcar Container Linux. Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
It will be consumed by new S3 service implementing S3 access for creating bootstrapping data for systems, which do not support pulling user data from Secret Manager, like Ignition. Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
This commit adds initial implementation of S3 service, which will be used to store bootstrap data for nodes, which do not support pulling them from Secret Manager, like ones using Ignition as bootstrap system. This commit also adds a function for creating a real S3 client similar to other functions in this package. Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
When S3Bucket.Enabled is true, cluster controller will create an S3 bucket, by default with cluster name as a bucket name, where machine controller will be able to put userdata for systems, which do not support pulling them from Secret Manager, like Ignition. When cluster is deleted, bucket will be removed as well. Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
This commit adds new Ignition block to AWSMachineSpec struct, which will allow different way of handling user data. If either bootstrap data has format defined as Ignition or user explicitly specify to use Ignition as a bootstrap format, machine controller will handle things accordingly. Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
This commit finalizes addition of Ignition support as bootstrap data format. Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
Co-authored-by: Dongsu Park <[email protected]> Signed-off-by: Mateusz Gozdek <[email protected]>
This commit adds the feature gate BootstrapFormatIgnition that will control the usage of field `ignition` in AWSMachine & AWSMachineTemplate and `s3Bucket` in AWSCluster. If user provides `ignition` field and/or `s3Bucket` without setting the feature gate then the webhook rejects the request with a validation error. Signed-off-by: Suraj Deshmukh <[email protected]>
Signed-off-by: Mateusz Gozdek <[email protected]>
Mainly so it can be referenced in the book. Signed-off-by: Mateusz Gozdek <[email protected]>
Signed-off-by: Mateusz Gozdek <[email protected]>
@invidian: The following test failed, say
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. 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/test-infra repository. I understand the commands that are listed here. |
Thanks for the docs and subsequent small changes @invidian. Based on the conversation ^^^^ and the agreement to follow up on certain items as PRs after this, from my side: /lgtm |
To make kubernetes-sigs#2271 CI pass, as current Flatcar AMIs for 1.23.0 are built using older image-builder version which we are not compatible with. Signed-off-by: Mateusz Gozdek <[email protected]>
Thanks all, this could be the largest PR that is going in for a while. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sedefsavas The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Thanks a lot for approving @sedefsavas! I'm really happy this work didn't get stale and eventually got merged. In case you want me to address unresolved conversations, they are linked in this comment: #2271 (comment). They got wrapped by GitHub, so they are not easy to reach anymore. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR adds support for handling bootstrap data in Ignition format, which will hopefully be produced by CABPK v1alpha4 implemented by PR kubernetes-sigs/cluster-api#4172 (not merged yet).
As Ignition does not plan to support multi part mime for user-data (coreos/ignition#1072), this PR implements support for putting bootstrap data in Ignition format in S3 bucket, to workaround the 64kb limitation on user-data for EC2 instances.
Similarly to SSM support, bootstrap data is removed after node has successfully bootstrapped.
Right now single S3 bucket is used for each cluster, as we need a single place to control bucket policies, which are used to restrict access for control-plane and worker nodes to only be able to access their own bootstrap data.
Finally, new template is added tailored for Flatcar Container Linux, which contains references to right now unofficial AMIs, though Flatcar support is fully added in
image-builder
already.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1979
Refs #1875
Special notes for your reviewer:
This PR can't probably be merged at this point yet. We probably need to wait until CAPI PR is merged and released, but as this PR goes in pair with CAPI one, it would be awesome to be able to get some early feedback on the approach taken.
@dongsupark is also working on adding e2e tests for it.
Checklist:
Release note: