vbatts/cri-o
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
cri-o/cmd/kpod
History
Vincent Batts ab36ad50be
kpod: info subcommand 
Design: The output of the `info` subcommand ought to be directly
consumable in a format like JSON or yaml.
The structure being a map of sorts.

Each subsection of information being an individual cluster under the
top-level, like platform info, debug, storage, etc.

Even if there are errors under the top level key, the value will be a
map with the key of "error" and the value as the message of the
`err.Error()`. In this way, the command always returns usable output.

Ideally there will be a means for anything that can register info to do
so independently from it being in the single info.go, so this approach
is having a typed signature for the function that gives info, but i'm
sure it could be better.

Current iteration of this outputs the following as a limited user:

```yaml
host:
  MemFree: 711307264
  MemTotal: 2096222208
  SwapFree: 2147479552
  SwapTotal: 2147479552
  arch: amd64
  cpus: 1
  os: linux
store:
  error: 'mkdir /var/run/containers/storage: permission denied'

```

and as root (`sudo kpod info -D`):

```yaml
debug:
  compiler: gc
  go version: go1.7.6
  goroutines: 3
host:
  MemFree: 717795328
  MemTotal: 2096222208
  SwapFree: 2147479552
  SwapTotal: 2147479552
  arch: amd64
  cpus: 1
  os: linux
store:
  ContainerStore:
    number: 1
  GraphDriverName: overlay2
  GraphRoot: /var/lib/containers/storage
  ImageStore:
    number: 1
```

And with the `--json --debug` flag:

```json
{
  "debug": {
    "compiler": "gc",
    "go version": "go1.7.6",
    "goroutines": 3
  },
  "host": {
    "MemFree": 709402624,
    "MemTotal": 2096222208,
    "SwapFree": 2147479552,
    "SwapTotal": 2147479552,
    "arch": "amd64",
    "cpus": 1,
    "os": "linux"
  },
  "store": {
    "ContainerStore": {
      "number": 1
    },
    "GraphDriverName": "overlay2",
    "GraphRoot": "/var/lib/containers/storage",
    "ImageStore": {
      "number": 1
    }
  }
}
```

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
2017-07-17 14:23:53 -04:00
..
common.go Add 'kpod images' and 'kpod rmi' commands 2017-07-11 15:52:57 -04:00
common_test.go Add 'kpod images' and 'kpod rmi' commands 2017-07-11 15:52:57 -04:00
images.go Add 'kpod images' and 'kpod rmi' commands 2017-07-11 15:52:57 -04:00
images_test.go Add 'kpod images' and 'kpod rmi' commands 2017-07-11 15:52:57 -04:00
info.go kpod: info subcommand 2017-07-17 14:23:53 -04:00
main.go kpod: info subcommand 2017-07-17 14:23:53 -04:00
pull.go Add 'kpod pull' command 2017-07-11 09:05:17 -04:00
README.md Rename ocid to crio. 2017-05-12 09:56:06 -04:00
rmi.go Add 'kpod images' and 'kpod rmi' commands 2017-07-11 15:52:57 -04:00
rmi_test.go Add 'kpod images' and 'kpod rmi' commands 2017-07-11 15:52:57 -04:00
tag.go Add kpod tag command 2017-07-06 10:10:51 -04:00
version.go kpod: version should not fail 2017-07-10 17:02:13 -04:00

README.md

kpod - Simple debugging tool for pods and images

kpod is a simple client only tool to help with debugging issues when daemons such as CRI runtime and the kubelet are not responding or failing. A shared API layer could be created to share code between the daemon and kpod. kpod does not require any daemon running. kpod utilizes the same underlying components that crio uses i.e. containers/image, container/storage, oci-runtime-tool/generate, runc or any other OCI compatible runtime. kpod shares state with crio and so has the capability to debug pods/images created by crio.

Use cases

  1. List pods.
  2. Launch simple pods (that require no daemon support).
  3. Exec commands in a container in a pod.
  4. Launch additional containers in a pod.
  5. List images.
  6. Remove images not in use.
  7. Pull images.
  8. Check image size.
  9. Report pod disk resource usage.