J'utilise Kubernetes et j'ai récemment mis à jour mes certificats d'administration utilisés dans le kubeconfig
. Cependant, après avoir fait cela, toutes les commandes helm
échouent ainsi:
Error: Get https://cluster.mysite.com/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: x509: certificate signed by unknown authority
kubectl
fonctionne comme prévu:
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-1-0-34.eu-central-1.compute.internal Ready master 42d v1.7.10+coreos.0
ip-10-1-1-51.eu-central-1.compute.internal Ready master 42d v1.7.10+coreos.0
ip-10-1-10-120.eu-central-1.compute.internal Ready <none> 42d v1.7.10+coreos.0
ip-10-1-10-135.eu-central-1.compute.internal Ready <none> 27d v1.7.10+coreos.0
ip-10-1-11-71.eu-central-1.compute.internal Ready <none> 42d v1.7.10+coreos.0
ip-10-1-12-199.eu-central-1.compute.internal Ready <none> 8d v1.7.10+coreos.0
ip-10-1-2-110.eu-central-1.compute.internal Ready master 42d v1.7.10+coreos.0
D'après ce que j'ai pu lire, helm
est censé utiliser les mêmes certificats que kubectl
, ce qui me rend curieux de savoir comment kubectl
fonctionne, mais helm
non?
Il s'agit d'un cluster de production avec des versions internes gérées via des graphiques de barre, il est donc impératif de le résoudre.
Tout indice serait grandement apprécié.
Pour contourner ce problème, vous pouvez essayer de désactiver la vérification des certificats. Helm utilise le fichier de configuration kube (par défaut ~/.kube/config
). Vous pouvez ajouter insecure-skip-tls-verify: true
pour la section cluster
:
clusters:
- cluster:
server: https://cluster.mysite.com
insecure-skip-tls-verify: true
name: default
Avez-vous déjà essayé de réinstaller la barre/barre franche?
kubectl delete deployment tiller-deploy --namespace kube-system
helm init
Vérifiez également si vous avez configuré un certificat non valide dans la configuration du cluster.
Dans mon cas, l'erreur a été causée par un certificat non approuvé du référentiel Helm. Téléchargement du certificat et spécification à l'aide de --ca-file
a résolu le problème (au moins dans Helm version 3).
helm repo add --ca-file /path/to/certificate.crt repoName https://example/repository
--ca-file
chaîne, vérifiez les certificats des serveurs compatibles HTTPS à l'aide de cet ensemble CA
Bien que l'ajout d'un dépôt avec --ca-file ait fait l'affaire, quand il a essayé de télécharger à partir de ce dépôt avec la commande publiée sous, j'ai toujours obtenu le certificat x509: signé par une autorité inconnue
helm dependency update helm/myStuff
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "myRepo" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 18 charts
Downloading myService from repo https://myCharts.me/
Save error occurred: could not download https://myCharts.me/stuff.tgz ...
x509: certificate signed by unknown authority
Deleting newly downloaded charts, restoring pre-update state
Ce que je devais faire, en plus d'ajouter un dépôt avec --ca-file, c'était de télécharger le certificat de référentiel et de l'installer en tant qu'utilisateur actuel:
Placez tous les certificats dans le magasin suivant: Autorités de certification racines de confiance:
Après avoir installé le certificat, j'ai également dû redémarrer l'ordinateur. Après le redémarrage, lorsque vous ouvrez le navigateur et collez l'URL du référentiel, il doit se connecter sans donner d'avertissement ni faire confiance au site (de cette façon, vous savez que vous avez correctement installé le certificat).
Vous pouvez continuer et exécuter la commande, il devrait choisir le certificat cette fois.
helm dependency update helm/myStuff
....
Saving 18 charts
Downloading service1 from repo https://myCharts.me/
Downloading service2 from repo https://myCharts.me/
....