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


27

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”]


1
Przepisz swoje pliki manifestów, aby używały obecnie obsługiwanego apis kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
zerkms

Jak mogę odtworzyć problem u może udostępnić mi krok
dan

Odpowiedzi:


56

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.


czy mogę obniżyć wersję Kubernet, ponieważ wszystkie pliki yaml dotyczące wdrażania dla mojaloop są kompatybilne z kuberntes w wersji 1.15, więc w jaki sposób mogę obniżyć wersję lub dokonując przejścia na niższą wersję, mogę uzyskać soln
dan

1
Sprawdziłem tę tabelę sterów mojaloop / mojaloop. Niestety, wszystkie szablony z wdrożeń mają apiVersions: extensions/v1beta1. Jednym z możliwych obejść jest git clonecałkowite repo i zastąpienie apiVersion apps/v1we wszystkich szablonach / wdrożeniu. Skrypt usinc. find . -name 'deployment.yaml' | xargs -n 1 perl -pi -e 's/(apps\/v1beta2)|(extensions\/v1beta1)/apps\/v1/g'.Drugim obejściem może być tylko użycie starszej wersji Kubernetes (1.15), gdy walidator zaakceptuje rozszerzenia jako apiVersion dla Deployent i StatefulSet.
PjoterS,

@dan używasz Minikubelub Kubeadm?
PjoterS,

kubeadm nie korzystałem z minikube
dan

czy możesz udostępnić mi kilka kroków do instalacji kubeadmn spec do wersji 1.15. Nie mogę znaleźć konkretnego zasobu, biorąc pod uwagę instalację kubeadmn 1.15
dan

4

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ę!


0

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


0

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: ~ #

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.