kubernetes: don't require API server connection for `kubectl create configmap ... --dry-run`

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature

What happened:

kubectl create configmap my-cmap --from-file=file.txt --dry-run --output=yaml > my-cmap.yaml
Unable to connect to the server: dial tcp: lookup REDACDTED on REDACTED: no such host

What you expected to happen: Ideally, I expect that no connection to the Kubernetes API server should be needed to create a ConfigMap with --dry-run.

How to reproduce it (as minimally and precisely as possible): Run the above command with no connection to a Kubernetes cluster.

Anything else we need to know?: https://github.com/kubernetes/kubernetes/issues/11488 is a related issue that mentions that we need to decide if --dry-run should or should not require server-side connection. In this case for running --dry-run to create and save YAMLs, we should not need API server connection. It seems like an API server connection should only be needed if both --dry-run and --validate are used to validate the manifest against the API server and not apply the manifest.

Environment:

  • Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.2", GitCommit:"477efc3cbe6a7effca06bd1452fa356e2201e1ee", GitTreeState:"clean", BuildDate:"2017-04-19T20:33:11Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
  • Cloud provider or hardware configuration**: n/a
  • OS (e.g. from /etc/os-release): n/a
  • Kernel (e.g. uname -a): n/a
  • Install tools: n/a
  • Others: n/a

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 27
  • Comments: 76 (30 by maintainers)

Most upvoted comments

/remove-lifecycle stale

so I have another use case for running without a connection to a cluster and that is validating yaml files that have been generated through templating in a CI pipeline without needing to configure that pipeline to connect to any cluster it may/may not have access to

@apelisse - any chance we can re-open this issue? Given we now have kubectl apply --dry-run=client and kubectl apply --dry-run=server with v1.18, it seems sensible that the client option does not require kubectl to be authenticated and connected to the apiserver.

For context of our use case: we’re using this to do some validation and JSON rendering of manifests in an automated pipeline that should not have access to the actual Kubernetes cluster.

Sounds reasonable to me. /reopen

Seems like we want the --local flag. On Mon, Oct 23, 2017 at 1:57 PM Guilhem Lettron notifications@github.com wrote:

We have same problem here with kubectl create secret generic. Even if we specify --dry-run=true --validate=false, command fail with Unable to connect to the server.

We only want to some files without having to configure a running cluster.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/kubernetes/issues/51475#issuecomment-338743815, or mute the thread https://github.com/notifications/unsubscribe-auth/ABmslkbGo7eTSH7z3UT2WaOxm44ajTiyks5svNOYgaJpZM4PFDtw .

We have a fix for this bug that doesn’t require a new flag (we’ve removed the server dependency here). Unfortunately, it failed to go in 1.24 by a string, this will be fixed in 1.25, thanks.

@apelisse

According to https://kubernetes.io/blog/2019/01/14/apiserver-dry-run-and-kubectl-diff/

The existing solution is to run kubectl apply --dry-run, but this runs a local dry-run that doesn’t talk to the server

But that doesn’t appear to be true. There was the introduction of the apiserver-dry-run so not sure how that differs from a --dry-run.

I to would like to run some validation in a pipeline where no cluster exists.

/remove-lifecycle stale

I would also like a "local’ mode where I can use kubectl create subcommands to nicely format files for later use. It’s nice that kubectl create secret generic <name> --from-file=<file1> --from-file=<file2> takes care of the base64 encoding and populating YAML key/value pairs for me. Similarly nice for config maps.

/remove-lifecycle stale

OK, kubectl create (as is in the title) doesn’t require a connection.

kubectl apply is a different beast, it needs to read the existing object, since it’s not doing a strict creation, it’s also possibly patching the existing object. How do we know the state of the current object without a connection?

kustomize build does not need a server connection. So kubectl create --dry-run=client neither should need one.

EDITED: create added

The bug is that running --dry-run=client requires a connection to the K8s server. If I (can) have a connection to the cluster, I should prefer to use --dry-run=server, which provides more accurate results because it’s also running the server-side validation.

Here you can see that when starting minikube (Client Version: v1.24.1 / Server Version: v1.23.3) and using --dry-run=client it’s working, but when I turn minikube off, the command will not work:

image

That’s one way to do it, we could also do:

o.OpenAPISchema = f.OpenAPISchema

and lazily call that function as needed? If you do that, make sure that only one call is actually emitted (I think this function automatically uses a cache so it should be fine).

I’d start by looking at the kubectl create code, which probably lives around here.

The thing that requires the connection to the server, I think, is the call to OpenAPISchema() or something, you should be able to investigate and found this call. It’s not necessary when we’re using kubectl create with parameters rather than with a given file.

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

I think current contract of dry-run is quite useful to see if everything with a request is correct or not without changing any state

This is what I think, too. Maybe there could be an additional command kubectl validate to validate without server-connection

I am not sure if it is a good idea, I think it should interact with API server just that shouldn’t mutate any state in etcd.

Otherwise what guarantee would a a successful dry run provide if it doesn’t even interact with the server?

There might be RBAC rules to be evaluated Or availability checked for certain API groups.

I think current contract of dry-run is quite useful to see if everything with a request is correct or not without changing any state