Kubectl: namespace is ignored when --dry-run=client -o yaml

Created on 18 Jan 2021  路  3Comments  路  Source: kubernetes/kubectl

What happened:

$ kubectl run nginx2 --image=nginx --restart=Never -n development -o yaml --dry-run=client
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx2
  name: nginx2
spec:
  containers:
  - image: nginx
    name: nginx2
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

What you expected to happen:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx2
  name: nginx2
  namespace: development
spec:
  containers:
  - image: nginx
    name: nginx2
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

How to reproduce it (as minimally and precisely as possible):

$ kubectl run nginx2 --image=nginx --restart=Never -n development -o yaml --dry-run=client

Funny thing: without -o yaml --dry-run=client it does the expected thing.

$ kubectl run nginx2 --image=nginx --restart=Never -n development

$ kubectl get pods -n development
NAME     READY   STATUS    RESTARTS   AGE
nginx2   1/1     Running   0          10s

Anything else we need to know?:

No

Environment:

  • Kubernetes client and server versions (use kubectl version):
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"archive", BuildDate:"2020-07-28T00:00:00Z", GoVersion:"go1.15rc1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:51:19Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
  • Cloud provider or hardware configuration:
$ minikube version
minikube version: v1.16.0
commit: 9f1e482427589ff8451c4723b6ba53bb9742fbb1
  • OS (e.g: cat /etc/os-release):
$ cat /etc/os-release 
NAME=Fedora
VERSION="33 (Workstation Edition)"
ID=fedora
VERSION_ID=33
VERSION_CODENAME=""
PLATFORM_ID="platform:f33"
PRETTY_NAME="Fedora 33 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:33"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=33
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=33
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation
kinbug needs-triage

Most helpful comment

I confirm this is not a bug after all. If I use the same server version with my client there it works.
Sorry for the noise.

All 3 comments

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

I tried this but it was not reproduced. The difference looks like the kubectl version. What if you upgrade your kubectl to the latest then try again?

# I am using my own namespace, not `development` but it's unlikely related
$ kubectl run nginx2 --image=nginx --restart=Never -n kubecolor -o yaml --dry-run=client
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx2
  name: nginx2
  namespace: kubecolor
spec:
  containers:
  - image: nginx
    name: nginx2
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}
$ kubectl version --short
Client Version: v1.20.2
Server Version: v1.20.0
$ minikube version
minikube version: v1.16.0
commit: 9f1e482427589ff8451c4723b6ba53bb9742fbb1

I confirm this is not a bug after all. If I use the same server version with my client there it works.
Sorry for the noise.

Was this page helpful?
0 / 5 - 0 ratings