eksctl-anywhere cluster config generation with parameters for bare metal and vSphere

[ygao-armada]

Sample command for bare metal is:

eksctl anywhere generate clusterconfig <cluster name> \
   -p tinkerbell \
   -m params_tinkerbell.yaml

Sample params_tinkerbell.yaml has content:

managementClusterName: <management cluster name>
podsCidrBlocks:
  - 192.168.64.0/18 servicesCidrBlocks:
  - 10.96.0.0/12 kubernetesVersion: 1.26
cpCount: 1
workerCount: 2
cpEndpointHost: <control plane endpoint host ip>
tinkerbellIP: <tinkerbellIP>
adminIP: <admin machine ip>
osFamily: ubuntu
osImageURL: <osImageURL of K8s 1.26>
hardwareCSV: <hardware CSV file>
sshAuthorizedKeyFile: <sshKey.pub file>
tinkerbellTemplateConfigTemplateFile: tinkerbellTemplateConfigTemplateUbuntu.yaml

managementClusterName is optional, the default value is
tinkerbellTemplateConfigTemplateFile is for advanced use cases, the default ("") is ok to use

Sample command for vSphere is:

eksctl anywhere generate clusterconfig <cluster name>
   -p vsphere
   -m params_vsphere.yaml

Sample params_vsphere.yaml has content:

managementClusterName: <management cluster name>
podsCidrBlocks:
  - 192.168.192.0/18 servicesCidrBlocks:
  - 10.96.192.0/18 cpCount: 2
etcdCount: 3
workerCount: 3
cpEndpointHost: <control plane endpoint host ip>
kubernetesVersion: 1.28
datacenter: <vDatacenter>
insecure: true
network: <vCenterNetwork>
server: <serverIP>
thumbprint: <thumprint>
datastore: <vDatastore>
folder: <folder>
cpDiskGiB: 0
cpMemoryMiB: 0
cpNumCPUs: 0
etcdDiskGiB: 0
etcdMemoryMiB: 0
etcdNumCPUs: 0
workerDiskGiB: 256
workerMemoryMiB: 65536
workerNumCPUs: 16
osFamily: "ubuntu"
resourcePool: <resource pool>
template: <template name of OS>
sshAuthorizedKeyFile: <sshKey.pub>

managementClusterName is optional, the default value is <cluster name>

*Issue #, if available:
Upon request

*Description of changes:
The existing way to create a cluster config is through 3 steps:

1. use EKSA command to generate a config skeleton file.
2. change the default values like counts, cidrs, etc. to the actually values.
3. fill custom config information manually.

This new approach enable automatic cluster config generation with cluster meta data and parameterized machine template, which has following advantages:

1. fast -- users don't need to collect the config information from document and compose them, single command will generate the cluster config
2. less error-prone -- automatic config generation can avoid many mistakes introduced by manual approaches.
3. easy to maintain -- maintain meta data only, when there are changes in meta data or EKSA versions, just re-generate the config

Users can feed the custom data with following ways:

1. users specify cluster meta data in parameters file with "eksctl anywhere -m" option, if the file doesn't exist, and a sample parameter file content is supplied in the stdout based on the provider
2. for bare metal, users can use parameterized machine template file with the field "tinkerbellTemplateConfigTemplateFile" in the parameter file, if the template file doesn't exist, the sample template file is supplied in the stdout based on the osFamily
3. for bare metal, the node counts will be auto calculated from the hardware.csv file directly.

With above information, EKSA will generate a working cluster config with custom data.

Right now, only bare metal and vSphere are covered, but easy to extend to other providers.

*Testing (if applicable):

1. local-e2e
2. manual tests

*Documentation added/planned (if applicable): coming soon.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[eks-distro-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign jacobweinstock for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[eks-distro-bot]

Hi @ygao-armada. Thanks for your PR.

I'm waiting for a aws member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[ph-armada]

Hi admin - may I know if you can help review and provide feedback? Thanks