-
Notifications
You must be signed in to change notification settings - Fork 830
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
feat: Add windows support #3698
Conversation
✅ Deploy Preview for karpenter-docs-prod canceled.
|
Wow, thanks for writing this up. @jonathan-innis can you review? |
5c9cc40
to
99af8e5
Compare
@jonathan-innis @ellistarn |
@jonathan-innis @rawahars
Please review the new change. Thanks |
Our general feeling is that an AMIFamily should be centered around the userData that is used to startup the node and attach it to the cluster. An AMIFamily should be a grouping of AMIs that have effectively the same configuration. With that in mind, I think it would be preferable to have Musing: I wonder if we can do this through the windows build number that we know will get populated to the node when the node registers with the cluster. We can support different AMI SSM aliases and have them be compatible with different sets of |
@rawahars Can you comment on this one? |
It's reasonable but we need to first decide on the source of AMI. There are two options
All are doable, and please shed some light on this. |
I'd argue either the Provisioner or the workload is the best place. At a high-level, the philosophy behind the different components is:
You can imagine a scenario where a version of Windows isn't defined in the Provisioner at all and its just defined at the workload level, which will be passed into the launched machine requirements and be used to select the correct Windows AMI version for that workload |
Referencing the Upstream Kubernetes Windows User Guide for more info on the windows build version and windows best-practices |
I'm afraid I have no idea to implement the Windows build version without AWS EKS team support. I notice that the new AMIFamily @jonathan-innis Any idea? |
@topikachu Yes, this is the idea, that the |
ff013a8
to
a3b59a5
Compare
@jonathan-innis Please check this new change. |
@topikachu Can you rebase the change? It looks like you have a few conflicts in a few files in the PR |
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.
Looking good! Just some high-level nits
fa1d83e
to
1b4fec1
Compare
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.
/karpenter snapshot
Snapshot successfully published to |
Fixes aws#1131 This change try to integrate with the latest EKS window support. Add two new Windows AMI Family, Windows2019 and Windows2022. Only Core are supported OOTB. Windows relevant code, "kubernetes.io/os" and "vpc.amazonaws.com/PrivateIPv4Address" is only active when Windows AMI Family defined in the AwsNodeTemplate Users can use amiSelector to choose other AMIs. Test on a Linux and Windows mixed system for provision and de-provision. Test on a live system with mixed Windows and Linux workload. Both provision and de-provision are tested
1. Remove variant in windows family since we only support "Core" now. 2. Follow the test case convention to test labels.
1. Remove unused consts 2. Add SupportsENILimitedPodDensity feature flag. 3. Make kubeletExtraArgs as a generic method of amifamily.Options 4. Add ContainerRuntime parameter in windows bootstrap 5. Change ENILimitedPods, maxPods, privateIPv4Address
1. Fix the issue that double ContainerRuntime is configured in Windows 2. Refactor getOSRequirement 3. Refine test and one new to test pods number on windows node
02b1566
to
4435349
Compare
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.
/karpenter snapshot
Snapshot successfully published to |
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.
/karpenter snapshot
Snapshot successfully published to |
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.
LGTM 🚀
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.
lgtm
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.
LGTM 🚢
Thank you for accepting my code change. I'm excited that the addition of Windows support to Karpeneter will benefit all users. If there are any further modifications needed, please let me know. I'm eager to contribute more to the Karpeneter project and assist in any way I can. Thanks again for the opportunity. |
Fixes #1131
Description
This change try to integrate with the latest EKS window support.
Add two new Windows AMI Family, Windows2019 and Windows2022.
Only Core are supported OOTB.
Windows relevant code, "kubernetes.io/os" and "vpc.amazonaws.com/PrivateIPv4Address" is only active when Windows AMI Family defined in the AwsNodeTemplate
Users can use amiSelector to choose other AMIs.
Test on a Linux and Windows mixed system for provision and de-provision.
How was this change tested?
Does this change impact docs?
New document is required after this change is approved.
Release Note
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.