Closed nvalembois closed 1 week ago
I have the same problem when trying to replace a first-controlplane node. The docs https://github.com/kubernetes-sigs/kubespray/blob/master/docs/nodes.md just dont work.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
What happened?
Playbook cluster.yml fails when adding a new control plane node to an existing cluster.
What did you expect to happen?
Playbook cluster.yml succeeds.
How can we reproduce it (as minimally and precisely as possible)?
In a cluster deployed with Kubespray :
OS
Linux 6.1.0-18-amd64 x86_64 PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
Version of Ansible
ansible [core 2.16.2] config file = /home/nicolas/git/kub/k8s-leno/kubespray/ansible.cfg configured module search path = ['/home/nicolas/git/kub/k8s-leno/kubespray/library'] ansible python module location = /home/nicolas/ansible/lib/python3.11/site-packages/ansible ansible collection location = /home/nicolas/.ansible/collections:/usr/share/ansible/collections executable location = /home/nicolas/ansible/bin/ansible python version = 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] (/home/nicolas/ansible/bin/python3) jinja version = 3.1.3 libyaml = True
Version of Python
Python 3.11.2
Version of Kubespray (commit)
8760abf4b
Network plugin used
calico
Full inventory with variables
localhost | SUCCESS =>
leno1 | SUCCESS =>
lenop | SUCCESS =>
leno2 | SUCCESS =>
leno4 | SUCCESS =>
leno3 | SUCCESS =>
Command used to invoke ansible
ansible-playbook playbooks/cluster.yml --limit=kube_control_plane --become
Output of ansible run
Only put then end, full log is too long.
Anything else we need to know
When adding a new control-plane, the task
kubernetes/control-plane : Create kubeadm token for joining nodes with 24h expiration (default)
is delegated tofirst_kube_control_plane
(leno4
in the run). The taskParse certificate key if not set
in kubeadm-secondary sets facts fromgroups['kube_control_plane'][0]
which is not the same node (lenop
in the run). For this reasonkubeadm_certificate_key
is not valid and taskkubernetes/control-plane : Create kubeadm ControlPlane config
fails.This patch resolves the bug in my situation :