Kubernetes将图像设置为缺少资源类型'deployment' [英] Kubernetes set image missing resource type 'deployment'

问题描述

我正在尝试使用以下命令更新Kubernetes中的图像:

I'm trying to update an image in Kubernetes by using the following command:

kubectl set image deployment/ms-userservice ms-userservice=$DOCKER_REGISTRY_NAME/$BITBUCKET_REPO_SLUG:$BITBUCKET_COMMIT --insecure-skip-tls-verify

但是当我收到以下错误消息时:

But when I receive the following error:

error: the server doesn't have a resource type "deployment"

我检查了我是否在正确的命名空间中，并且名称相同的pod已存在并且正在运行.

I have checked that i am in the right namespace, and that the pod with the name exists and is running.

关于此错误，我找不到任何有意义的资源.

I can't find any meaningful resources in regards to this error.

旁注:我正在通过Bitbucket和管道进行此操作，该管道还会生成我要使用的图像.

Sidenote: I'm doing this through Bitbucket and a pipeline, which also builds the image i want to use.

有什么建议吗?

推荐答案

我怀疑它与用户有关-错误消息没有太多帮助.

I have a suspicion that it has something to do with user - not much help from the error message.

@TietjeDK是正确的，它只是一个误导性的错误消息.这表示正在发生两种情况之一(或可能同时发生):kubectl二进制文件比集群支持的版本范围新(例如:对v1.8集群使用v1.11二进制文件)或如果JWT签名不正确.

@TietjeDK is correct that it is just a misleading error message. It means one of two things is happening (or maybe both): the kubectl binary is newer than the supported version range of the cluster (so: using a v1.11 binary against a v1.8 cluster, for example) or the provided JWT is incorrectly signed.

您应该非常小心地使用--insecure-skip-tls-verify，这不仅是因为它的安全卫生状况很差，而且还因为如果kubeconfig不正确(在这种情况下很可能是这样)，那么看到x509错误比显示更清楚尝试对无效的JWT进行故障排除.

You should be very very careful with --insecure-skip-tls-verify not only because it's bad security hygiene but also because if a kubeconfig is incorrect -- as is very likely the case here -- then seeing the x509 error is a much clearer indication than trying to troubleshoot an invalid JWT.

让我相信它实际上是令牌的签名而不是其内容的指标是，如果是令牌的内容，您将看到RBAC消息User "[e-mail]" cannot list deployments in $namespace namespace，这意味着apiserver确实将JWT拆包并找到了它断言不足以进行此操作.但是，如果您使用随机密钥对JWT进行签名，则JWT不会解压缩，因为它将导致公钥验证失败并被彻底拒绝.

The indicator that makes me believe it is actually the signature of the token, and not its contents, is that if it were the contents you would seen an RBAC message User "[e-mail]" cannot list deployments in $namespace namespace, meaning the apiserver did unpack the JWT and found its assertions were insufficient for the operation. But if you sign a JWT using a random key, the JWT will not unpack since it will fail public key validation and be rejected outright.

因此，tl; dr有两个:

So, the tl;dr is two-fold:

1. 将kubeconfig修复为实际上包含集群的正确证书颁发机构(CA)，因此不需要--insecure-skip-tls-verify
2. 在修复kubeconfig时，为(User | ServiceAccount)发出一个新令牌，该令牌来自旨在与之交互的群集

1. fix the kubeconfig to actually contain the correct certificate authority (CA) for the cluster, so --insecure-skip-tls-verify isn't required
2. while fixing kubeconfig, issue a new token for the (User | ServiceAccount) that comes from the cluster it is designed to interact with

这篇关于Kubernetes将图像设置为缺少资源类型'deployment'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！