Немає відповідностей для типу "Розгортання" у версіях "extensions / v1beta1

У мене виникли проблеми під час розгортання mojaloop .kubernetes відповідає на зразок журналу помилок

Я перевірив свою Kubernetes версію, і 1.16 - це версія, то як я можу виправити подібну проблему з версією API. З розслідування я виявив, що Kubernetes не підтримує програми / v1beta2, apps / v1beta1, тож як я можу зробити Kubernetes до використовувати наразі не застарілу версію або підтримувану версію. Я новачок у Kubernetes і кожен, хто може мене підтримати, я радий

Помилка: перевірка не вдалася: [не вдається розпізнати "": немає відповідностей для типу "Розгортання" у версії "apps / v1beta2", не вдається розпізнати "": немає відповідностей для типу "Розгортання" у версії "розширення / v1beta1", не вдається розпізнати "": немає відповідностей для роду "StatefulSet" у версії "apps / v1beta2", не вдається розпізнати "": немає відповідностей для виду "StatefulSet" у версії "apps / v1beta1"]

У Kubernetes 1.16 деякі зміни apiбули змінені.

Ви можете перевірити, який apis підтримує поточний об’єкт Kubernetes, використовуючи

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

Це означає, що для aploVersion appsправильним є лише для Deployments ( extensionsне підтримує Deployment). Така ж ситуація і з StatefulSet.

Вам просто потрібно змінити програму Deployment та StatefuSet apiVersion: apps/v1.

Якщо це не допомагає, будь-ласка, додайте YAML до питання.

EDIT Оскільки проблема викликана шаблонами HELM, включеними старими apiVersions в Deployments, які не підтримуються у версії 1.16, є 2 можливих рішення:

1. git clone Весь репо і замінити apiVersion на apps/v1у всіх шаблонах / deployment.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 fetch repo/chart

то у вашому робочому прямо запустіть скрипт bash нижче - який я назвав helmk

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

Зміст штурвала - потрібно відредагувати назву кластера 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

Якщо вам потрібно відредагувати YAML для налаштування - просто замініть один з / dev / stdin на проміжні файли, але, мабуть, краще отримати його за допомогою "create" з збереженням-config, як у мене, а потім просто "застосувати" ваші зміни а це означає, що вони також будуть записані в кубернетах. Удачі

простіше кажучи, ви не змушуєте поточну установку використовувати застарілу версію API, але ви просто виправите версію у своїх конфігураційних файлах, якщо ви хочете перевірити, яку версію ви підтримуєте в поточній кубі, просто запустіть:

root @ ubn64: ~ # kubectl api-версії | grep -i додатки

програми / v1

root @ ubn64: ~ #