kubectl apply --validate=true --dry-run=client requires connection to Kubernetes cluster

[yannh]

Note: Not sure if Bug, Enhancement request or Support request.

What happened:

What you expected to happen:

Trying to validate a Kubernetes manifest using client-side schema validation requires a connection to a Kubernetes cluster:

$ kubectl config use-context none
Switched to context "none".
$ kubectl apply --validate=true --dry-run=client -f nginx-service.yml
The connection to the server localhost:8080 was refused - did you specify the right host or port?

My understanding, according to the man page, is that --validate will perform validation of the manifests using schemas, and that --dry-run=client will not send the manifests to the server: "If client strategy, only print the object that would be
sent, without sending it.".

Shouldn't this be a local-only operation? Currently this connection requirement makes it hard to validate files as part of a CI system. Is it trying to get the Kubernetes' cluster version to select the right schemas?

Thanks!

Anything else we need to know?:

Environment:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:59:43Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?

[k8s-ci-robot]

@yannh: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ralsu091]

In our CI pipeline we used to be able to run kubectl create secret generic -n namespace mysecret --from-literal=key=secret -oyaml --dry-run=client

This now fails with kubectl 1.19 with:

error: Missing or incomplete configuration info.  Please point to an existing, complete config file:


  1. Via the command-line flag --kubeconfig
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

Was this a recent change?

[eddiezane]

@apelisse any thoughts here?

[apelisse]

"If client strategy, only print the object that would be
sent, without sending it."

That applies to the apply part, not to the validation part unfortunately.
We need to get the OpenAPI/type information from somewhere to validate.

The typical solution for CI is to download a copy of the OpenAPI somewhere and use kubeval
to validate the manifests.

I don't know if there is anything we can do here beyond clarifying the documentation.

[seans3]

The validation schema may not be downloaded from the cluster. So a connection may be needed to download this schema so validation can proceed. In order for this to happen exclusively locally, we have to be able to know for sure the schema has already been downloaded.

[apelisse]

error: Missing or incomplete configuration info.  Please point to an existing, complete config file:


  1. Via the command-line flag --kubeconfig
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

This is odd and sounds like a bug, aren't we supposed to use a default "localhost:8080" when no config is specified?

[yannh]

@apelisse I understand, it was not clear to me that kubectl was downloading the OpenAPI Schema from the cluster for validation. I maintain kubeconform, a kubeval-like validator, which is why I am interested in kubectl validation capabilities.

Kubeval requires to convert the OpenAPI spec into JSONSchemas first - it would be interesting if that step could be skipped, since it requires regular maintenance (see https://github.com/instrumenta/kubernetes-json-schema , on which kubeval depends). I have opened this related ticket recently to try to understand how kubectl does validation and whether kubeval/kubeconform could be simplified to not require this JSONSchema conversion: kubernetes/kube-openapi#219 .

As far as I am concerned we can close this ticket! Thanks a lot.

[seans3]

@ralsu091 The issue you are describing is different than the initial issue. Please open a different issue to address your concern.

/close

[k8s-ci-robot]

@seans3: Closing this issue.

In response to this:

@ralsu091 The issue you are describing is different than the initial issue. Please open a different issue to address your concern.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.