Remove non needed 2nd kubernetes node

[cmoulliard]

• Issue [Suggestion] Create only one kubernetes node and not two as this is the case today: worker and control plane #54
• Remove non needed 2nd kubernetes node to deploy only the control plane
• Add 2 new parameters to allow to set the kube version and extraPortMappings

[nabuskey]

I like the ideas and the cluster itself needs to be configurable. Instead of exposing two specific configuration options, can we let users define the kind cluster config instead? So the flag would be something like --kind-config /path/to/config

The config itself is just the kind cluster config e.g.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  ipFamily: ipv6

I think we should have the default config embedded in Go like we are doing now, but allow for customization.

[cmoulliard]

Instead of exposing two specific configuration options, can we let users define the kind cluster config instead? So the flag would be something like --kind-config /path/to/config

I think that we still need to have some parameters like: name, kube version, extraPorts and perhaps too the server IP address to be used or container type: docker, podman.

I will include the option to pass as additional parameter a kind config file.

Warning: Using such a config file could break what idpbuilder is doing internally. Example, if the config file don't include the proper registry ports, then it will not be possible to pull/push images from the docker registry container. Idem if the ports exposed don't match what ingress will register as routes, etc

Example:
if we pass as name local within this command:
./idpbuilder create --buildName local --kindConfig /path/to/my-kind.cfg
then the hostname of the registry should be equal to here within the kind config

containerdConfigPatches:
- |-
...
    endpoint = ["http://idpbuilder-local-registry:5000"]

[cmoulliard]

can we let users define the kind cluster config instead?

See commit: 964bb45 @nabuskey

[nabuskey]

Looks good except for a minor documentation line.

What would be cool is to have the ability to dump the default kind configuration file into stdout. This allows end users to easily customize kind clusters without reading too much into documentation. We can place comments in the yaml file about requirements. Out of scope for this PR though. I'll make a new issue.

Thank you for this!

[nabuskey]

Should be ./my-kind.yaml. Kind cluster configs are usually a yaml file I think.

[cmoulliard]

Should be ./my-kind.yaml. Kind cluster configs are usually a yaml file I think.

Yes but it can be suffixed with *.cfg too ;-) I will rename it

[nabuskey]

Opened a new issue related to the comment above. #58