Kubeadm: aucun moyen programmatique d'obtenir le jeton de découverte ca hash

Avez-vous essayé la version récente de kubeadm ?

# kubeadm token create --print-join-command
kubeadm join --token 5d2dc8.3e93f8449167639b 10.0.2.66:6443 --discovery-token-ca-cert-hash sha256:44a68d4a2c2a86e05cc0d4ee8c9c6b64352c54e450021331c483561e45b34388

ce n'est toujours pas génial - toute personne essayant de l'utiliser par programme devra analyser la commande afin d'extraire à la fois le jeton et le hachage du jeton de découverte. Ce serait mieux si nous pouvions spécifier un formulaire de sortie comme json afin que nous puissions l'analyser en toute sécurité

merci, je ne savais pas qu'il y avait une commande séparée/nouvelle pour cela. Je suis d'accord, ce serait mieux d'avoir ça en json. mon flux de travail précédent pour 1.6 et 1.7, était kubeadm token generate, puis réutilisait cette valeur lors de l'initialisation et de la jointure, le kubeadm token generate était délimité par une ligne de valeur unique lisible par machine, mais c'est maintenant effectivement une commande morte car il manque la cert hash (et non extensible en soi en raison de ce format). re pourquoi lisible par machine, j'ai des paramètres supplémentaires à passer pour la jointure et certains que je dois remplacer comme DNS pour l'ip.

Oui, j'ai dû vider la commande de jointure dans un fichier, puis utiliser sed pour ajouter un indicateur ignorer les erreurs de contrôle en amont, pas terrible mais pas particulièrement convivial non plus.

Il y a donc un effort continu pour rogner les phases pour le rendre plus programmatique et dédupliquer les drapeaux, ce n'est qu'une histoire d'utilisateur. @fabriziopandini avez-vous un problème de parent pour cela quelque part?

@timothysc
Le problème pour les phases d'obtention du diplôme est le numéro 454, mais il est en quelque sorte obsolète et il serait peut-être logique de commencer par un nouveau dès que le prochain KEP sera approuvé.

Cependant, en ce qui concerne ce problème, l'OMI devrait ouvrir un problème générique dédié pour répondre à la demande de sortie lisible par machine de manière cohérente pour toutes les commandes, car la demande s'étend de kubeadm init/phases à kubeadm token et aussi kubeadm upgrade (voir #494).

WDYT ? si ça vous va, j'ouvrirai le nouveau numéro parapluie...

Je viens de frapper ce problème moi-même. J'ai pu calculer la somme sha256 de la clé publique du certificat ca en utilisant les éléments suivants :

$ openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -pubkey | openssl rsa -pubin -outform DER 2>/dev/null | sha256sum | cut -d' ' -f1

Pas beau...

J'utilise les expressions régulières. J'ai testé avec Ansible.

- hosts: localhost
  tasks:
    - shell: kubeadm token create --print-join-command
      register: results
    - debug:
        var: results.stdout
    - set_fact:
        token: "{{ results.stdout | regex_search(regexp, '\\2') | first }}"
      vars:
        regexp: '([^\s]+\s){4}([^\s]+)'
    - debug:
        var: token
    - set_fact:
        hash: "{{ results.stdout | regex_search(regexp, '\\2') | first }}"
      vars:
        regexp: '([^\s]+\s){6}([^\s]+)'
    - debug:
        var: hash

Résultat:

TASK [debug] *******************************************************************************************************************************************************************************************************
ok: [localhost] => {
    "results.stdout": "kubeadm join 192.168.1.2:6443 --token 3a0fje.octau87o6x30dz8i --discovery-token-ca-cert-hash sha256:1fd18093fb89b364879d5667b7ec84fd24171c30de0070deb6a3801b54a0f85c"
}

TASK [set_fact] ****************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [debug] *******************************************************************************************************************************************************************************************************
ok: [localhost] => {
    "token": "3a0fje.octau87o6x30dz8i"
}

TASK [set_fact] ****************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [debug] *******************************************************************************************************************************************************************************************************
ok: [localhost] => {
    "hash": "sha256:1fd18093fb89b364879d5667b7ec84fd24171c30de0070deb6a3801b54a0f85c"
}

Fermeture car il existe plusieurs solutions de contournement.

Ce n'est pas recommandé mais, dans https://github.com/cablespaghetti/kubeadm-aws/blob/master/worker.sh#L45 --discovery-token-unsafe-skip-ca-verification fonctionne également

sur Azure, en utilisant des balises pour les ressources worker et master :
rg est une variable avec le nom RG

masterPrivateIp=$(az network nic list -g $rg --query "[?tags.module == 'k8smasters'].ipConfigurations[0].privateIpAddress" -o tsv)
tokenId=$(ssh $masterIp "liste de jetons kubeadm | grep -v TOKEN | cut -d' ' -f1")
tokenSHA=$(ssh $masterIp "openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -pubkey | openssl rsa -pubin -outform DER 2>/dev/null | sha256sum | cut -d' ' -f1 ")

joinCommand="kubeadm join $master PrivateIp:6443 --token $tokenId --discovery-token-ca-cert-hash sha256:$tokenSHA"

pour ip dans $(az network public-ip list -g $rg --query [?tags.module == 'k8sworkers'].ipAddress -o tsv)
faire
ssh $ip $joinCommande
terminé