brak pasujących do rodzaju „Deployment” w wersji „extensions / v1beta1

Wystąpił problem podczas wdrażania programu mojaloop .kubernetes odpowiada dziennikiem błędów podobnym do tego

Sprawdziłem moją wersję Kubernetes i 1.16 jest wersją, więc jak mogę rozwiązać tego rodzaju problem z wersją API. Z dochodzenia odkryłem, że Kubernetes nie obsługuje aplikacji / v1beta2, apps / v1beta1, więc jak mogę sprawić, by Kubernetes używaj aktualnie nieaktualnej wersji lub obsługiwanej wersji Jestem nowy w Kubernetes i każdy, kto może mnie wspierać, jestem szczęśliwy

Błąd: sprawdzanie poprawności nie powiodło się: [nie można rozpoznać „”: brak wyników dla rodzaju „Wdrożenie” w wersji „apps / v1beta2”, nie można rozpoznać „”: brak wyników dla rodzaju „Wdrażanie” w wersji „rozszerzenia / v1beta1”, nie można rozpoznać „”: brak dopasowań dla rodzaju „StatefulSet” w wersji „apps / v1beta2”, nie można rozpoznać „”: brak dopasowań dla rodzaju „StatefulSet” w wersji „apps / v1beta1”]

W Kubernetes 1.16 niektóre apis zostały zmienione.

Możesz sprawdzić, które api obsługują bieżący obiekt Kubernetes za pomocą

$ kubectl api-resources | grep deployment
deployments                       deploy       apps                           true         Deployment

Oznacza to, że tylko apiVersion z appsjest poprawny dla wdrożeń ( extensionsnie obsługuje Deployment). Ta sama sytuacja z StatefulSet.

Musisz tylko zmienić Deployment i StatefuSet apiVersion na apiVersion: apps/v1.

Jeśli to nie pomoże, dodaj swój YAML do pytania.

EDYCJA Ponieważ problem jest spowodowany przez szablony HELM uwzględniające stare apiVersions we wdrożeniach, które nie są obsługiwane w wersji 1.16, istnieją 2 możliwe rozwiązania:

1. git clone Całe repozytorium i zamień apiVersion na apps/v1we wszystkich templates /loyment.yaml za pomocą skryptu
2. Użyj starszej wersji Kubernetes (1.15), gdy walidator zaakceptuje extensionsjak apiVersiondla Deployenti StatefulSet.

Możesz zmienić ręcznie jako alternatywę. Pobierz tabelę sterów:

helm fetch --untar stable/metabase

Uzyskaj dostęp do folderu wykresu:

cd ./metabase

Zmień wersję interfejsu API:

sed -i 's|extensions/v1beta1|apps/v1|g' ./templates/deployment.yaml

Dodaj spec.selector.matchLabels:

spec:
[...]
selector:
    matchLabels:
    app: {{ template "metabase.name" . }}
[...]

Na koniec zainstaluj zmieniony wykres:

helm install ./ \
  -n metabase \
  --namespace metabase \
  --set ingress.enabled=true \
  --set ingress.hosts={metabase.$(minikube ip).nip.io}

Cieszyć się!

To mnie denerwowało, ponieważ testuję wiele pakietów sterów, więc napisałem szybki skrypt - który można zmodyfikować w celu uporządkowania przepływu pracy, być może patrz poniżej

Nowy przepływ pracy Najpierw pobierz wykres jako tgz do katalogu roboczego

helm fetch repo/chart

następnie w swoim działaniu uruchom bezpośrednio poniżej skrypt bash - który nazwałem helmk

helmk myreleasename mynamespace chart.tgz [any parameters for kubectl create]

Zawartość helmk - musisz edytować nazwę klastra kubeconfig, aby działać

#!/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

Jest to nieco niebezpieczny hack, ponieważ ręcznie przełączam się do nowego pożądanego kontekstu przestrzeni nazw, a następnie z powrotem, więc tak naprawdę można go używać tylko dla deweloperów pojedynczego użytkownika lub komentować.

Otrzymasz ostrzeżenie o używaniu funkcji konwersji kubectl w ten sposób

Jeśli chcesz zmodyfikować YAML, aby dostosować - po prostu zamień jeden z plików / dev / stdin na pliki pośrednie, ale prawdopodobnie lepiej jest go uruchomić za pomocą „create” z zapisz-config tak jak ja, a następnie po prostu „zastosuj” swoje zmiany co oznacza, że ​​zostaną one również zapisane w kubernetes. Powodzenia

mówiąc najprościej, nie zmuszaj bieżącej instalacji do używania przestarzałej wersji interfejsu API, ale po prostu naprawiasz wersję w plikach konfiguracyjnych, jeśli chcesz sprawdzić, którą wersję obsługuje obecnie kube, po prostu uruchom:

root @ ubn64: ~ # wersje kubectl api-wersje | aplikacje grep -i

apps / v1

root @ ubn64: ~ #