-
Notifications
You must be signed in to change notification settings - Fork 4.7k
(Experimental) bare-metal with IPv6 #16944
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
Conversation
I am trying to upload this and then I can rebasing as I/we fix each problem. Current problem is from nodeup:
So we need to decide how the podCIDR is assigned! |
346c7ce
to
88116be
Compare
1204c0d
to
23634fb
Compare
2e6784b
to
4ff49a7
Compare
/retest |
4ff49a7
to
67a7b40
Compare
52749c9
to
39d7698
Compare
5759774
to
29997cc
Compare
2792a42
to
a84f931
Compare
cc @hakman I think this is now uncontroversial (I hope). We assign podCIDRs to nodes if they are configured on the Host object. If users don't want to do that, they just don't set podCIDRs on the Host object. |
Cool, I will take a look soon. 🚀 |
IPv6 brings some new complexities, particularly around IPAM.
While we do require CCM for IPv6, we should configure the appropriate CCM.
This is needeed for bootstrapping the control plane, because it's a CRD so can't be registered until the control plane is running. It's also quite nice because we might want to review the contents of the host CRD, e.g. to verify the key out-of-band.
a84f931
to
3f25b1e
Compare
/retest |
/test all |
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 great, just a small nit.
@@ -36,6 +36,9 @@ type Host struct { | |||
type HostSpec struct { | |||
PublicKey string `json:"publicKey,omitempty"` | |||
InstanceGroup string `json:"instanceGroup,omitempty"` | |||
|
|||
// PodCIDRs configures the IP ranges to be used for pods on this node/host. | |||
PodCIDRs []string `json:"podCIDRs,omitempty"` |
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.
Should this be added to the v1apha3
API too? What about the main API?
kops/pkg/apis/kops/v1alpha3/host.go
Lines 36 to 39 in 5f564fe
type HostSpec struct { | |
PublicKey string `json:"publicKey,omitempty"` | |
InstanceGroup string `json:"instanceGroup,omitempty"` | |
} |
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.
Great call. But I propose doing it as a separate PR, because I think we are also missing a round-trip test that would have caught this!
/hold in case you want to update the other APIs (could also be a separate PR). |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hakman 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 |
/test pull-kops-e2e-k8s-aws-amazonvpc |
/test pull-kops-e2e-k8s-gce-cilium |
/test pull-kops-e2e-k8s-aws-calico |
/test pull-kops-e2e-k8s-aws-amazonvpc |
/hold cancel I propose adding a round-trip test alongside fixing the missing field in v1alpha3 |
IPv6 brings some new complexities, particularly around IPAM.
We create a test and then fix a few things:
node.kops.k8s.io/uninitialized
taint for CCM to clear, and nobody clears it.