can i use a configmap created from an init container in the pod

后端 未结 3 1677
半阙折子戏
半阙折子戏 2021-02-14 16:32

I am trying to \"pass\" a value from the init container to a container. Since values in a configmap are shared across the namespace, I figured I can use it for this purpose. Her

相关标签:
3条回答
  • 2021-02-14 16:46

    First of all, kubectl is a binary. It was downloaded in your machine before you could use the command. But, In your POD, the kubectl binary doesn't exist. So, you can't use kubectl command from a busybox image.

    Furthermore, kubectl uses some credential that is saved in your machine (probably in ~/.kube path). So, If you try to use kubectl from inside an image, this will fail because of missing credentials.

    For your scenario, I will suggest the same as @ccshih, use volume sharing. Here is the official doc about volume sharing between init-container and container.

    The yaml that is used here is ,

    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: {}
    

    Here init-containers saves a file in the volume and later the file was available in inside the container. Try the tutorial by yourself for better understanding.

    0 讨论(0)
  • 2021-02-14 16:56

    If your various reasons, you don't want to use share volume. And you want to create a configmap or a secret, here is a solution.

    First you need to use a docker image which contains kubectl : gcr.io/cloud-builders/kubectl:latest for example. (docker image which contains kubectl manage by Google).

    Then this (init)container needs enough rights to create resource on Kubernetes cluster. Ok by default, kubernetes inject a token of default service account named : "default" in container, but I prefer to make more explicit, then add this line :

    ...
          initContainers:
            - # Already true by default but if use it, prefer to make it explicit
              automountServiceAccountToken: true
              name: artifactory-snapshot
    

    And add "edit" role to "default" service account:

    kubectl create rolebinding default-edit-rb --clusterrole=edit --serviceaccount=default:myapp --namespace=default
    

    Then complete example :

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: installer-test
    spec:
      template:
        spec:
          initContainers:
            - # Already true by default but if use it, prefer to make it explicit.
              automountServiceAccountToken: true
              name: artifactory-snapshot
              # You need to use docker image which contains kubectl
              image: gcr.io/cloud-builders/kubectl:latest
              command:
                - sh
                - -c
                # the "--dry-run -o yaml | kubectl apply -f -" is to make command idempotent
                - kubectl create configmap test-config --from-literal=artifactorySnapshotUrl=http://artifactory.com/some/url --dry-run -o yaml | kubectl apply -f -
          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
    
    
    0 讨论(0)
  • 2021-02-14 16:59

    You can create an EmptyDir volume, and mount this volume onto both containers. Unlike persistent volume, EmptyDir has no portability issue.

    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
    
    0 讨论(0)
提交回复
热议问题