From f770631cd9907fb76527dbf2505e8a5273117555 Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Tue, 19 Jun 2018 11:40:00 +0900 Subject: [PATCH 1/2] apply task template --- .../debug-pod-replication-controller.md | 51 ++++++++++++++----- 1 file changed, 39 insertions(+), 12 deletions(-) diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index f196853172492..cdb66694e2a6e 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -1,17 +1,33 @@ --- reviewers: - bprashanth -title: Debug Pods and Replication Controllers +title: Debug Pods and ReplicationControllers +content_template: templates/task --- -{{< toc >}} +{{% capture overview %}} +This page shows how to debug Pods and ReplicationControllers. +{{% /capture %}} -## Debugging pods +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* You should be familiar with the basics of + [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). + +{{% /capture %}} + +{{% capture steps %}} + +## Debugging Pods The first step in debugging a pod is taking a look at it. Check the current state of the pod and recent events with the following command: - $ kubectl describe pods ${POD_NAME} +```shell +kubectl describe pods ${POD_NAME} +``` Look at the state of the containers in the pod. Are they all `Running`? Have there been recent restarts? @@ -44,8 +60,10 @@ case you can try several things: command. Here are some example command lines that extract just the necessary information: - kubectl get nodes -o yaml | grep '\sname\|cpu\|memory' - kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}' + ```shell + kubectl get nodes -o yaml | grep '\sname\|cpu\|memory' + kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}' + ``` The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured to limit the total amount of @@ -75,33 +93,42 @@ worker node, but it can't run on that machine. Again, the information from First, take a look at the logs of the current container: - $ kubectl logs ${POD_NAME} ${CONTAINER_NAME} +```shell +kubectl logs ${POD_NAME} ${CONTAINER_NAME} +``` If your container has previously crashed, you can access the previous container's crash log with: - $ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} +```shell +kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} +``` Alternately, you can run commands inside that container with `exec`: - $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} +```shell +kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} +``` Note that `-c ${CONTAINER_NAME}` is optional and can be omitted for pods that only contain a single container. As an example, to look at the logs from a running Cassandra pod, you might run: - $ kubectl exec cassandra -- cat /var/log/cassandra/system.log +```shell +kubectl exec cassandra -- cat /var/log/cassandra/system.log +``` If none of these approaches work, you can find the host machine that the pod is running on and SSH into that host. -## Debugging Replication Controllers +## Debugging ReplicationControllers -Replication controllers are fairly straightforward. They can either create pods +ReplicationControllers are fairly straightforward. They can either create pods or they can't. If they can't create pods, then please refer to the [instructions above](#debugging_pods) to debug your pods. You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events related to the replication controller. +{{% /capture %}} From 2db385cc57c20ef9b59c47e16a76a1fa992019ae Mon Sep 17 00:00:00 2001 From: makocchi-git Date: Tue, 17 Jul 2018 21:26:24 +0900 Subject: [PATCH 2/2] change content_template to task from concept --- .../debug-pod-replication-controller.md | 29 +++++++++++++------ 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 6d319217cdb9e..d59f3a918c740 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -1,12 +1,29 @@ --- reviewers: - bprashanth -title: Debug Pods and Replication Controllers -content_template: templates/concept +title: Debug Pods and ReplicationControllers +content_template: templates/task --- {{% capture overview %}} +This page shows how to debug Pods and ReplicationControllers. + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* You should be familiar with the basics of + [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). + +{{% /capture %}} + +{{% capture steps %}} + +## Debugging Pods + The first step in debugging a pod is taking a look at it. Check the current state of the pod and recent events with the following command: @@ -19,12 +36,6 @@ there been recent restarts? Continue debugging depending on the state of the pods. -{{% /capture %}} - -{{< toc >}} - -{{% capture body %}} - ### My pod stays pending If a pod is stuck in `Pending` it means that it can not be scheduled onto a @@ -117,7 +128,7 @@ running on and SSH into that host. ReplicationControllers are fairly straightforward. They can either create pods or they can't. If they can't create pods, then please refer to the -[instructions above](#debugging_pods) to debug your pods. +[instructions above](#debugging-pods) to debug your pods. You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events related to the replication controller.