在版本“ extensions / v1beta1”中没有与“部署”类型匹配的项

27

我在部署mojaloop .kubernetes时遇到问题，并显示错误日志，例如

我已经检查了我的Kubernetes版本，而1.16是该版本，那么我该如何解决API版本的这种问题。从调查中发现Kubernetes不支持apps / v1beta2，apps / v1beta1，所以我如何使Kubernetes成为使用当前未弃用的版本或受支持的版本我是Kubernetes的新手，任何支持我的人我都很高兴

错误：验证失败：[无法识别“”：版本“ apps / v1beta2”中没有与类型“ Deployment”匹配，无法识别“”：版本“ extensions / v1beta1”中没有与类型“ Deployment”匹配，无法识别“”：版本“ apps / v1beta2”中没有匹配类型“ StatefulSet”，无法识别“”：版本“ apps / v1beta1”中没有匹配类型“ StatefulSet”]

kubernetes

— 担
source

1

重写清单文件以使用当前支持的api kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16

— zerkms

我该如何重现该问题？您能和我分享一些步骤

— 吗？

1

twitter.com/IanColdwater/status/1213607102595424258

— VAS

56

在Kubernetes 1.16中，有些api已更改。

您可以使用以下命令检查哪些api支持当前的Kubernetes对象

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

这意味着只有apiVersion具有才适用apps于Deployments（extensions不支持Deployment）。与StatefulSet相同的情况。

您只需要将Deployment和StatefuSet apiVersion更改为即可apiVersion: apps/v1。

如果这样做没有帮助，请将您的YAML添加到问题中。

编辑由于问题是由部署中包含旧apiVersions的HELM模板引起的，而版本1.16中不支持该版本，因此有2种可能的解决方案：

1. git clone整个回购和替换apiVersion到apps/v1的所有模板/ deployment.yaml使用脚本
2.使用旧版本的Kubernetes的（1.15）时，验证接受extensions的apiVersion用于Deployent和StatefulSet。

— PjoterS
source

我可以降级kubernettes吗，因为mojaloop的所有部署yaml文件都可以与kuberntes 1.15版兼容，所以我如何降级或通过降级可以得到一个soln呢

— 丹

1

我检查了这张mojaloop / mojaloop掌舵图。不幸的是，部署所有模板都apiVersions： extensions/v1beta1。作为可能的解决方法之一，是在git clone整个apps/v1模板/deployment.yaml usinc脚本中整体回购并替换apiVersion，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您使用的是Minikube还是Kubeadm？

— PjoterS

kubeadm我没有使用minikube

— 丹，

ü可以分享我的一些步骤来安装kubeadmn specfic到1.15版本的我找不到specfic资源考虑安装kubeadmn 1.15

— 丹

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}

请享用！

— 布鲁诺·韦戈
source

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之一替换为中间文件，但最好像我一样使用带有save-config的“ create”来启动它，然后简单地“应用”您的更改这意味着它们也将被记录在kubernetes中。祝好运

— 约翰·贝克
source

0

为简单起见，您不强制当前安装使用API的过时版本，但是如果要检查当前kube支持的版本，只需在配置文件中修复该版本，只需运行：

root @ ubn64：〜＃kubectl api版本| grep -i应用程序

应用/ v1

root @ ubn64：〜＃

— Shareef
source