no hay coincidencias para el tipo "Implementación" en la versión "extensiones / v1beta1

He estado teniendo el problema al implementar mojaloop .kubernetes responde con un registro de errores como

Verifiqué mi versión de Kubernetes y 1.16 es la versión, entonces, ¿cómo puedo solucionar este tipo de problema con la versión API? Después de investigar, descubrí que Kubernetes no es compatible con apps / v1beta2, apps / v1beta1, ¿cómo puedo hacer que Kubernetes funcione? uso la versión actualmente no desaprobada o la versión compatible Soy nuevo en Kubernetes y cualquier persona que pueda apoyarme estoy feliz

Error: error de validación: [no se puede reconocer "": no hay coincidencias para el tipo "Implementación" en la versión "apps / v1beta2", no se puede reconocer "": no hay coincidencias para el tipo "Implementación" en la versión "extensiones / v1beta1", no se puede reconocer "": no hay coincidencias para el tipo "StatefulSet" en la versión "apps / v1beta2", no se puede reconocer "": no hay coincidencias para el tipo "StatefulSet" en la versión "apps / v1beta1"]

En Kubernetes 1.16 apise han cambiado algunos s.

Puede verificar qué apis admiten el objeto Kubernetes actual usando

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

Esto significa que solo apiVersion with appses correcto para implementaciones ( extensionsno es compatible Deployment). La misma situación con StatefulSet.

Solo necesita cambiar la implementación de implementación y StatefuSet a apiVersion: apps/v1.

Si esto no ayuda, agregue su YAML a la pregunta.

EDITAR Como el problema es causado por las plantillas HELM incluidas las apiVersiones antiguas en las implementaciones que no son compatibles con la versión 1.16, hay 2 posibles soluciones:

1. git clone repositorio completo y reemplazar apiVersion apps/v1en todas las plantillas / despliegue.yaml usando el script
2. Use la versión anterior de Kubernetes (1.15) cuando el validador acepte extensionscomo apiVersionpara Deployenty StatefulSet.

Puede cambiar manualmente como alternativa. Obtener el gráfico del timón:

helm fetch --untar stable/metabase

Acceda a la carpeta del gráfico:

cd ./metabase

Cambiar versión de API:

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

Añadir spec.selector.matchLabels:

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

Finalmente instale su gráfico alterado:

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

¡Disfrutar!

Esto me molestó porque estoy probando muchos paquetes de timón, así que escribí un script rápido, que podría modificarse para ordenar su flujo de trabajo, tal vez vea a continuación

Nuevo flujo de trabajo Primero busque el gráfico como tgz en su directorio de trabajo

helm fetch repo/chart

luego, en su trabajo, ejecute directamente el script bash a continuación, que denominé helmk

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

Contenido de helmk: necesita editar su nombre de clúster kubeconfig para que funcione

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

Es un truco un poco peligroso, ya que cambio manualmente a su nuevo contexto de espacio de nombres deseado y luego lo vuelvo a usar, solo para ser utilizado por desarrolladores de un solo usuario o comentarlo.

Recibirá una advertencia sobre el uso de la función de conversión de kubectl como esta

Si necesita editar el YAML para personalizarlo, simplemente reemplace uno de los archivos / dev / stdin a intermedios, pero probablemente sea mejor hacerlo usando "crear" con una configuración de guardar como lo he hecho y luego simplemente "aplicar" sus cambios lo que significa que también se grabarán en kubernetes. Buena suerte

Para simplificarlo, no obliga a la instalación actual a usar una versión desactualizada de la API, sino que simplemente arregla la versión en sus archivos de configuración si desea verificar qué versión admite kube actual, simplemente ejecute:

root @ ubn64: ~ # kubectl versiones api | grep -i apps

aplicaciones / v1

root @ ubn64: ~ #