J'ai eu le problème lors du déploiement de mojaloop .kubernetes répond avec un journal des erreurs comme
J'ai vérifié ma version de Kubernetes et 1.16 est la version, alors comment puis-je résoudre ce type de problème avec la version de l'API. utiliser la version actuellement non obsolète ou la version prise en charge Je suis nouveau sur Kubernetes et tous ceux qui peuvent me soutenir, je suis heureux
Erreur: échec de la validation: [impossible de reconnaître "": aucune correspondance pour le type "Déploiement" dans la version "apps/v1beta2", impossible de reconnaître "": aucune correspondance pour le type "Déploiement" dans la version "extensions/v1beta1", impossible de reconnaître "": aucune correspondance pour le type "StatefulSet" dans la version "apps/v1beta2", impossible de reconnaître "": aucune correspondance pour le type "StatefulSet" dans la version "apps/v1beta1"]
Dans Kubernetes 1.16, certains api
ont été modifiés.
Vous pouvez vérifier quels API prennent en charge l'objet Kubernetes actuel à l'aide de
$ kubectl api-resources | grep deployment
deployments deploy apps true Deployment
Cela signifie que seule apiVersion avec apps
est correcte pour les déploiements (extensions
ne prend pas en charge Deployment
). La même situation avec StatefulSet.
Il vous suffit de remplacer Déploiement et ApiVersion StatefuSet par apiVersion: apps/v1
.
Si cela n'aide pas, veuillez ajouter votre YAML à la question.
EDIT Comme le problème est causé par les modèles HELM inclus dans les anciennes versions des déploiements qui ne sont pas prises en charge dans la version 1.16, il existe 2 solutions possibles:
1.git clone
repo entier et remplacez apiVersion par apps/v1
dans tous les modèles/deployment.yaml à l'aide d'un script
2. Utilisez une ancienne version de Kubernetes (1.15) lorsque le validateur accepte extensions
comme apiVersion
pour Deployent
et StatefulSet
.
Vous pouvez changer manuellement comme alternative. Récupérez le graphique de barre:
helm fetch --untar stable/metabase
Accédez au dossier du graphique:
cd ./metabase
Changer la version de l'API:
sed -i 's|extensions/v1beta1|apps/v1|g' ./templates/deployment.yaml
Ajouter spec.selector.matchLabels
:
spec:
[...]
selector:
matchLabels:
app: {{ template "metabase.name" . }}
[...]
Enfin, installez votre graphique modifié:
helm install ./ \
-n metabase \
--namespace metabase \
--set ingress.enabled=true \
--set ingress.hosts={metabase.$(minikube ip).nip.io}
Prendre plaisir!
Cela m'ennuyait parce que je teste beaucoup de packages de barre, j'ai donc écrit un script rapide - qui pourrait être modifié pour trier votre flux de travail, voir ci-dessous
Nouveau workflow Récupérez d'abord le graphique en tant que tgz dans votre répertoire de travail
helm fetch repo/chart
puis dans votre travail exécutez directement le script bash ci-dessous - que j'ai nommé helmk
helmk myreleasename mynamespace chart.tgz [any parameters for kubectl create]
Contenu de helmk - besoin de modifier votre nom de cluster kubeconfig pour qu'il fonctionne
#!/bin/bash
echo usage $0 releasename namespace chart.tgz [createparameter1] [createparameter2] ... [createparameter n]
echo This will use your namespace then shift back to default so be careful!!
kubectl create namespace $2 #this will create harmless error if namespace exists have to ignore
kubectl config set-context MYCLUSTERNAME --namespace $2
helm template -n $1 --namespace $2 $3 | kubectl convert -f /dev/stdin | kubectl create --save-config=true ${@:4} -f /dev/stdin
#note the --namespace parameter in helm template above seems to be ignored so we have to manually switch context
kubectl config set-context MYCLUSTERNAME --namespace default
C'est un piratage légèrement dangereux car je passe manuellement au nouveau contexte d'espace de noms souhaité, puis à nouveau, donc uniquement pour les développeurs mono-utilisateur ou pour le commenter.
Vous recevrez un avertissement concernant l'utilisation de la fonction de conversion de kubectl comme celle-ci
Si vous avez besoin d'éditer le YAML pour le personnaliser - remplacez simplement l'un des fichiers/dev/stdin par des fichiers intermédiaires, mais il est probablement préférable de le faire en utilisant "create" avec une sauvegarde-config comme je l'ai et puis simplement "appliquez" vos changements ce qui signifie qu'ils seront également enregistrés dans kubernetes. Bonne chance
pour faire simple, vous ne forcez pas l'installation actuelle à utiliser une version obsolète de l'API, mais vous fixez simplement la version dans vos fichiers de configuration si vous voulez vérifier la version prise en charge par le kube actuel, exécutez simplement:
root @ ubn64: ~ # kubectl api-versions | applications grep -i
apps/v1
root @ ubn64: ~ #