pas de correspondance pour le type "Déploiement" dans la version "extensions / v1beta1

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 apis 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 seul apiVersion with appsest correct pour les déploiements ( extensionsne 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 dû aux modèles HELM inclus dans les anciennes versions des déploiements qui ne sont pas pris en charge dans la version 1.16, il existe 2 solutions possibles:

1. git clone repo entier et remplacer apiVersion apps/v1dans tous les templates / deployment.yaml en utilisant le script
2. Utilisez une ancienne version de Kubernetes (1.15) lorsque le validateur accepte extensionscomme apiVersionpour Deployentet 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 le nom de votre 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 hack légèrement dangereux car je passe manuellement au nouveau contexte d'espace de noms souhaité, puis à nouveau, donc uniquement pour être utilisé par des 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: ~ #