You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{product-title} manages image caching using a local registry. In edge computing use cases, clusters are often subject to bandwidth restrictions when communicating with centralized image registries, which might result in long image download times.
10
10
11
11
Long download times are unavoidable during initial deployment. Over time, there is a risk that CRI-O will erase the `/var/lib/containers/storage` directory in the case of an unexpected shutdown.
12
+
To address long image download times, you can create a local image registry on remote managed clusters using GitOps ZTP. This is useful in Edge computing scenarios where clusters are deployed at the far edge of the network.
12
13
13
-
To address long image download times, you can create a local image registry on the remote managed clusterusing GitOps ZTP. This is useful in Edge computing scenarios where clusters are deployed on the far edge of the network.
14
+
Before you can set up the local image registry with GitOps ZTP, you need to configure disk partitioning in the `SiteConfig` CR that you use to install the remote managed cluster. After installation, you configure the local image registry using a `PolicyGenTemplate` CR. Then, the ZTP pipeline creates Persistent Volume (PV) and Persistent Volume Claim (PVC) CRs and patches the `imageregistry` configuration.
14
15
15
16
[NOTE]
16
17
====
17
-
The local image registry can only be used for user application images and cannot be used for the {product-title} or Operator Lifecycle Manager operator images. For information about working with these, see Topology Aware Lifecycle Manager (TALM) in Additional resources.
18
+
The local image registry can only be used for user application images and cannot be used for the {product-title} or Operator Lifecycle Manager operator images.
18
19
====
19
-
20
-
The first phase of setting up a local image registry is configuring disk partitioning using a `SiteConfig` CR. You can use the `SiteConfig` CR to generate the `MachineConfig` CR used for disk partitioning.
21
-
The next phase is to configure the image registry using `PolicyGenTemplate` CRs. The ZTP pipeline uses `PolicyGenTemplate` CRs to create Persistent Volumes (PV) and Persistent Volume Claim (PVC) CRs and patch the `imageregistry` configuration.
Use a `SiteConfig` CR to generate the `MachineConfig` CR used for disk partitioning. Prior to installation, you need to modify values in the `SiteConfig` CR to reflect dependencies on the underlying disk.
9
+
Configure disk partitioning for a managed cluster using a `SiteConfig` CR and GitOps ZTP. The disk partition details in the `SiteConfig` CR must match the the underlying disk.
10
10
11
11
[NOTE]
12
12
====
13
-
You must use persistent naming for devices to avoid device names such as `/dev/sda` and `/dev/sdb` being switched at every reboot. You can use `rootDeviceHints` to choose the bootable device and then use same device for further partitioning: in this case, for Image registry.
13
+
Use persistent naming for devices to avoid device names such as `/dev/sda` and `/dev/sdb` being switched at every reboot. You can use `rootDeviceHints` to choose the bootable device and then use same device for further partitioning.
14
14
====
15
15
16
16
.Prerequisites
17
17
18
-
* You have installed and configured Zero Touch Provisioning (ZTP). For information about this, see the topic on ZTP in Additional resources.
18
+
* You have installed the OpenShift CLI (`oc`).
19
+
20
+
* You have logged in to the hub cluster as a user with `cluster-admin` privileges.
21
+
22
+
* You have created a Git repository where you manage your custom site configuration data for use with GitOps Zero Touch Provisioning (ZTP).
19
23
20
24
.Procedure
21
25
22
-
. Add the following YAML to the `SiteConfig` CR that you use to generate the `MachineConfig` CR for disk partitioning:
26
+
. Add the following YAML that describes the host disk partitioning to the `SiteConfig` CR that you use to install the managed cluster:
= Configuring the image registry using PolicyGenTemplate CRs
8
8
9
-
You can use `PolicyGenTemplate`to apply to create the PV and PVC and patch `imageregistry` configuration. Select the appropriate `PolicyGenTemplate` for each `source-cr`. See Additional Resources for more help.
9
+
Use `PolicyGenTemplate`(PGT) CRs to apply the CRs required to configure the image registry and patch the `imageregistry` configuration.
10
10
11
11
.Prerequisites
12
12
13
-
* You have installed and configured Zero Touch Provisioning (ZTP). For information about this, see the topic on ZTP in Additional resources.
13
+
* You have configured a disk partition in the managed cluster.
14
+
15
+
* You have installed the OpenShift CLI (`oc`).
16
+
17
+
* You have logged in to the hub cluster as a user with `cluster-admin` privileges.
18
+
19
+
* You have created a Git repository where you manage your custom site configuration data for use with GitOps Zero Touch Provisioning (ZTP).
14
20
15
21
.Procedure
16
22
17
-
. Configure the storage class, persistent volume claim, persistent volume, and image registry configuration in the appropriate `PolicyGenTemplate` CR. For example, to configure an individual site, use the following YAML:
23
+
. Configure the storage class, persistent volume claim, persistent volume, and image registry configuration in the appropriate `PolicyGenTemplate` CR. For example, to configure an individual site, add the following YAML to the file `example-sno-site.yaml`:
18
24
+
19
25
[source,yaml]
20
26
----
21
27
sourceFiles:
22
-
# storage class
23
-
- fileName: StorageClass.yaml
24
-
policyName: "sc-for-image-registry"
25
-
metadata:
26
-
name: image-registry-sc
27
-
annotations:
28
-
ran.openshift.io/ztp-deploy-wave: "100" <1>
28
+
# storage class
29
+
- fileName: StorageClass.yaml
30
+
policyName: "sc-for-image-registry"
31
+
metadata:
32
+
name: image-registry-sc
33
+
annotations:
34
+
ran.openshift.io/ztp-deploy-wave: "100" <1>
29
35
# persistent volume claim
30
-
- fileName: StoragePVC.yaml
36
+
- fileName: StoragePVC.yaml
31
37
policyName: "pvc-for-image-registry"
32
38
metadata:
33
39
name: image-registry-pvc
34
40
namespace: openshift-image-registry
35
-
annotations:
36
-
ran.openshift.io/ztp-deploy-wave: "100" <2>
41
+
annotations:
42
+
ran.openshift.io/ztp-deploy-wave: "100"
37
43
spec:
38
44
accessModes:
39
-
ReadWriteMany
45
+
- ReadWriteMany
40
46
resources:
41
47
requests:
42
48
storage: 100Gi
43
49
storageClassName: image-registry-sc
44
50
volumeMode: Filesystem
45
51
# persistent volume
46
-
- fileName: ImageRegistryPV.yaml <3>
52
+
- fileName: ImageRegistryPV.yaml <2>
47
53
policyName: "pv-for-image-registry"
48
54
metadata:
49
55
annotations:
50
-
ran.openshift.io/ztp-deploy-wave: "100" <4>
51
-
# image registry config
52
-
- fileName: ImageRegistryConfig.yaml <5>
56
+
ran.openshift.io/ztp-deploy-wave: "100"
57
+
- fileName: ImageRegistryConfig.yaml
53
58
policyName: "config-for-image-registry"
54
-
complianceType: musthave <5>
59
+
complianceType: musthave
55
60
metadata:
56
61
annotations:
57
-
ran.openshift.io/ztp-deploy-wave: "100" <6>
62
+
ran.openshift.io/ztp-deploy-wave: "100"
58
63
spec:
59
64
storage:
60
65
pvc:
61
66
claim: "image-registry-pvc"
62
67
----
63
-
<1> Set the appropriate value for `ztp-deploy-wave` depending on whether you are configuring image registries at the site, common, or group level. `ztp-deploy-wave: "100"` is appropriate for an individual site. ZTP deploy waves are used to order how policies are applied to the spoke cluster. All policies created by `PolicyGen` have a ztp deploy wave by default.
64
-
<2> Set the appropriate value for `ztp-deploy-wave` as in note 1.
65
-
<3> This assumes that `mount_point` is set to `/var/imageregistry` in `SiteConfig` using StorageClass `image-registry-sc` (see the topic on configuring disk partitioning with `SiteConfig`).
66
-
<4> Set the appropriate value for `ztp-deploy-wave` as in note 1.
67
-
<5> Configure registry to point to the PVC created above.
68
-
<6> Set the appropriate value for `ztp-deploy-wave` as in note 1.
68
+
<1> Set the appropriate value for `ztp-deploy-wave` depending on whether you are configuring image registries at the site, common, or group level. `ztp-deploy-wave: "100"` is suitable for development or testing because it allows you to group the referenced source files together.
69
+
<2> In `ImageRegistryPV.yaml`, ensure that the `spec.local.path` field is set to `/var/imageregistry` to match the value set for the `mount_point` field in the `SiteConfig` CR.
70
+
71
+
+
72
+
[IMPORTANT]
73
+
====
74
+
Do not set `complianceType: mustonlyhave` for the `- fileName: ImageRegistryConfig.yaml` configuration. This can cause the registry pod deployment to fail.
75
+
====
76
+
77
+
. Commit the `PolicyGenTemplate` change in Git, and then push to the Git repository being monitored by the GitOps ZTP ArgoCD application.
69
78
70
79
.Verification
71
80
72
-
. Check that the `Config` CRD of the group `imageregistry.operator.openshift.io` instance is not reporting errors. Run the following command:
81
+
Use the following steps to troubleshoot errors with the local image registry on the managed clusters:
73
82
74
-
. Check that the `PersistentVolumeClaim` on the managed cluster is populated with data. Run the following command:
83
+
* Verify successful login to the registry while logged in to the managed cluster. Run the following commands:
75
84
76
-
. Check that the `registry*` pod is up correctly located under the `openshift-image-registry` namespace.
85
+
.. Export the managed cluster name:
86
+
+
87
+
[source,terminal]
88
+
----
89
+
$ cluster=<managed_cluster_name>
90
+
----
77
91
78
-
. Verify successful login to the registry with `podman`:
. Check for disk partitioning using `lsblk` to list your blocks:
106
+
.. Verify access to the image registry from the managed cluster. See "Accessing the registry".
107
+
108
+
* Check that the `Config` CRD in the `imageregistry.operator.openshift.io` group instance is not reporting errors. Run the following command while logged in to the managed cluster:
91
109
+
92
110
[source,terminal]
93
111
----
94
-
$ oc debug node/sno-1.example.com
112
+
$ oc get image.config.openshift.io cluster -o yaml
. When you enter the node, run the following command:
136
+
* Check that the `PersistentVolumeClaim` on the managed cluster is populated with data. Run the following command while logged in to the managed cluster:
137
+
+
138
+
[source,terminal]
139
+
----
140
+
$ oc get pv image-registry-sc
141
+
----
142
+
143
+
* Check that the `registry*` pod is running and is located under the `openshift-image-registry` namespace.
144
+
+
145
+
[source,terminal]
146
+
----
147
+
$ oc get pods -n openshift-image-registry | grep registry*
* For more information about configuring GitOps ZTP on the hub cluster, see xref:../../scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-hub-cluster[Preparing the hub cluster for ZTP]
53
-
54
-
* For more information about container image registries, see xref:../../registry/index.adoc#registry-overview[{product-title} registry overview].
57
+
* xref:../../registry/accessing-the-registry.adoc#accessing-the-registry[Accessing the registry]
0 commit comments