Могу ли я использовать configmap, созданный из контейнера init в модуле

Question

Я пытаюсь "передать" значение из контейнера init в контейнер.Поскольку значения в configmap совместно используются в пространстве имен, я решил, что могу использовать его для этой цели.Вот мой job.yaml (с поддельной информацией):

apiVersion: batch/v1
kind: Job
metadata:
  name: installer-test
spec:
  template:
    spec:
      containers:
      - name: installer-test
        image: installer-test:latest
        env:
        - name: clusterId
          value: "some_cluster_id"
        - name: in_artifactoryUrl
          valueFrom:
            configMapKeyRef:
              name: test-config
              key: artifactorySnapshotUrl
      initContainers:
      - name: artifactory-snapshot
        image: busybox
        command: ['kubectl', 'create configmap test-config --from-literal=artifactorySnapshotUrl=http://artifactory.com/some/url']
      restartPolicy: Never
  backoffLimit: 0

Это не похоже на работу (EDIT: хотя утверждения, следующие за этим примечанием к редактированию, могут все еще быть правильными, это не работает, потому что kubectlне распознаваемая команда в образе busybox), и я предполагаю, что модуль может считывать значения только из карты конфигурации, созданной ДО создания модуля.Кто-нибудь еще сталкивался с трудностью передачи значений между контейнерами, и что вы сделали, чтобы решить эту проблему?

Должен ли я развернуть configmap в другом модуле и подождать, чтобы развернуть его, пока не существует configmap?

(я знаю, что могу записывать файлы на том, но я бы предпочел не идти по этому пути, если это не является абсолютно необходимым, поскольку по сути это означает, что наши образы докеров должны быть связаны с окружением, в котором существуют некоторые конкретные файлы)

Answer 1

Прежде всего, kubectl - это двоичный файл.Он был загружен на ваш компьютер, прежде чем вы могли использовать команду.Но в вашем POD двоичный файл kubectl не существует.Таким образом, вы не можете использовать команду kubectl из образа busybox.

Кроме того, kubectl использует некоторые учетные данные, сохраненные на вашем компьютере (вероятно, в пути ~/.kube).Поэтому, если вы попытаетесь использовать kubectl изнутри изображения, это не удастся из-за отсутствия учетных данных.

Для вашего сценария я предложу то же самое, что и @ccshih, используйте разделение томов.Вот официальный документ о совместном использовании томов между init-container и container.

Здесь используется yaml:

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  # These containers are run during pod initialization
  initContainers:
  - name: install
    image: busybox
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

Здесь init-containersсохраняет файл в томе, а затем файл был доступен внутри контейнера.Попробуйте учебник самостоятельно для лучшего понимания.

Answer 2

Вы можете создать том EmptyDir и смонтировать этот том в оба контейнера.В отличие от persistent volume, EmptyDir не имеет проблем с переносимостью.

apiVersion: batch/v1
kind: Job
metadata:
  name: installer-test
spec:
  template:
    spec:
      containers:
      - name: installer-test
        image: installer-test:latest
        env:
        - name: clusterId
          value: "some_cluster_id"
        volumeMounts:
        - name: tmp
          mountPath: /tmp/artifact
      initContainers:
      - name: artifactory-snapshot
        image: busybox
        command: ['/bin/sh', '-c', 'cp x /tmp/artifact/x']
        volumeMounts:
        - name: tmp
          mountPath: /tmp/artifact
      restartPolicy: Never
      volumes:
      - name: tmp
        emptyDir: {}
  backoffLimit: 0