Make an index available on Cluster
Once you have an
Index of operators, you can make it available on cluster by referencing it from a
For example, if you have an index image
quay.io/my-namespace/my-index:latest, you can create a CatalogSource with your index image:
apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-index namespace: operator spec: sourceType: grpc image: quay.io/my-namespace/my-index:latest displayName: My Index publisher: Me updateStrategy: registryPoll: interval: 10m
Explanation of spec.updateStrategy
It is possible to configure the
CatalogSource to poll a source, such as an image registry, to check whether the catalog source pod should be updated. A common use case would be pushing new bundles to the same catalog source tag, and seeing updated operators from those bundles being installed in the cluster. Currently polling is only implemented for image-based catalogs that serve bundles over gRPC.
For example, say currently you have Operator X v1.0 installed in the cluster. It came from a the
quay.io/my-namespace/my-index:master. This is the latest version of the X operator in the
Index. When a new v2.0 of Operator X is available, the index image can be rebuilt to include the v2.0 version of the X operator(with
opm index add) and pushed to the same master tag. With catalog polling enabled, OLM will pull down the newer version of the index image and route service traffic to the newer pod. The existing subscription to your operator will seamlessly install the v2.0 operator and remove the old v1.0 installation.
Each type of check for an updated catalog source is called an
updateStrategy. Only one
updateStrategy is supported at a time.
registryPoll is a type of
updateStrategy that checks an image registry for an updated version of the same tag(via image SHAs). The
interval defines the amount of time between each successive poll.
- The polling sequence is not instantaneous - it can take up to 15 minutes from each poll for the new catalog source pod to be deployed into the cluster. It may take longer for larger clusters.
- Because OLM pulls down the image every poll interval and starts the pod, to see if its updated, the updated catalog pod must be able to be scheduled onto the cluster. If the cluster is at absolutely maximum capacity, without autoscaling enabled, this feature may not work.
- OLM checks to see whether the container ImageID has changed between the old and new catalog source image when determining if an upgrade is in order. It does not actually parse the image content itself to check for later CSVs. If there is a bad upgrade to the catalog source image, simply overwrite the tag with another version and it will be pulled down, or delete and recreate the catalog source.
- The polling interval should be reasonably high to ensure the update functionality works as intended. Avoid intervals less than 15m.
Using registry images that require authentication as index/bundle/operator/operand images
If certain images are hosted in an authenticated container image registry, also known as a private registry, OLM is unable to pull the images by default. To enable access, you can create a pull secret that contains the authentication credentials for the registry. By referencing one or more pull secrets in a
CatalogSource, OLM can handle placing the secrets in the operator and catalog namespace to allow installation.
Note: Bundle images that require authentication to pull are handled by this method. Other images required by an Operator or its Operands might require access to private registries as well. OLM does not handle placing the secrets in target tenant namespaces for this scenario, but authentication credentials can be added to the global cluster pull secret or individual namespace service accounts to enable the required access. Alternatively, if providing access to the entire cluster is not permissible, the pull secret can be added to the
defaultservice accounts of the target tenant namespaces.
To use images from private registries as index/bundle images, create a secret for each required private registry. Once you have the secrets,
kubectl apply your secrets to the cluster, and the create or update an existing
CatalogSource object to reference one or more secrets to add a
spec.secrets section and specify all secrets.
apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-index namespace: operator spec: sourceType: grpc secrets: - "<secret_name_1>" - "<secret_name_2>" image: quay.io/my-namespace/my-index:latest displayName: My Index publisher: Me updateStrategy: registryPoll: interval: 10m