нет совпадений для вида «Развертывание» в версии «extensions / v1beta1»

У меня возникла проблема при развертывании mojaloop .kubernetes отвечает с журналом ошибок, как

Я проверил свою версию Kubernetes, и 1.16 - это версия, так как я могу решить такую ​​проблему с версией API. Из исследования я обнаружил, что Kubernetes не поддерживает apps / v1beta2, apps / v1beta1, так как я могу заставить Kubernetes используйте текущую не поддерживаемую версию или поддерживаемую версию. Я новичок в Kubernetes и все, кто может меня поддержать, я счастлив

Ошибка: проверка не удалась: [невозможно распознать "": нет совпадений для вида "Deployment" в версии "apps / v1beta2", невозможно распознать "": нет совпадений для вида "Deployment" в версии "extensions / v1beta1", невозможно распознать "": нет совпадений для вида "StatefulSet" в версии "apps / v1beta2", невозможно распознать "": нет совпадений для вида "StatefulSet" в версии "apps / v1beta1"]

В Kubernetes 1.16 некоторые apis были изменены.

Вы можете проверить, какие API поддерживают текущий объект Kubernetes, используя

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

Это означает, что только apiVersion с appsверным для развертываний ( extensionsне поддерживает Deployment). Та же ситуация с StatefulSet.

Вам просто нужно изменить Deployment и StatefuSet apiVersion на apiVersion: apps/v1.

Если это не помогает, пожалуйста, добавьте свой YAML к вопросу.

РЕДАКТИРОВАТЬ Так как проблема вызвана тем, что шаблоны HELM включали старые apiVersions в Deployments, которые не поддерживаются в версии 1.16, есть 2 возможных решения:

1. git clone Полное репозиторий и замена apiVersion apps/v1во всех шаблонах / deploy.yaml с использованием скрипта
2. Используйте старую версию Kubernetes (1.15), когда валидатор принимает extensionsкак apiVersionдля Deployentи StatefulSet.

Вы можете изменить вручную в качестве альтернативы. Получить таблицу управления:

helm fetch --untar stable/metabase

Откройте папку с диаграммой:

cd ./metabase

Изменить версию API:

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

Добавить spec.selector.matchLabels:

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

Наконец, установите ваш измененный график:

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

Наслаждайтесь!

Это меня раздражало, потому что я тестирую множество пакетов helm, поэтому я написал быстрый скрипт - который можно изменить, чтобы отсортировать ваш рабочий процесс, возможно, см. Ниже

Новый рабочий процесс Сначала загрузите диаграмму в виде tgz в ваш рабочий каталог

helm fetch repo/chart

тогда в вашей работе напрямую запустите скрипт bash, который я назвал helmk

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

Содержимое helmk - необходимо отредактировать ваше имя кластера 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

Это немного опасный хак, поскольку я вручную переключаюсь на ваш новый требуемый контекст пространства имен, а затем снова обратно, так что его можно использовать только для однопользовательских разработчиков или комментировать.

Вы получите предупреждение об использовании kubectl convert, подобного этому

Если вам нужно отредактировать YAML для настройки - просто замените один из / dev / stdin на промежуточные файлы, но, вероятно, лучше установить его, используя "create" с сохранением конфигурации, как я, а затем просто "применить" ваши изменения это означает, что они будут записаны также в kubernetes. Удачи

Проще говоря, вы не заставляете текущую установку использовать устаревшую версию API, но вы просто исправляете версию в своих конфигурационных файлах, если хотите проверить, какую версию поддерживает текущая версия kube, просто запустите:

root @ ubn64: ~ # kubectl api-версии | grep -i apps

Приложения / v1

корень @ ubn64: ~ #