3

Docker image tags are mutable, in that image:latest and image:1.0 can both point to image@sha256:....., but when version 1.1 is released, image:latest stored within a registry can be pointed to an image with a different sha digest. Pulling an image with a particular tag now does not mean that an identical image will be pulled next time.

If a Kubernetes YAMl resource definition refers to an image by tag (not by digest), is there a means of determining what sha digest each image will actually resolve to, before the resource definition is deployed? Is this functionality supported using kustomize or kubectl?

Use case is wanting to determine what has actually been deployed in one environment before deploying to another (I'd like to take a hash of the resolved resource definition and could then use this to understand whether image:1.0 to be deployed to PROD refers to the same image:1.0 that was deployed to UAT).

Are there any tools that can be used to support this functionality?

For example, given the following YAML, is there a way of replacing all images with their resolved digests?

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

To get something like this:

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

I'd like to be able to do something like pipe yaml (that might come from cat, kustomize or kubectl ... --dry-run) through a tool and then pass to kubectl apply -f:

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

EDIT:

The background to this is the need to be able to prove to auditors/regulators that what is about to be deployed to one env (PROD) is exactly what has been successfully deployed to another env (UAT). I'd like to use normal tags in the deployment template and at the time of deploying to UAT, take a snapshot of the template with the tags replaced with the digests of the resolved images. That snapshot will be what is deployed (via kubectl or similar). When deploying to PROD, that same snapshot will be used.

John
  • 10,837
  • 17
  • 78
  • 141
  • As mentioned in your question there is a live [example](https://github.com/kubernetes-sigs/kustomize/tree/b2dd74ab97e9b140cecce66a45b295b0905e8ef8/examples/transformerconfigs/images) – Mark Sep 20 '19 at 16:05
  • Thanks @Hanx, I hadn't seen that. It's not quite what I'm after, in that I don't want to define the sha digest in the deployment config, I just want to know what that digest is prior to initiating the digest. – John Sep 21 '19 at 00:36
  • Hey John, did you find a solution for this? I'm looking exactly for the same, define some images in templates with some tag and replace those tags by the actual sha256 during deployment. – agascon May 12 '20 at 12:41
  • @agascon I haven't tried `kbld` as you mention in an answer below as it wasn't available when I asked the question, but at the time I did do something with [skopeo](https://github.com/containers/skopeo), which specifically allows for inspecting images without actually needing to download them, as detailed [here](https://www.projectatomic.io/blog/2016/03/skopeo-inspect-remote-images/). – John May 15 '20 at 08:26

4 Answers4

5

This tool is supporting exactly what you need...

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

Resolves name-tag pair reference (nginx:1.17) into digest reference (index.docker.io/library/nginx@sha256:2539d4344...)

Looks integrates quite well with templating tools like Kustomize or even Helm

agascon
  • 718
  • 1
  • 6
  • 25
2

You can all the containers used info with this command. This will list all namespaces, with pod names, with container image name and sha256 of the image.

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{","}{.metadata.name}{","}{range .status.containerStatuses[*]}{.image}{", "}{.imageID}{", "}{end}{end}' | sort
Ram
  • 123
  • 4
0

is there a means of determining what sha digest each image will actually resolve to, before the resource definition is deployed?

No, and in the case you describe, it can vary by node. The Deployment will create some number of Pods, each Pod will get scheduled on some Node, and the Kubelet there will only pull the image if it doesn’t have something with that tag already. If you have two replicas, and you’ve changed the image a tag points to, then on node A it could use the older image that was already there, but on node B where there isn’t an image, it will pull and get the newer version.

The best practice here is to avoid changing the image a tag points to. Give each build coming out of your CI system a unique tag (a datestamp or source control commit ID for example) and use that in your Kubernetes object specifications. That avoids this problem entirely.

A workaround is to set

imagePullPolicy: Always

in your pod specs, which will force the node to pull a newer version, but this is unnecessary overhead in most cases.

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • Sorry, I haven't made my self clear. I want to define in YAML that I am using `image:1.0`, because that is easy for a human to understand and reason about. I want to replace the `1.0` in the YAML with the sha digest **and use this new YAML for the deployment**. The error you describe cannot happen under these circumstances. – John Sep 20 '19 at 13:19
  • A templating system like Helm could be an effective solution for this. You could have the default image tag be `1.0` but replace it with a fixed version at deploy time. – David Maze Sep 20 '19 at 13:38
0

Here's another on - k8s-digester from google folks. It's a bit different in a sense than the main focus is on cluster-side changes(via Adm Controller) even though client-side KRM functions seems to also be possible.

Overall, kbld seems to be more about development experience and adoption with your cli/CICD/orchestration, while k8s-digester is more about administration on the cluster side.

yuranos
  • 8,799
  • 9
  • 56
  • 65