Question

在部署mojaloop .kubernetes时出现问题，例如错误日志

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

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

Answer 1

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

您可以使用

检查哪些api支持当前的Kubernetes对象

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

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

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

如果没有帮助，请在问题中添加您的YAML。

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

1。。git clone整个存储库，并使用脚本
在所有template / deployment.yaml中将apiVersion替换为apps/v1。 2。。当验证器接受extensions和apiVersion的{{1}}作为Deployent时，请使用Kubernetes的旧版本（1.15）。

Answer 2

要将旧的Deployment转换为apps / v1，可以运行：

kubectl convert -f ./my-deployment.yaml --output-version apps/v1

Answer 3

我更喜欢kubectl explain。

# kubectl explain deploy
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object metadata.

   spec <Object>
     Specification of the desired behavior of the Deployment.

   status       <Object>
     Most recently observed status of the Deployment.

Answer 4

简而言之，您不强制当前的安装使用API的过时版本；您可以在配置文件中修复版本。如果要检查当前kube支持的版本，请运行：

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

apps/v1

Answer 5

您也可以手动更改。获取舵图：

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}

享受！

Answer 6

我遇到了以下错误 -
错误：无法识别“deployment.yaml”：版本“extensions/v1beta1”中的“Deployment”种类没有匹配

对我有用的解决方案 -

将 deployment.yaml 中的 apiVersion: extensions/v1beta1 修改为 apiVersion: apps/v1

原因—— 我们已经升级了 K8 集群，因此出现了这个错误。

Answer 7

这让我很烦，因为我正在测试许多头盔包，所以我写了一个快速脚本-可以对其进行修改以对您的工作流程进行排序见下文

新的工作流程首先以图表形式将图表获取到您的工作目录

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的“创建”来启动它，然后简单地“应用”即可您的更改，这意味着它们也将记录在kubernetes中。祝你好运

Answer 8

我在升级到不支持某些 api 版本（v1.17 和 apps/v1beta2）的版本的集群上遇到了同样的问题。

$ helm get manifest some-deployment
...
# Source: some-deployment/templates/deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: some-deployment
  labels:
...

查看 helm 文档，manifest 似乎存储在集群中供 helm 引用，并且可能包含无效的 api 版本，导致错误。

这两个 proposed methods 要么手动编辑清单（一个相当乏味的多阶段过程），要么使用名为 mapkubeapis 的 helm 插件自动完成。

$ helm plugin install https://github.com/hickeyma/helm-mapkubeapis

它可以与 --dry-run 标志一起运行以模拟效果：

$ helm mapkubeapis --dry-run some-deployment
2021/02/15 09:33:29 NOTE: This is in dry-run mode, the following actions will not be executed.
2021/02/15 09:33:29 Run without --dry-run to take the actions described below:
2021/02/15 09:33:29
2021/02/15 09:33:29 Release 'some-deployment' will be checked for deprecated or removed Kubernetes APIs and will be updated if necessary to supported API versions.
2021/02/15 09:33:29 Get release 'some-deployment' latest version.
2021/02/15 09:33:30 Check release 'some-deployment' for deprecated or removed APIs...
2021/02/15 09:33:30 Found deprecated or removed Kubernetes API:
"apiVersion: apps/v1beta2
kind: Deployment"
Supported API equivalent:
"apiVersion: apps/v1
kind: Deployment"
2021/02/15 09:33:30 Finished checking release 'some-deployment' for deprecated or removed APIs.
2021/02/15 09:33:30 Deprecated or removed APIs exist, updating release: some-deployment.
2021/02/15 09:33:30 Map of release 'some-deployment' deprecated or removed APIs to supported versions, completed successfully.

然后在没有标志的情况下运行以应用更改。

版本“ extensions / v1beta1

8 个答案: