The command minikube kubectl has a lot of problems. Any flag that you pass to it won't work because corba will try to parse it, eg:
minikube kubectl logs -f my-pod
Error: unknown shorthand flag: 'f' in -f
Usage:
minikube kubectl [flags]
Flags:
-h, --help help for kubectl
Global Flags:
--alsologtostderr log to standard error as well as files
-b, --bootstrapper string The name of the cluster bootstrapper that will set up the kubernetes cluster. (default "kubeadm")
--log_backtrace_at traceLocation when logging hits line file:N, emit a stack trace (default :0)
--log_dir string If non-empty, write log files in this directory
--logtostderr log to standard error instead of files
-p, --profile string The name of the minikube VM being used. This can be set to allow having multiple instances of minikube independently. (default "minikube")
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
-v, --v Level log level for V logs
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging
Or if you run --help on it, it shows the corba help, not kubectl itself.
Would it make sense to deprecate it? Let users use kubectl, as long as we have the minikube profile to allow setting the context, or switching the context it should be okay.
wdyt? @medyagh @tstromberg @afbjorklund
I wouldn't say _lots_ of problems, you just have to put the -- in the right place...
$ minikube kubectl -- --help
kubectl controls the Kubernetes cluster manager
See #4333
But maybe we should go for something like sudo minikube kubectl --install ?
I would prefer to install it in e.g. the home directory, but it's not always in $PATH.
So could use something like /usr/local/bin, and hope _that_ is in the default path*.
I just want the user to avoid having to go through two horrible installation procedures.
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
&& chmod +x minikube
sudo install minikube /usr/local/bin
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
See #3645
Hopefully some documentation could "fix" this ?
I think that we should handle kubectl like kubelet...
@afbjorklund Thank you so much for clarifying. That makes a lot of sense, definitely, some documentation would fix it.
Thanks for the suggestion, in the current form it wouldn't fly very well with our documentation.
$ minikube kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.4 --port=8080
Error: unknown flag: --image
Usage:
minikube kubectl [flags]
Then again, maybe it needs some improvements anyway.
$ minikube kubectl -- run hello-minikube --image=k8s.gcr.io/echoserver:1.4 --port=8080
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/hello-minikube created
But we should write minikube kubectl -- everywhere.
Or add that --install command to put it in the $PATH.
I was experiencing same issue with --image flag and as I was aliasing kubectl command to avoid writing minikube all the time, I decided changing alias to this:
alias kubectl="minikube kubectl --"
Hope this helps to more users :wink:
Most helpful comment
I wouldn't say _lots_ of problems, you just have to put the
--in the right place...See #4333
But maybe we should go for something like
sudo minikube kubectl --install?I would prefer to install it in e.g. the home directory, but it's not always in $PATH.
So could use something like
/usr/local/bin, and hope _that_ is in the default path*.I just want the user to avoid having to go through two horrible installation procedures.
See #3645
Hopefully some documentation could "fix" this ?
I think that we should handle kubectl like kubelet...