Uniqueness to machine info and ability to reference in kubeadmConfigSpec about cluster-api-provider-packet HOT 12 CLOSED

However, you can see that the type is not unique enough to distinguish. Each respective type, e.g IPv4, IPv6, and private vs. public should have unique types to reference.

Correct. This is part of the core CAPI spec, see type MachineAddressType which only is one of:

• Hostname
• InternalIP
• ExternalIP
• InternalDNS
• ExternalDNS

We don't have any real control over this to make it more precise. You can raise an issue on cluster-api if you want more precise details, or even just tags that can be applied, but it will have to be hooked into the right places in the Reconcile() loop.

from cluster-api-provider-packet.

Also, it appears as though the creation of the master and the IP it's able to advertise is coupled with the ability to create + apply an elastic IP

It is. You can do a single node control plane (CAPP used to have that), but if you want a multi-master control plane, you need to create the IP before creating the first node. This is part and parcel of how CAPI works. Even doing the single-node assumes that, but we sort of "cheated" by saying it was ready when it wasn't.

if you can omit the `{{ .controlPlaneEndpoint }} and have it default to one of the hosts' addresses, then maybe just the docs need to be updated, otherwise it would be valuable to be able to reference these as variables during the cluster initialization.

How would that work? The way CAPBK works, it uses the controlPlaneEndpoint to create the kubeconfig (/etc/kubernetes/admin.yaml, but the others as well), and then tries to reach it in kubeadm init phase wait-control-plane; it then reuses that same address in kubeadm join.

The end goal being that one does not have to have an elastic IP assigned to the master, and could reference a variable like InternalIP within the respective kubeadmConfigSpec blocks; ex

I see what you are trying to do. I tried to get it somewhere similar, but didn't have any success. It uses controlPlaneEndpoint to generate the kubeconfig, so it will get stuck on wait-control-plane no matter what you do.

You don't actually need CAPP or CAPI for this. The contents of initConfiguration and joinConfiguration are identical to those in a regular kubeadm yaml. Just spin up a node, install kubeadm, create the kubeadm.yaml you want, and run an experiment. If you can get it to work, more than happy to roll it here into CAPP.

from cluster-api-provider-packet.

@deitch while the initConfiguration and joinConfiguration are identical, I can't use the variables from the machine in that specification as far as I know, unless you're saying I should be able to pass in a variable like InternalIP?

from cluster-api-provider-packet.

I can't use the variables from the machine in that specification as far as I know

No, you cannot. I know of no way that kubeadm will inject runtime information into its parsed config. You can inject it at the CAPI level, using templates (as we do with controlPlaneEndpoint), but kubeadm itself isn't doing it.

from cluster-api-provider-packet.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

from cluster-api-provider-packet.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

from cluster-api-provider-packet.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

from cluster-api-provider-packet.

@fejta-bot: Closing this issue.

from cluster-api-provider-packet.

/remove-lifecycle rotten

from cluster-api-provider-packet.

/reopen

from cluster-api-provider-packet.

@cprivitere: Reopened this issue.

from cluster-api-provider-packet.

I'm closing this with a better comment. We can't do this as asked due to limitations in Cluster API. But even if we could, the actual effect in kubeadm would not be what people actually want (people want a floating external IP and internal only IPs that the clusters use to talk to each other...kubeadm just can't do it with its current options/flags). We do need some sort of internal only IP solution for CAPP, however, that we'll tackle in a separate issue. And hopefully I'll remember to come back and update this if kubeadm options expand in the future to permit this better.

from cluster-api-provider-packet.