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)
/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=clientandkubectl apply --dry-run=serverwith 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 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/
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 createsubcommands to nicely format files for later use. It’s nice thatkubectl 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 applyis 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 builddoes not need a server connection. Sokubectl create --dry-run=clientneither should need one.EDITED:
createaddedThe bug is that running
--dry-run=clientrequires 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=clientit’s working, but when I turn minikube off, the command will not work:That’s one way to do it, we could also do:
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 createcode, 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 usingkubectl createwith 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
This is what I think, too. Maybe there could be an additional command
kubectl validateto validate without server-connectionI 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