I think we should just remove the samples inventories (or at least the variables) and rely on roles defaults (also for documentation).

For some data point, when I came to work on the clusters I manage with kubespray, I removed more than 10k lines of inventory, accross 8 clusters. Most of it was just default value, which made quite hard to tell what was not default.

I finally found a way to minimize the amount of files, to store only values changed from defaults, here is all that we needed:

- hosts.yaml
- group_vars/all.yaml

And the example content - hosts.yaml:

all:
  vars:
    ansible_connection: ssh
    ansible_user: root
  hosts:
    node1:
      # The hostname to connect, or an external IP address of the node.
      ansible_host: mycluster.mydomain.com
      # Optionally, you can override the IP address for connecting to the node, if it differs from the hostname.
      # access_ip: 1.2.3.4
      # The node IP address in the internal network. Uncomment and set if you have a separate internal network.
      # ip: 10.0.0.2
  children:
    kube_control_plane:
      hosts:
        node1:
    kube_node:
      hosts:
        node1:
    etcd:
      hosts:
        node1:
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:

and group_vars/all.yaml:

cluster_name: mycluster.mydomain.com

supplementary_addresses_in_ssl_keys:
  - node1.mycluster.mydomain.com

helm_enabled: true

metrics_server_enabled: true
metrics_server_kubelet_insecure_tls: true

krew_enabled: true

kubectl_alias: k

And here is a "best practice" structure of the git repo:

├── inventory
│   └── mycluster
│       ├── group_vars
│       │   └── all.yaml
│       └── hosts.yaml
├── kubespray (as a git submodule)
└── .gitmodules

Having this, we can simply deploy the cluster using a command:

cd kubesprary && ansible-playbook -i ../inventory/mycluster ./cluster.yml

So, if this approach looks okay, maybe add this example as a best practice to manage minimal Kubespray configuration?

Maybe you could add group specific files in that example.
For example supplementary_addresses_in_ssl_keys should rather go in a group_vars/kube_control_plane.yml file rather than all (it's only used in the control-plane role)

Maybe you could add group specific files in that example. For example supplementary_addresses_in_ssl_keys should rather go in a group_vars/kube_control_plane.yml file rather than all (it's only used in the control-plane role)

I can, but then I should distribute all other values to different files too, and this will end up with a bunch of files again, instead of one convenient file with few strings. And having this in the all.yaml file will give us no conflicts. So I vote to keep this as simple as possible.

I created an example repository with a minimal template of the Kubespray configuration here: https://github.com/Murz-K8s/kubespray-inventory-base
Feel free to discuss and improve it.

Also, I have a question - can we simplify this part of the hosts.yaml file?

  children:
    # The list of hosts that should be included into the cluster
    kube_node:
      hosts:
        node1:
        # node2:

    # The list of nodes that should be used as the control plane.
    kube_control_plane:
      hosts:
        node1:

    # The list of nodes that should be used as the etcd storage.
    etcd:
      hosts:
        node1:

    # What's the purpose of this?
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:

Can we somehow get rid of the all.children.k8s_cluster.children group?

the k8s_cluster group is used all other the places in plays, not sure how practical it would be to remove it from inventories... Maybe we could compute it at the same time that we handle "legacy groups" 🤔

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale