如何将 /var/lib/kubelet/pods 下的 guids 映射到实际的 pods

How to map the guids under /var/lib/kubelet/pods to the actual pods

我试图调试一些挂载问题,挂载日志引导我进入 /var/lib/kubelet/pods 下的路径,即

/var/lib/kubelet/pods/f6affad1-941d-4df1-a0b7-38e3f2ab99d5/volumes/kubernetes.io~nfs/my-pv-e0dbe341a6fe475c9029fb372e

如何将pods下根目录的guid映射到实际的运行 pod或容器中?

(上例中的f6affad1-941d-4df1-a0b7-38e3f2ab99d5

我没有发现与 kubectlcrictl 返回的值有任何关联。

他们是 Pod 的 .metadata.uid;可以使用您最喜欢的机制将它们映射回来,以查询所有 pods 并在其 .metadata.uid 上进行过滤,并且如果您有这么多 Pods 使 -A 不可行

for d in /var/lib/kubelet/pods/*; do
  p_u=$(basename "$d")
  kubectl get po -A -o json | \
    jq --arg pod_uuid "$p_u" -r '.items[] 
      | select(.metadata.uid == $pod_uuid) 
      | "uuid \($pod_uuid) is \(.metadata.name)"'
done

我确定有一个 -o jsonpath=-o gotemplate= 表格可以消除 jq 的需要,但是在文本区域中输入需要做更多的工作

关于你的 crictl 问题,我现在无法访问我的 containerd 集群,但是基于 docker 的容器用 io.kubernetes.pod.uid 标记本地容器,所以我会猜测 containerd 做了类似的事情:

            "Labels": {
                "annotation.io.kubernetes.container.hash": "e44bee94",
                "annotation.io.kubernetes.container.restartCount": "4",
                "annotation.io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
                "annotation.io.kubernetes.container.terminationMessagePolicy": "File",
                "annotation.io.kubernetes.pod.terminationGracePeriod": "30",
                "io.kubernetes.container.logpath": "/var/log/pods/kube-system_storage-provisioner_b4aa3b1c-62c1-4661-a302-4c06b305b7c0/storage-provisioner/4.log",
                "io.kubernetes.container.name": "storage-provisioner",
                "io.kubernetes.docker.type": "container",
                "io.kubernetes.pod.name": "storage-provisioner",
                "io.kubernetes.pod.namespace": "kube-system",
                "io.kubernetes.pod.uid": "b4aa3b1c-62c1-4661-a302-4c06b305b7c0",
                "io.kubernetes.sandbox.id": "3950ec60121fd13116230cad388a4c6c4e417c660b7da475436f9ad5c9cf6738"
            }