nessuna corrispondenza per il tipo "Distribuzione" nella versione "extensions / v1beta1

Ho riscontrato il problema durante la distribuzione di mojaloop .kubernetes risponde con un registro degli errori simile

Ho verificato la mia versione di Kubernetes e 1.16 è la versione, quindi come posso risolvere questo tipo di problema con la versione dell'API. Dall'inchiesta Ho scoperto che Kubernetes non supporta app / v1beta2, apps / v1beta1, quindi come posso fare per Kubernetes utilizzare la versione attualmente non deprecata o la versione supportata Sono nuovo su Kubernetes e chiunque sia in grado di supportarmi sono contento

Errore: convalida non riuscita: [impossibile riconoscere "": nessuna corrispondenza per il tipo "Distribuzione" nella versione "app / v1beta2", impossibile riconoscere "": nessuna corrispondenza per il tipo "Distribuzione" nella versione "estensioni / v1beta1", impossibile per riconoscere "": nessuna corrispondenza per il tipo "StatefulSet" nella versione "apps / v1beta2", impossibile riconoscere "": nessuna corrispondenza per il tipo "StatefulSet" nella versione "apps / v1beta1"]

In Kubernetes 1.16 alcuni apis sono stati cambiati.

Puoi controllare quali API supportano l'oggetto Kubernetes corrente usando

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

Ciò significa che solo apiVersion con appsè corretto per le distribuzioni ( extensionsnon supporta Deployment). La stessa situazione con StatefulSet.

È sufficiente modificare Deployment e StatefuSet apiVersion in apiVersion: apps/v1.

Se questo non aiuta, aggiungi il tuo YAML alla domanda.

MODIFICA Poiché il problema è causato dai modelli HELM inclusi apiVersions precedenti nelle distribuzioni che non sono supportati nella versione 1.16, ci sono 2 possibili soluzioni:

1. git clone intero repository e sostituisci apiVersion in apps/v1in tutti i template / deployment.yaml usando lo script
2. Usa la versione precedente di Kubernetes (1.15) quando il validatore accetta extensionscome apiVersionper Deployente StatefulSet.

Puoi cambiare manualmente come alternativa. Scarica la mappa del timone:

helm fetch --untar stable/metabase

Accedi alla cartella dei grafici:

cd ./metabase

Cambia versione API:

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

Aggiungi spec.selector.matchLabels:

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

Finalmente installa il tuo grafico alterato:

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

Godere!

Questo mi ha infastidito perché sto testando molti pacchetti helm, quindi ho scritto uno script veloce - che potrebbe essere modificato per ordinare il tuo flusso di lavoro, forse vedi sotto

Nuovo flusso di lavoro Per prima cosa recupera il grafico come tgz nella directory di lavoro

helm fetch repo/chart

poi nel tuo lavoro esegui direttamente lo script bash di seguito - che ho chiamato helmk

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

Contenuti di helmk - per poter funzionare è necessario modificare il proprio clustername kubeconfig

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

È un trucco leggermente pericoloso poiché passo manualmente al nuovo contesto dello spazio dei nomi desiderato, quindi di nuovo in modo da essere utilizzato solo per gli sviluppatori di singoli utenti o commentarlo.

Riceverai un avviso sull'utilizzo della funzione di conversione di kubectl in questo modo

Se è necessario modificare lo YAML per personalizzare, basta sostituire uno dei file / dev / stdin in file intermedi, ma è probabilmente meglio alzarlo usando "create" con un save-config come ho fatto e quindi semplicemente "applicare" le modifiche il che significa che saranno registrati anche in kubernetes. In bocca al lupo

per dirla in modo semplice, non forzare l'installazione corrente a utilizzare una versione obsoleta dell'API, ma semplicemente aggiusti la versione nei tuoi file di configurazione se vuoi controllare quale versione supporta l'attuale kube, esegui semplicemente:

root @ ubn64: ~ # kubectl api-version | grep -i app

apps / v1

root @ ubn64: ~ #