バージョン「extensions / v1beta1」の種類「Deployment」に一致するものはありません


27

mojaloop .kubernetesのデプロイ中に問題が発生しました。次のようなエラーログが返されます。

Kubernetesのバージョンを確認したところ、1.16のバージョンなので、APIバージョンのこのような問題をどのように修正できますか?調査の結果、Kubernetesがapps / v1beta2、apps / v1beta1をサポートしていないことがわかりました。現在サポートが終了していないバージョンまたはサポートされているバージョンを使用する私はKubernetesを初めて使用し、サポートしてくれる人なら誰でも幸せです

エラー:検証に失敗しました:["を認識できません:バージョン" apps / v1beta2 "の種類" Deployment "に一致しません。" "を認識できません:バージョン" extensions / v1beta1 "の種類" Deployment "に一致しません。 ""を認識:バージョン "apps / v1beta2"で種類 "StatefulSet"との一致なし、 ""を認識できません:バージョン "apps / v1beta1"で種類 "StatefulSet"との一致なし]


1
現在サポートされているAPI
zerkms

どうすれば問題を再現できますか?いくつかのステップを共有できます
dan

回答:


56

Kubernetes 1.16では、一部apiのが変更されています。

現在のKubernetesオブジェクトをサポートするAPIを確認するには、

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

つまり、appsDeploymentにはapiVersionのみが適切です(extensionsはサポートしていませんDeployment)。StatefulSetと同じ状況。

DeploymentとStatefuSet apiVersionをに変更するだけですapiVersion: apps/v1

これで問題が解決しない場合は、YAMLを質問に追加してください。

編集 問題は、バージョン1.16でサポートされていないDeploymentに古いapiVersionが含まれているHELMテンプレートが原因で発生するため、2つの解決策があります。

1. git clone全体のレポとにapiVersionを置き換えるapps/v1スクリプト使用して、すべてのテンプレート/ deployment.yamlで
2バリ受け入れる際に使用して、Kubernetesの古いバージョン(1.15)extensionsとしてapiVersionのためDeployentStatefulSet


mojaloopのすべてのデプロイyamlファイルはkuberntesバージョン1.15と互換性があるため、kubernettesをダウングレードできますか。ダウングレードする方法、またはダウングレードしてソルンを取得するには
dan

1
このmojaloop / mojaloopヘルムチャートを確認しました。残念ながら、デプロイメントを含むすべてのテンプレートにはapiVersions:がありextensions/v1beta1ます。考えられる回避策の1つは、git cloneリポジトリ全体を作成しapps/v1、apiVersionをすべてのtemplates / deployment.yaml usincスクリプトで 置き換えることです。2 find . -name 'deployment.yaml' | xargs -n 1 perl -pi -e 's/(apps\/v1beta2)|(extensions\/v1beta1)/apps\/v1/g'.番目の回避策は、バリデーターがDeployentおよびStatefulSetのapiVersionとして拡張機能を受け入れる場合、古いバージョンのKubernetes(1.15)を使用するだけです。
PjoterS

@danは使用していますMinikubeKubeadm
PjoterS

kubeadm私はminikubeを使用しませんでした
dan

バージョン1.15に固有のkubeadmnのインストールに関するいくつかの手順を教えてください。kubeadmn1.15のインストールを検討している特定のリソースが見つかりません
dan

4

別の方法として、手動で変更できます。ヘルムチャートを取得します。

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}

楽しい!


0

多くのヘルムパッケージをテストしているので、これは私を困らせていました。簡単なスクリプトを作成しました。これを変更して、ワークフローをソートすることができます。

新しいワークフローまず、グラフを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変換機能の使用に関する警告が表示されます

カスタマイズするためにYAMLを編集する必要がある場合-/ dev / stdinの1つを中間ファイルに置き換えるだけですが、私が持っているように、save-configで「create」を使用してそれを取得し、変更を「適用」するだけの方が良いでしょう。つまり、kubernetesにも記録されます。幸運を


0

簡単に言うと、現在のインストールで古いバージョンのAPIを使用する必要はありませんが、現在のkubeがサポートしているバージョンを確認するには、設定ファイルでバージョンを修正するだけです。

root @ ubn64:〜#kubectl api-versions | grep -iアプリ

アプリ/ v1

root @ ubn64:〜#

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.