I was able to view the app container logs using kubectl -f logs and was able to login to the container using "k exec --stdin --tty -- /bin/bash".
After injecting linkerd, I could not login to the container. However my goal is to check the app logs.
When I use this "k logs -f linkerd-proxy" I could not see the app-related logs.
I tried injecting debug-sidecar as well.
Tried this - "k logs deploy/ linkerd-debug - " and as well as this "k exec -it -c linkerd-debug -- tshark -i any -f "tcp" -V -Y "http.request"
still I couldn't see the exact logs for my app in the pod. Please suggest.
Linkerd works by injecting an additional container into your pods; this is known as the "sidecar" pattern. Your application (or better said container) logs are still accessible, however, as a result of having more than one container in the pod, kubectl requires you to explicitly specify the container name.
For example, assuming you have a pod with two containers (linkerd-proxy and app), you'd have to specify app as the name of the container:
$ kubectl logs -f <pod-name> -c app
# You can specify the container name without the -c flag
$ kubectl logs -f <pod-name> app
# This will work for 'exec' too
$ kubectl exec <pod-name> -c app -it -- sh
Related
I tried multiple syntax including one given below , no luck yet
kubectl exec -u root -it testpod -- bash
Error: unknown shorthand flag: 'u' in -u
See 'kubectl exec --help' for usage.
it is version 1.22
There is no option available in kubectl exec to mention the user
Because it is decided at either in the container image or in the pod.spec.containers.securityContext.runAsUser field
so to achieve what youy want is on a running container then do just kubectl exec -it testpod -- bash and then issue su - root from inside the container
Currently if I'm about to inspect my container, I have to do three steps:
kubectl get all -n {NameSpace}
kubectl describe {Podname from step 1} -n {NameSpace}
Find the Node Host and the container ID (My eyes are complaning!)
Switch to the host and execute "docker exec -ti -u root {Container ID} bash"
I am so mad about it right now. Wish somebody could offer some help to me and those who may share the same issue.
Pods are the smallest deployable units of computing that you can
create and manage in Kubernetes.
So, if you want to "enter" a container, you just need to "exec" into the pod in a particular namespace. Kubernetes will get you the shell/command for that pod.
kubectl -n somenamespace exec -it podname -- bash
There is no need to mention the node here as Kubernetes internally knows on which node the pod is scheduled.
If a Pod has more than one container, use --container or -c to specify
a container in the kubectl exec command. For example, suppose you have
a Pod named my-pod, and the Pod has two containers named main-app and
helper-app. The following command would open a shell to the main-app
container.
kubectl exec -it my-pod -c main-app -- /bin/bash
https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/
I often run tasks like:
Read the log of the service X
or
Attach a shell inside the service Y
I always use something in my history like:
kubectl logs `kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep <partial_name>`
or
kubectl exec -it `kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep <partial_name>` bash
Do you know if kubectl has already something in place for this? Or should I create my own set of aliases?
Kubernetes instances are loosely coupled by the means of labels (key-value pairs). Because of that Kubernetes provides various functionalities that can help you to operate on sets of objects based on labels.
In case you have several pods of the same service good chances that they are managed by some ReplicaSet with the use of some specific label. You should see it if you run:
kubectl get pods --show-labels
Now for aggregating logs for instance you could use label selector like:
kubectl logs -l key=value
For more info please see: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ .
added to my .zshconfig
sshpod () {
kubectl exec --stdin --tty `kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep ${1} | head -n 1` -- /bin/bash
}
usage
sshpod podname
this
finds all pods
greps needed name
picks the first
sshs into the pod
You can go access a pod by its deployment/service/etc:
kubectl exec -it svc/foo -- bash
kubectl exec -it deployment/bar -- bash
Kubernetes will pick a pod that matches the criteria and send you to it.
You can enable shell autocompletion. Kubectl provides this support for Bash and Zsh which will save you a lot of typing (you will use TAB to get the suggestion/completion).
Kuberentes documentations has a great set of information about how to enable autocompletion under Optional kubectl configurations. It covers Bash on Linux, Bash on MacOS and Zsh.
I run an .NET Core 2.1 in a container. It writes logs to a file within the container. I am able to run a docker exec bash command to inspect the log file, locally.
This application is then deployed with Kubernetes to a pod with more than one container.
How can I inspect the log file within each one of these containers?
You can exec into container within pod:
kubectl -n <namespace> exec -it <pod name> -c <container name> bash
But the better approach is to make your application stream logs to stdout or stderr, so you can access it directly with:
kubectl -n <namespace> logs <pod name> -c <container name>
I have problem login into one container of a multi-container pod.
I get the container id from the kubectl describe pod <pod-name>
kubectl describe pod ipengine-net-benchmark-488656591-gjrpc -c <container id>
When i try:
kubectl exec -ti ipengine-net-benchmark-488656591-gjrpc -c 70761432854f /bin/bash
It says: Error from server: container 70761432854f is not valid for pod ipengine-net-benchmark-488656591-gjrpc
Ah once more detailed reading the man page of kubectl exec :
Flags:
-c, --container="": Container name. If omitted, the first container in the pod will be chosen
-p, --pod="": Pod name
-i, --stdin[=false]: Pass stdin to the container
-t, --tty[=false]: Stdin is a TTY
So i just used the container name from my manifest.yaml and it worked like charm.
Name of the container: ipengine-net-benchmark-iperf-server
kubectl exec -ti ipengine-net-benchmark-488656591-gjrpc -c ipengine-net-benchmark-iperf-server /bin/bash