-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
WIP Upgrade Karpenter to 1.0.0 #16758
base: master
Are you sure you want to change the base?
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
c6b05c8
to
09e208c
Compare
- id: ami-12345678 | ||
blockDeviceMappings: | ||
- deviceName: /dev/xvda | ||
ebs: {} |
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.
looks like reuse the awsmodel's defaulting logic for root volumes:
kops/pkg/model/awsmodel/autoscalinggroup.go
Lines 146 to 171 in 5d4d867
rootVolumeSize, err := defaults.DefaultInstanceGroupVolumeSize(ig.Spec.Role) | |
if err != nil { | |
return nil, err | |
} | |
var rootVolumeType ec2types.VolumeType | |
rootVolumeEncryption := DefaultVolumeEncryption | |
rootVolumeKmsKey := "" | |
if ig.Spec.RootVolume != nil { | |
if fi.ValueOf(ig.Spec.RootVolume.Size) > 0 { | |
rootVolumeSize = fi.ValueOf(ig.Spec.RootVolume.Size) | |
} | |
rootVolumeType = ec2types.VolumeType(fi.ValueOf(ig.Spec.RootVolume.Type)) | |
if ig.Spec.RootVolume.Encryption != nil { | |
rootVolumeEncryption = fi.ValueOf(ig.Spec.RootVolume.Encryption) | |
} | |
if fi.ValueOf(ig.Spec.RootVolume.Encryption) && ig.Spec.RootVolume.EncryptionKey != nil { | |
rootVolumeKmsKey = *ig.Spec.RootVolume.EncryptionKey | |
} | |
} | |
if rootVolumeType == "" { | |
rootVolumeType = DefaultVolumeType | |
} |
I had a look at the userdata problem. As part of the bare metal WIP, I've refactored the bootstrap script building so it isn't as tricky as it used to be: https://github.com/kubernetes/kops/blob/master/pkg/commands/toolbox_enroll.go#L401 I had a go at piping that through, it isn't too bad except for the wellKnownAddresses. But getting those would indeed be tricky... But - I was wondering if we should build this in the template anyway, vs uploading the kops InstanceGroups and having kops-controller (for example) expand them. This is what I've been playing with for cluster-api, and it seems to work I think (though I should probably revive and clean that up) Another advantage of doing it that way is that users could then dynamically create InstanceGroups. The gotcha is that those would not be stored in the state store so would have to be managed differently, but we don't have to support (or encourage) dynamic InstanceGroups. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
PR needs rebase. 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. |
TODO list:
fi.CloudupTask
dependencies but none of the bootstrapchannelbuilder code usesfi.Resource
rolling-update
,delete cluster
, andtoolbox dump
code to confirm it works without kops-managed launch templatesNote that this doesn't follow the required karpenter upgrade procedure - therefore existing kops clusters with karpenter enabled may not have an upgrade path to this version of karpenter. We'll need to figure out a low-effort workaround to include in the upgrade instructions.