search

kubernetes-sigs / kind

Kubernetes IN Docker - local clusters for testing Kubernetes
https://kind.sigs.k8s.io/
Apache License 2.0
13.38k stars 1.55k forks source link

kind ctl print default create cluster configuration #3168

Open tanberBro opened 1 year ago

tanberBro commented 1 year ago

What would you like to be added: Add a subcommand to print the default configuration for creating a cluster. Why is this needed: Convenient modification based on default configuration. like: kubeadm config print init-defaults, containerd config default

tanberBro commented 1 year ago

/assign

tanberBro commented 1 year ago

/cc @aojea

BenTheElder commented 1 year ago

Hmm, but unlike kubernetes API objects you cannot wind up round-tripping kind config so patching doesn't make much sense/

What's the use case where simply not setting fields is insufficient? If you don't want to override defaults you can just not set them in kind. The default is merely a one-node cluster with the default image.

tanberBro commented 1 year ago

The use case is: I want to quickly generate a list of supported fields and default values for configuration, and then make modifications on this basis.

tanberBro commented 1 year ago

@BenTheElder

BenTheElder commented 1 year ago

The use case is: I want to quickly generate a list of supported fields and default values for configuration, and then make modifications on this basis

Almost all fields are unset by default, except nodes with a list of a single node with the default image and control plane role. And you should only set known fields?

BenTheElder commented 1 year ago

This has been discussed before in this issue tracker, see prior examples.

kind cluster config doesn't round trip and there are non nontrivial default fields to patch. It's just one node with the release note listed default image. The other fields are documented opt-in advanced settings.

BenTheElder commented 1 year ago

I can't think of anything you could meaningfully patch from the default config vs just filling in a blank config. The types are already exported and documented

BenTheElder commented 1 year ago

Patching makes sense when you have a non-trivial base configuration generated by something and you want to apply partial configurations. With kind you can just use an empty config and apply patches to it, because the defaults are trivial field values like using the iptables kube-proxy mode that you should just be setting, not patching. Like if you want a default cluster, but with ipvs mode:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  kubeProxyMode: ipvs

https://github.com/kubernetes-sigs/kind/blob/main/pkg/apis/config/v1alpha4/default.go

The reason kind supports patching for e.g. containerd config is because kind itself fills in many non-default field values, so users can supply a patch on top of the non-default values kind sets.

But kind configs with values like the node image should not be persisted across kind releases (see the notes at https://kind.sigs.k8s.io/docs/user/quick-start/#creating-a-cluster about image support)

I have yet to see an example where patching the default would make sense vs the example above where you only set the fields you would've patched. Which you can consider as patching:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

If the goal is to have a structured object containing all fields, that won't work because it would be a breaking change to remove omitempty which is on most fields already and most fields don't have a default, the zero value is meaningful instead (e.g. no feature gates set). You can instead work with the go structs in pkg/apis/config/v1alpha4.