-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to add control-plane node #10973
Comments
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:
You can:
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:
You can:
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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-sigs/prow repository. |
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)
8760abf
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 task
Parse 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 reason
kubeadm_certificate_key
is not valid and taskkubernetes/control-plane : Create kubeadm ControlPlane config
fails.This patch resolves the bug in my situation :
The text was updated successfully, but these errors were encountered: