Как получить разрешенный sha дайджест для всех изображений в Kubernetes yaml? - PullRequest
Новая
       7

Как получить разрешенный sha дайджест для всех изображений в Kubernetes yaml?

0 голосов
/ 20 сентября 2019

Теги изображений Docker являются изменяемыми, так как image:latest и image:1.0 могут указывать на image@sha256:....., но когда выпущена версия 1.1, image:latest, хранящаяся в реестре, может указывать на изображение сдругой ша дайджест.Вытягивание изображения с определенным тегом теперь не означает, что идентичное изображение будет извлечено в следующий раз.

Если определение ресурса YAMl Kubernetes относится к изображению по тегу (не по дайджесту), есть ли средствоопределение того, к какому дайджесту будет каждое изображение будет фактически разрешено, до того, как определение ресурса будет развернуто?Поддерживается ли эта функция с использованием 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

Я хотел бы иметь возможность сделать что-то вроде pipe yaml (которое может прийти от cat, kustomize или kubectl ... --dry-run) через инструмент и затем перейти к kubectl apply -f: 

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

РЕДАКТИРОВАТЬ:

Основанием для этого является необходимость иметь возможность доказать аудиторам / регулирующим органам, что то, что собирается развернуть в одном env (PROD), составляет точно что было успехомполностью развернут в другой env (UAT).Я хотел бы использовать обычные теги в шаблоне развертывания и во время развертывания в UAT сделать снимок шаблона с замененными тегами на дайджесты разрешенных изображений.Этот снимок будет тем, что развернуто (через kubectl или подобное).При развертывании в PROD будет использоваться тот же моментальный снимок.

1 Ответ

0 голосов
/ 20 сентября 2019

есть ли способ определить, к какому дайджесту будет фактически разрешено каждое изображение перед развертыванием определения ресурса?

Нет, и в случае, который вы описываете, оно может варьироватьсяпо узлу.Развертывание создаст некоторое количество модулей, каждое из которых будет запланировано на каком-либо узле, а Kubelet будет тянуть изображение только в том случае, если у него уже нет чего-либо с этим тегом.Если у вас есть две реплики, и вы изменили изображение, на которое указывает тег, то на узле A он мог бы использовать более старое изображение, которое уже было там, но на узле B, где нет изображения, он вытянет и получитболее новая версия.

Рекомендуется избегать изменения изображения, на которое указывает тег.Присвойте каждой сборке, выходящей из вашей системы CI, уникальный тег (например, метку даты или код подтверждения исходного кода) и используйте его в спецификациях объекта Kubernetes.Это полностью устраняет эту проблему.

Обходной путь должен установить 

imagePullPolicy: Always

в ваших спецификациях pod, что заставит узел тянуть более новую версию, но в большинстве случаев это ненужные издержки.

...