I'm on macOS Catalina 10.15.4, and I'm using minikube v1.11.0 and kubernetes v1.18.3, both installed from brew. Minikube is initialized with the docker engine.
The initialization command is set up like so:
containers:
- name: database
image: "mysql:5.6"
imagePullPolicy: IfNotPresent
env:
- name: MYSQL_ROOT_PASSWORD
value: 12345
- name: MYSQL_USER
value: user
- name: MYSQL_PASSWORD
value: password
- name: MYSQL_DATABASE
value: db
I'm trying to get a bash script open for one of my running kubectl containers. From research online, it appears that this should be the command that will open a bash window in my terminal:
minikube kubectl exec -it --namespace=tools test-pod -- bash
However, when I run it, I get the following traceback:
Error: unknown shorthand flag: 'i' in -it See 'minikube kubectl --help' for usage.
It doesn't seem to want me using any arguments in my command. Is there something I'm missing, or am I attempting to use a command that is deprecated?
Note: I am able to run exec, but not for opening a bash script. For example, I am able to run the following command:
minikube kubectl exec test-pod -- ls /
And it outputs this following:
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
bin
boot
dev
docker-entrypoint-initdb.d
entrypoint.sh
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
Edit: I have attempted the following command:
minikube kubectl exec --stdin --tty --namespace=tools test-pod -- sh
And I got the following traceback:
Error: unknown flag: --stdin
See 'minikube kubectl --help' for usage.
It seems like any flags at all, short or long, are failing, and I cannot figure out why they wouldn't be.
minikube kubectl needs the -- after the command when you want to use it with arguments:
$ minikube kubectl -- exec --stdin --tty --namespace=tools test-pod -- sh
You can also use plain kubectl
If would just make sure that your ~/.kube/config is pointing to the right minikube context/cluster. Typically, any minikube command you run from the shell will cause it to change the context to your minikube cluster. i.e minikube ssh
Then just use kubectl
$ kubectl exec --stdin --tty --namespace=tools test-pod -- sh
So, I figured out the solution:
With my configuration, initializing minikube with minikube start --driver=docker does not successfully initialize everything. I changed my driver to virtualbox, and minikube was able to ssh and continue without any issues.
Setup with a docker driver appears to be commonly issue-prone, as this GitHub thread shows: https://github.com/kubernetes/minikube/issues/7332
Related
I am using Kubernetes to exec into a pod like this:
kubectl exec myPod bash -i
which works fine, except I don't get a prompt. So then I do:
export PS1="myPrompt "
Which I would expect to give me a prompt, but doesn't. Is there some workaround for this?
Trying to exec into pod in interactive way requires specifying -ti option.
Where -i passes stdin to the container and -t connects your terminal to this stdin.
Take a look at the following example:
kubectl exec -it myPod -- bash
I am writing a shell script for executing a pod for which the syntax is:
winpty kubectl --kubeconfig="C:\kubeconfig" -n namespace exec -it podname bash
This works fine but since podname is not stable and changes for every deployment so is there any alternative for this?
Thanks.
You can use normally $ kubectl exec command but define value for changing pod name.
Assuming that you have deployment and labeled pods: app=example, simply execute:
$ kubectl exec -it $(kubectl get pods -l app=example -o custom-columns=:metadata.name) -- bash
EDIT:
You can also execute:
POD_NAME = $(kubectl get pods -l app=example -o custom-columns=":metadata.name")
or
POD_NAME = $(kubectl get pods -l app=example -o jsonpath = "{. Items [0] .metadata.name}")
finally
$ winpty kubectl exec -ti $POD_NAME --bash
Make sure that you execute command in proper namespace - you can also add -n flag and define it.
You can use the following command:
kubectl -n <namespace> exec -it deploy/<deployment-name> -- bash
Add a service to your application:
As you know, pods are ephemeral; They come in and out of existence dynamically to ensure your application stays in compliance with your configuration. This behavior implements the scaling and self-healing aspects of kubernetes.
You application will consist of one or more pods that are accessible through a service , The application's service name and address does not change and so acts as the stable interface to reach your application.
This method works both if your application has one pod or many pods.
Does that help?
I'm very new to docker.
Also I'm using Docker for Windows (ie Image and Container are for Windows OS).
I'm trying to get a list of all the folders and subfolders to resolve another issue I'm having. I read several post and blogs and seems like I should be able to run
docker exec -it <container id> dir
To get the info as it is suppose to allow me to run commands against the container.
I even ran
docker exec -it f83eb1533b67 help
which gave me a list of commands (because no one tells what are acceptable 'commands'...) and it is listed. however I get the following message when I run DIR command
PS P:\docker\tmp\SqlServerSetup> `docker exec -it f83eb1533b67 dir`
container f83eb1533b671b4462b8a1562da7343185b2dd27e94ff360e0230969d432ec37 encountered an error during CreateProcess: failure in a Windows system call: The system cannot find the file specified. (0x2)
[Event Detail: Provider: 00000000-0000-0000-0000-000000000000] extra info: {"CommandLine":"dir","WorkingDirectory":"C:\\","Environment":{"ACCEPT_EULA":"Y","attach_dbs":"[]","sa_password":"Pass1.4DBAs","sa_password_path":"C:\\ProgramData\\Docker\\secrets\\sa-password"},"EmulateConsole":true,"CreateStdInPipe":true,"CreateStdOutPipe":true,"ConsoleSize":[0,0]}
PS P:\docker\tmp\SqlServerSetup>
Please note: I don't want to persist a volume. Seems like that option is for people that are trying to reuse data.
UPDATE:
This is the statement that i'm using to create the container:
docker run -p 1433:1433 -e sa_password=Pass1.4DBAs -e ACCEPT_EULA=Y -p 11433:1433 --name sqlTraining --cap-add SYS_PTRACE -d microsoft/mssql-server-windows-developer
It works fine. Container is created, but I want to view the filesystem within that container.
For Windows containers, prefix the command with the command shell (cmd) and the /c parameter. For example:
docker exec <container id> cmd /c dir
This will execute the dir command on the specified container and terminate.
Try running:
docker exec -it <container id> sh
to start the interactive shell console. This should help you with debugging.
I'm running Docker Toolbox on VirtualBox on Windows 10.
I'm having an annoying issue where if I docker exec -it mycontainer sh into a container - to inspect things, the shell will abruptly exit randomly back to the host shell, while I'm typing commands. Some experimenting reveals that it's when I press two letters at the same time (as is common when touch typing) that causes the exit.
The container will still be running.
Any ideas what this is?
More details
Here's a minimal docker image I'm running inside. Essentially, I'm trying to deploy kubernetes clusters to AWS via kops, but because I'm on Windows, I have to use a container to run the kops commands.
FROM alpine:3.5
#install aws-cli
RUN apk add --no-cache \
bind-tools\
python \
python-dev \
py-pip \
curl
RUN pip install awscli
#install kubectl
RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
RUN chmod +x ./kubectl
RUN mv ./kubectl /usr/local/bin/kubectl
#install kops
RUN curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
RUN chmod +x kops-linux-amd64
RUN mv kops-linux-amd64 /usr/local/bin/kops
I build this image:
docker build -t mykube .
I run this in the working directory of my the project I'm trying to deploy:
docker run -dit -v "${PWD}":/app mykube
I exec into the shell:
docker exec -it $containerid sh
Inside the shell, I start running AWS commands as per here.
Here's some example output:
##output of previous dig command
;; Query time: 343 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Wed Feb 14 21:32:16 UTC 2018
;; MSG SIZE rcvd: 188
##me entering a command
/ # aws s3 mb s3://clus
##shell exits abruptly to host shell while I'm writing
DavidJ#DavidJ-PC001 MINGW64 ~/git-workspace/webpack-react-express (master)
##container is still running
$ docker ps --all
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
37a341cfde83 mykube "/bin/sh" 5 minutes ago Up 3 minutes gifted_bhaskara
##nothing in docker logs
$ docker logs --details 37a341cfde83
A more useful update
Adding the -D flag gives an important clue:
$ docker -D exec -it 04eef8107e91 sh -x
DEBU[0000] Error resize: Error response from daemon: no such exec
/ #
/ #
/ #
/ #
/ # sdfsdfjskfdDEBU[0006] [hijack] End of stdin
DEBU[0006] [hijack] End of stdout
Also, I've ascertained that what specifically is causing the issue is pressing two letters at the same time (which is quite common when I'm touch typing).
There appears to be a github issue for this here, though this one is for docker for windows, not docker toolbox.
This issue appears to be a bug with docker and windows. See the github issue here.
As a work around, prefix your docker exec command with winpty, which comes with git bash.
eg.
winpty docker exec -it mycontainer sh
Check the USER which is the one you are login with when doing a docker exec -it yourContainer sh.
Its .bahsrc, .bash_profile or .profile might include a command which would explain why the session abruptly quits.
Check also the logs associated to that container (docker logs --details yourContainer) in order to see if that closed session generated anything in stderr.
Reasons I can think of for a process to be killed in your container include:
Pid 1 exiting in the container. This would cause the container to go into a stopped state, but a restart policy could have restarted it. See your docker container inspect output to see if this is happening. This is the most common cause I've seen.
Out of memory on the OS, where the kernel would then kill processes. View your system logs and dmesg to see if this is happening.
Exceeding the container memory limit, where docker would kill the container, possibly restarting it depending on your policy. You would again view docker container inspect but the status will have different details.
Process being killed on the host, potentially by a security tool.
Perhaps a selinux or apparmor policy being violated.
Networking issues. Never encountered it myself, but since docker is a client / server design, there's a potential for a network disconnect to drop the exec session.
The server itself is failing, and you'd see various logs in syslog / dmesg indicating problems it can't recover from.
I'm having k8s cluster with 3 minions, master and haproxy in front. When I use
kubectl exec -p $POD -i -t -- bash -il
for accessing bash in the pod (it is a single container in this case) I get in and after something like 5 mins I get dropped out of the terminal. If I reenter the container I can see my old bash process running, with a new started for my new connection. Is there a way to prevent this from happening? When I'm using docker exec it works fine and doesn't drop me so I guess it is from kubernetes.
As a bonus question - is there a way to increase the characters per line when using kubectl exec? I get truncated output that is different from docker exec.
Thanks in advance!
It is a known issue -
https://github.com/kubernetes/kubernetes/issues/9180
The kubelet webserver times out.
i have resolve by add env COLUMNS=$COLUMNS LINES=$LINES before bash kubectl exec -ti busybox env COLUMNS=$COLUMNS LINES=$LINES bash