If I run the command
$ kubectl exec pod-name echo Hello World
I get a deprecation error message asking me to include the '--' characters.
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Why was the decision made to require the '--' characters there? It seems unnecessary to me. I understand it's deprecated, I'm just trying to understand the reasoning behind the decision.
According the book "Kubernetes in action" by Marko Luksa:
Why the double dash?
The double dash (--) in the command signals the end of command options for
kubectl. Everything after the double dash is the command that should be executed
inside the pod . Using the double dash isn’t necessary if the command has no
arguments that start with a dash. But in your case, if you don’t use the double dash
there, the -s option would be interpreted as an option for kubectl exec and would
result in the following strange and highly misleading error:
$ kubectl exec kubia-7nog1 curl -s http://10.111.249.153
The connection to the server 10.111.249.153 was refused – did you
specify the right host or port?
This has nothing to do with your service refusing the connection. It’s because
kubectl is not able to connect to an API server at 10.111.249.153 (the -s option
is used to tell kubectl to connect to a different API server than the default).
Related
I was trying to get into kubernetes-dashboard Pod, but I keep getting this error:
C:\Users\USER>kubectl exec -n kubernetes-dashboard kubernetes-dashboard-66c887f759-bljtc -it -- sh
OCI runtime exec failed: exec failed: unable to start container process: exec: "sh": executable file not found in $PATH: unknown
command terminated with exit code 126
The Pod is running normally and I can access the Kubernetes UI via the browser. But I was getting some issues getting it running before, and I wanted to get inside the pod to run some commands, but I always get the same error mentioned above.
When I try the same command with a pod running nginx for example, it works:
C:\Users\USER>kubectl exec my-nginx -it -- sh
/ # ls
bin home proc sys
dev lib root tmp
docker-entrypoint.d media run usr
docker-entrypoint.sh mnt sbin var
etc opt srv
/ # exit
Any explanation, please?
Prefix the command to run with /bin so your updated command will look like:
kubectl exec -n kubernetes-dashboard <POD_NAME> -it -- /bin/sh
The reason you're getting that error is because Git in Windows slightly modifies the MSYS that changes command args. Generally using the command /bin/sh or /bash/bash works universally.
That error message means literally what it says: there is no sh or any other shell in the container. There's no particular requirement that a container have a shell, and if a Docker image is built FROM scratch (as the Kubernetes dashboard image is) or a "distroless" image, it just may not contain one.
In most cases you shouldn't need to "enter a container", and you should use kubectl exec (or docker exec) sparingly if at all. This is doubly true in Kubernetes: it's not just that changes you make manually will get lost when the container exits, but also that in Kubernetes you typically have multiple replicas that you can't manually edit all at once, and also that in some cases the cluster can delete and recreate a Pod outside of your control.
When i issue
kubectl logs MY_POD_NAME --limit-bytes=1
command, the --limit-bytes option is ignored and i get all the pod's logs.
My kubernetes version is 1.15.3
Trying to understand why that would be. When i issue the same command in GKE setup, the --limit-bytes option works as expected. I wonder what might be different in my setup to prevent this option from working correctly. (This is on CentOS).
Update: i tracked down the issue to Docker's --log-driver option.
If the Docker --log-driver is set to 'json-file', then kubectl logs command works fine with --limit-bytes option. However, if the Docker -log-driver is set to 'journald', then kubectl logs command ignores the --limit-bytes option. Seems like a kubectl bug to me.
After executing this command you shoud have seen following error:
error: expected 'logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]'.
POD or TYPE/NAME is a required argument for the logs command
See 'kubectl logs -h' for help and examples.
Execute:
$ kubectl logs your_pod_name -c container_name --limit-bytes=1 -n namespace_name
If you set --limit-bytes flag you must know that
--limit-bytes=0: Maximum bytes of logs to return.
Defaults to no limit.=0: Maximum bytes of logs to return. Defaults to no limit.
Documentation of kubectl-logs.
Please let me know if it helps.
Yeah, it should work fine -
Please try this, if you have one container in application -
kubectl -n namespace logs pod_name --limit-bytes=1
If you have multiple containers then please mention like -
kubectl -n namespace logs pod_name -c container_name --limit-bytes=1
How can I set the timeout for the kubectl exec command ?
The below command does not work
kubectl exec -it pod_name bash --requrest-timeout=0 -n test
You have a typo, try:
kubectl exec -it pod_name bash --request-timeout=0 -n test
See kubectl official documentation about request-timeout
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
Note that "0" is already the default.
We ran into this issue standing up an on-prem instance of K8s. The answer in our situation was haproxy.
If you have a load-balancer in front of your K8s API (control-plane), I'd look at a timeout on that as the culprit.
I believe the default for haproxy was 20 seconds so after I changed it to 60m, we never noticed the problem again.
I have more than one Kubernetes context. When I change contexts, I have been using kill -9 to kill the port-forward in order to redo the pachtctl port-forward & command. I wonder if this is the right way of doing it.
In more detail:
I start off being in a Kubernetes context, we'll call it context_x. I then want to change context to my local context, called minikube. I also want to see my repos for this minikube context, but when I use pachctl list-repo, it still shows context_x's Pachyderm repos. When I do pachctl port-forward, I then get an error message about the address being already in use. So I have to ps -a, then kill -9 on those port forward processes, and then do pachctl port-forward command again.
An example of what I've been doing:
$ kubectl config use-context minikube
$ pachctl list-repo #doesn't show minikube context's repos
$ pachctl port-forward &
...several error messages along the lines of:
Unable to create listener: Error listen tcp4 127.0.0.1:30650: bind: address already in use
$ ps -a | grep forward
33964 ttys002 0:00.51 kubectl port-forward dash-12345678-abcde 38080:8080
33965 ttys002 0:00.51 kubectl port-forward dash-12345679-abcde 38081:8081
37245 ttys002 0:00.12 pachctl port-forward &
37260 ttys002 0:00.20 kubectl port-forward pachd-4212312322-abcde 30650:650
$ kill -9 37260
$ pachctl port-forward & #works as expected now
Also, kill -9 on the pachctl port-forward process 37245 doesn't work, it seems like I have to kill -9 on the kubectl port-forward
You can specify the port if you want, as a different one using -p flag as mentioned in docs Is there a reason of not doing it?
Also starting processes in background and then sending it a SIGKILL causes the resources to be unallocated properly so when you try to join again you might see it giving errors since it cannot allocate the same port again. So try running it without & at the end.
So whenever you change the context all you need to do is CTRL + C and start it again, this will release the resources properly and gain thema gain.
Just wanted to update this answer for anyone who finds it—pachctl now supports contexts, and a Pachyderm context includes a reference to its associated kubectl context. When you switch to a new pachctl context, pachctl will now use the associated kubectl context automatically (you'll still need to switch contexts in kubectl)
first of all any help is appreciated
I want execute a command in a container and I execute:
kubectl exec -ti busybox bash
but if I input about 70 characters in bash and then I get truncated output and line broken anyway lead to unreadable.
is there a way to increase the characters per line when using kubectl exec?
Environment (also see manifests for more detailed info):
Centos 7.0.1406
Kubernetes: 1.2.0
etcd: 2.3.7
flannel: 0.5.3
docker:1.10.3
Thanks a lot for any suggestions.
This will be supported in the upcoming Kubernetes 1.4 release (if you're interested, see its fix).