Do Openshift Origin jobs need hard-coded internal registry URLs for images?

后端 未结 1 1602
余生分开走
余生分开走 2020-12-06 08:14

I can\'t figure a namespace-portable way to build an image into an imagestream that can then be used for a job in an OpenShift project namespace without har

相关标签:
1条回答
  • 2020-12-06 08:49

    As I understand it, it is this way because what you are using is actually the Kubernetes Job object. Anytime you do things at the Kubernetes level, you have to reference an image from an image registry. The concept of image streams doesn't exist in Kubernetes. This is where OpenShift objects such as build and deployment configuration are a bit smarter, as they work via the image stream object, which acts as a form of index or indirect pointer. The use of image streams as an intermediary makes things easier when using OpenShift.

    That all said, I was told that there may be something in OpenShift 3.6 which does make this easier. Right now though, it apparently isn't documented as to how it works. The one person who can likely tell me about the details is on holiday to the end of the month, I am though seeing if I can find out more details and will update this when I know.


    UPDATE 1

    Provided you are using OpenShift 3.6, and is-copy-adaptermappings is an image stream in the current project, try the following:

    {
      "apiVersion": "batch/v1",
      "kind": "Job",
      "metadata": {
        "name": "configpod"
        "annotations": {
          "alpha.image.policy.openshift.io/resolve-names": "*"
        },
      },
      "spec": {
        "parallelism": 1,
        "completions": 1,
        "template": {
          "metadata": {
            "name": "copy-config-to-pv"
          },
          "spec": {
            "containers": [
              {
                "name": "copy-config-to-pv",
                "image": "is-copy-adaptermappings",
                "imagePullPolicy": "Always",
                "volumeMounts": [
                  {
                    "mountPath": "/dest",
                    "name": "volume-config"
                  }
                ]
              }
            ],
            "restartPolicy": "OnFailure",
            "volumes": [
              {
                "name": "volume-config",
                "persistentVolumeClaim": {
                  "claimName": "pvc-configs"
                }
              }
            ]
          }
        }
      }
    }
    

    The addition is the annotation with name alpha.image.policy.openshift.io/resolve-names in the metadata for the job.

    The value of image can be imagestream name, in which case latest tag is used, or can be name:tag and reference a specific tag.

    Using the annotation is this way has alpha status and as such the name of the annotation will eventually change. Usually they try and auto migrate names which incorporate alpha/beta tags, but do be aware that in case when status changes it stops working.


    UPDATE 2

    It looks like an alternate way to using the annotation that may now exist is to set is.spec.lookupPolicy and enable local lookup.

    $ oc explain is.spec.lookupPolicy
    RESOURCE: lookupPolicy <Object>
    
    DESCRIPTION:
         lookupPolicy controls how other resources reference images within this
         namespace.
    
        ImageLookupPolicy describes how an image stream can be used to override the image references used by pods, builds, and other resources in a namespace.
    
    FIELDS:
       local    <boolean> -required-
         local will change the docker short image references (like "mysql" or
         "php:latest") on objects in this namespace to the image ID whenever they
         match this image stream, instead of reaching out to a remote registry. The
         name will be fully qualified to an image ID if found. The tag's
         referencePolicy is taken into account on the replaced value. Only works
         within the current namespace.
    

    That is, set this on the image stream object you want to reference in the image field.

    0 讨论(0)
提交回复
热议问题