Change:
This page is outdated according to the comment of this ticket, because if you follow the instructions, you always get an error like the one below in any worker node when you execute: where is:{ "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "linux": { } } E0107 22:25:16. ] "RunPodSandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to setup network for sandbox "888e1ca106ad4e8439154c056cbf6d926b1417c43aba37f8a5052a916e5f8516": plugin type="calico" failed (add): pods "nginx-sandbox" not found" FATA[0000] run pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "888e1ca106ad4e8439154c056cbf6d926b1417c43aba37f8a5052a916e5f8516": plugin type="calico" failed (add): pods "nginx-sandbox" not found` and seemingly it is due to "calico daemonset watch apiserver to get a list of pods, and apply network configuration based on the pod spec." So, the page may be deleted or the list of sections below removed:
Page reported in issue: /language en
/retitle “Debugging Kubernetes nodes with crictl” is outdated
/sig node
/triage accepted
Funny, one of the reviewers of the doc, is the same person, that posted the note in the containerd issue, In fact, we don't recommend user to run and on a Kubernetes node , those commands are there just for some special debug case.
As per my investigation, all example commands work fine in the except for the mentioned sections. As per the referenced issue, I think it should be safe to delete the specific sections instead of a whole page. The documentation also has a warning message under section which refers to the sections that need to be deleted. So, if these sections are to be deleted then the warning message should be deleted as well.
still has the same example as included in . So it can very well be a bug. /cc Would it be okay to delete these sections in the documentation? If so I would like to raise a PR for the same.
thank you! Please propose a PR with the changes. We may also link to the official docs.
/assign

Discussion:
The following examples show some `crictl` commands and example output. <del> {{< warning >}} If you use `crictl` to create pod sandboxes or containers on a running Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a general purpose workflow tool, but a tool that is useful for debugging. {{< /warning >}} </del> ### List pods List all pods:

10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" ``` <del> ### Run a pod sandbox Using `crictl` to run a pod sandbox is useful for debugging container runtimes. On a running Kubernetes cluster, the sandbox will eventually be stopped and deleted by the Kubelet. 1. Create a JSON file like the following: ```json { "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "log_directory": "/tmp", "linux": { } } ``` 2. Use the `crictl runp` command to apply the JSON and run the sandbox. ```shell crictl runp pod-config.json ``` The ID of the sandbox is returned. ### Create a container Using `crictl` to create a container is useful for debugging container runtimes. On a running Kubernetes cluster, the container will eventually be stopped and deleted by the Kubelet. 1. Pull a busybox image ```shell crictl pull busybox ``` ```none Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 ``` 2. Create configs for the pod and the container: **Pod config**: ```json { "metadata": { "name": "busybox-sandbox", "namespace": "default", "attempt": 1, "uid": "aewi4aeThua7ooShohbo1phoj" }, "log_directory": "/tmp", "linux": { } } ``` **Container config**: ```json { "metadata": { "name": "busybox" }, "image":{ "image": "busybox" }, "command": [ "top" ], "log_path":"busybox.log", "linux": { } } ``` 3. Create the container, passing the ID of the previously-created pod, the container config file, and the pod config file. The ID of the container is returned. ```shell crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json ``` 4. List all containers and verify that the newly-created container has its state set to `Created`. ```shell crictl ps -a ``` The output is similar to this: ``` CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT 3e025dd50a72d       busybox             32 seconds ago      Created             busybox             0 ``` ### Start a container To start a container, pass its ID to `crictl start`: ```shell crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 ``` The output is similar to this: ``` 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 ``` Check the container has its state set to `Running`. ```shell crictl ps ``` The output is similar to this: ``` CONTAINER ID   IMAGE    CREATED              STATE    NAME     ATTEMPT 3e025dd50a72d  busybox  About a minute ago   Running  busybox  0 ``` </del> ## {{% heading "whatsnext" %}} * [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools).