[proposal] Add container and orchestrator info for processes

[andrewkroh]

Add support for determining container and orchestrator info about a process. The implementation should only infer data through information from the OS (no interaction with container runtimes or orchestrators to keep things stable and simple).

• container.id
• container.runtime
• orchestrator.resource.id - (i.e. the kubernetes pod uid which is what you get from kubectl get pods -o=json | jq '.items[].metadata.uid')
• orchestrator.type

This would only be implemented for the Linux provider at this time. Perhaps at some future time it could be extended to support container info on Windows. For Linux this information can be inferred from a process's cgroups as given by /proc/$pid/cgroup. However if the reading process has been placed in a cgroupns then it won't be able to infer the information because the paths will lack the necessary details.

For example, given this cgroup data then go-sysinfo would return

{
  "container": {
    "id": "e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459",
    "runtime": "containerd"
  },
  "orchestrator": {
    "type": "kubernetes",
    "resource": {
      "id": "2d5133c0-65f3-40b2-b375-c04866d418e1"
    }
  }
}

$ cat /proc/1234/cgroup 
11:memory:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
10:cpuset:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
9:pids:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
8:cpu,cpuacct:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
7:freezer:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
6:devices:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
5:perf_event:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
4:hugetlb:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
3:net_cls,net_prio:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
2:blkio:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope
1:name=systemd:/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2d5133c0_65f3_40b2_b375_c04866d418e1.slice/cri-containerd-e01a26336924e2fb8089bcf4cf943954fd9ea616cc5678f38f65928307979459.scope

At a minimum it should support detecting containers running via docker, podman, runc, cri-o, and containerd.

A good place to start would be to continue the discussion here with a proposal for the changes to the types package (like an interface and the supporting data structs).