2

Docker 镜像标签是可变的，因为它们image:latest都image:1.0可以指向image@sha256:.....，但是当版本1.1发布时，image:latest存储在注册表中的镜像可以指向具有不同 sha 摘要的镜像。现在拉取带有特定标签的图像并不意味着下次将拉取相同的图像。

如果 Kubernetes YAMl 资源定义按标签（而不是按摘要）引用图像，是否有一种方法可以在部署资源定义之前确定每个图像实际解析为什么 sha 摘要？是否使用kustomize或支持此功能kubectl？

用例希望在部署到另一个环境之前确定在一个环境中实际部署了什么（我想获取已解析资源定义的哈希值，然后可以使用它来了解是否image:1.0部署到 PROD 指的是相同image:1.0的被部署到 UAT）。

是否有任何工具可用于支持此功能？

例如，给定以下 YAML，有没有办法用解析的摘要替换所有图像？

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: image1
      image: image1:1.1
      command:
        - /bin/sh -c some command
    - name: image2
      image: image2:2.2
      command:
        - /bin/sh -c some other command

要得到这样的东西：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: image1
      image: image1@sha:....
      command:
        - /bin/sh -c some command
    - name: image2
      image: image2@sha:....
      command:
        - /bin/sh -c some other command

我希望能够通过工具执行管道 yaml （可能来自cat,kustomize或kubectl ... --dry-run）之类的操作，然后传递给kubectl apply -f：

cat mydeployment.yaml | some-tool | kubectl apply -f -

编辑：

其背景是需要能够向审计员/监管机构证明即将部署到一个环境 (PROD) 的内容正是已成功部署到另一个环境 (UAT) 的内容。我想在部署模板中使用普通标签，并在部署到 UAT 时，拍摄模板的快照，并将标签替换为已解析图像的摘要。该快照将是部署的（通过kubectl或类似方式）。部署到 PROD 时，将使用相同的快照。

4

4 回答 4

5

这个工具完全支持你所需要的......

kbld：https ://get-kbld.io/

将名称-标签对引用 (nginx:1.17) 解析为摘要引用 (index.docker.io/library/nginx@sha256:2539d4344...)

Looks 与 Kustomize 甚至 Helm 等模板工具集成得非常好

于 2020-05-12T12:56:14.810 回答
1

您可以使用此命令将所有容器使用信息。这将列出所有命名空间、pod 名称、容器镜像名称和镜像的 sha256。

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{","}{.metadata.name}{","}{range .status.containerStatuses[*]}{.image}{", "}{.imageID}{", "}{end}{end}' | sort
于 2021-08-02T05:35:41.967 回答
0

这是来自 google的另一个 on- k8s-digester 。从某种意义上说，它与主要关注集群端更改（通过 Adm 控制器）有点不同，尽管客户端 KRM 功能似乎也是可能的。

总体而言，kbld似乎更多的是关于您的开发经验和采用cli/ CICD/ orchestration，而k8s-digester更多的是关于集群方面的管理。

于 2021-11-16T16:49:34.913 回答
0

在部署资源定义之前，是否有一种方法可以确定每个图像实际解析为什么 sha 摘要？

不，在您描述的情况下，它可能因节点而异。Deployment 将创建一些 Pod，每个 Pod 将被安排在某个节点上，并且那里的 Kubelet 只会在没有带有该标签的东西时拉取镜像。如果您有两个副本，并且您更改了标签指向的图像，那么在节点 A 上它可以使用已经存在的旧图像，但在没有图像的节点 B 上，它将拉取并获取较新的版本。

此处的最佳做法是避免更改标签指向的图像。为来自 CI 系统的每个构建提供一个唯一标签（例如日期戳或源代码控制提交 ID），并在 Kubernetes 对象规范中使用它。这完全避免了这个问题。

一种解决方法是设置

imagePullPolicy: Always

在您的 pod 规格中，这将强制节点拉取较新的版本，但在大多数情况下这是不必要的开销。

于 2019-09-20T13:02:55.453 回答