Kubernetes set image missing resource type 'de

Question

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"

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.

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

Any suggestions?

Answer 1

I've had this error fixed by explicitly setting the namespace as an argument, e.g.:

kubectl set image -n foonamespace deployment/ms-userservice.....

https://www.mankier.com/1/kubectl-set-image#--namespace

Answer 2

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

@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.

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.

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.

So, the tl;dr is two-fold:

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