kubernetes-sigs/kubespray

kubectl_localhost get wrong binary when ansible host arch is different from deployed cluster

Open

#11 608 ouverte le 7 oct. 2024

Voir sur GitHub
 (8 commentaires) (0 réactions) (1 assigné)HTML (4 419 forks)batch import
help wantedkind/bug

Métriques du dépôt

Stars
 (10 380 stars)
Métriques de merge PR
 (Merge moyen 25j) (26 PRs mergées en 30 j)

Description

What happened?

when enable kubectl_localhost and ansible host arch is x86_64 and deploy a kubernetes cluster on aarch64 systems it copy the binary from the host.

binary from aarch64 host is not got for x86_64 ansible host error: kubectl: cannot execute binary file: Exec format error1

https://github.com/kubernetes-sigs/kubespray/blob/master/roles/kubernetes/client/tasks/main.yml#L90

What did you expect to happen?

when kubectl_localhost enable download correct arch binary to the ansible host

How can we reproduce it (as minimally and precisely as possible)?

1x ansible host x86_64 arch 1x controller node aarch64 arch

deploy kubespray with kubectl_localhost

OS

Ubuntu2204

Version of Ansible

2.17.0

Version of Python

3.11

Version of Kubespray (commit)

master

Network plugin used

calico

Full inventory with variables

Command used to invoke ansible

ansible-playbook -i inventory/arm/hosts.yaml cluster.yml

Output of ansible run

Anything else we need to know

No response

Guide contributeur

Direction de recherche
Inspectez la tâche dans roles/kubernetes/client/tasks/main.yml autour de la ligne 90. La logique actuelle copie le binaire kubectl depuis le nœud contrôleur. Elle doit être modifiée pour détecter l'architecture de l'hôte Ansible et télécharger le binaire de l'architecture appropriée. Alternativement, envisagez d'utiliser le fait ansible architecture pour sélectionner le binaire correct. Assurez vous que le binaire téléchargé est placé à l'emplacement attendu.
Stack technique
Aucun
Domaine
devopsinfrastructure
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitAnsible
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65