# Container Registry FAQ This page lists some common issues and solutions when using the container registry. ## Middleware deployment is not available in the DCE 5.0 standard package The DCE 5.0 standard package does not include middleware. Middleware is only available in the Platinum package. ## How to verify if the configured middleware network is connectable Log in to the target cluster where Harbor is deployed and execute the `ping` command on any node to test the connectivity to the middleware components. ## Private images not visible in the registry space list There is a bug in versions `v0.7.0-v0.7.3` and `v0.8.0` of the container registry system, which results in the inability to see private images. ## When using Minio deployed with middleware When using Minio deployed with middleware, you need to manually create buckets through the Minio management platform beforehand. ## Minimum supported version of Harbor for repository integration During repository integration, there are certain version requirements due to the use of Harbor's functionality. Currently, the known minimum supported version is `2.4.0`. Earlier versions will not be compatible. ## Offline environment image scanner failure The image scanner relies on vulnerability data, which is obtained by default from the [CVE official website](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=kubernetes). In a pure offline environment, vulnerability scanning cannot be performed, and the process will fail. ![trivy](https://docs.daocloud.io/daocloud-docs-images/docs/en/docs/kangaroo/images/trivy-nodb.png) ## Error occurs when creating Harbor after cluster verification passes in the first step Currently, only the existence of `CRD` is being verified in the cluster, and the `harbor-operator` service is not being checked. This may result in failures to create `Harbor` correctly when the `harbor-operator` service does not exist. ## Error occurs after executing `docker login {ip}` locally ```text Error response from daemon: Get "https://{ip}/v2/": x509: cannot validate certificate for {ip} because it doesn't contain any IP SANs ``` This error occurs because the `registry` is an `https` service that uses an unsigned or insecure certificate. To resolve this issue, add the corresponding IP to `"insecure-registries"` in the `/etc/docker/daemon.json` configuration file. ```json "insecure-registries": [ "{ip}", "registry-1.docker.io" ] ``` Then, restart the service with `systemctl restart docker`. ## Failed to start services when passwords contain special chars Failure to start services when creating Harbor and accessing external PG and Redis with passwords containing special characters (!@#$%^&*) Currently, passwords cannot contain special characters; otherwise, the services will fail to start. You can use a combination of uppercase and lowercase letters and numbers instead. ## Harbor Operator installation failed If the installation of `Harbor Operator` is unsuccessful, you should check the following: - Ensure that `cert-manager` has been successfully installed. - Verify that the `installCRDs` setting is set to `true`. - Confirm that the `helm` job for installing the `Harbor operator` was successful. ## Can I use redis cluster mode when creating a managed Harbor? Currently, `Harbor` does not support the use of `redis` cluster mode. ## Can private images be seen in a module other than container registry? The container registry strictly follows the authority of DCE 5.0. To view private registry space under the current tenant, users must belong to a specific tenant. Even administrators cannot view it without belonging to the tenant. ## Unable to query private images after binding to workspace After binding a private image to a workspace, the program executes several asynchronous logic processes, and it may not be immediately visible. The process duration is dependent on the system's speed and may take up to 5 minutes to appear. ## Managed Harbor accessible but status remains unhealthy Currently, the status on the managed Harbor page and the status of the registry integration are combined. When both statuses are healthy, the Harbor is considered healthy. It's possible that the managed `Harbor` is already accessible, but the state remains unhealthy. In this case, wait for a service detection cycle, which occurs every 10 minutes, and it will return to the original state after the cycle. ## The status of managed registry you created just now is unhealthy - A1: Incorrect user entries for the database, Redis, S3 storage, or other information may result in a connection failure. Troubleshoot by checking log files. You may notice that several core services have Pod startup failures. Review the logs to determine the cause of the failure. ```shell kubectl -n kangaroo-lrf04 get pods ``` ```none NAME READY STATUS RESTARTS AGE trust-node-port-harbor-harbor-chartmuseum-57fdfb9cdc-qznwc 1/1 Running 0 20h trust-node-port-harbor-harbor-core-855f8df46c-cgqb9 1/1 Running 0 20h trust-node-port-harbor-harbor-jobservice-6b958dbc57-ks997 1/1 Running 0 20h trust-node-port-harbor-harbor-portal-5cf6bf659b-kj6gd 1/1 Running 0 20h trust-node-port-harbor-harbor-registry-5ccbf457c5-qrtx5 2/2 Running 0 20h trust-node-port-harbor-harbor-trivy-dbdc8945-xh6rv 1/1 Running 0 20h trust-node-port-nginx-deployment-677c74576-7kmh4 1/1 Running 0 20h ``` - A2: If the troubleshooting in A1 is correct, check whether the `harborcluster` resource is healthy, and check the `harborcluster` resource status with the following command. ```shell kubectl -n kangaroo-lrf04 get harborclusters.goharbor.io ``` ```none NAME PUBLIC URL STATUS trust-node-port https://10.6.232.5:30010 healthy ``` - A3: If the troubleshooting in A2 is correct, check whether the `registrysecrets.kangaroo.io` resource is created and the status of `status` on the `kpanda-global-cluster` cluster. Tip: The default namespace is `kangaroo-system`. ```shell kubectl -n kangaroo-system get registrysecrets.kangaroo.io ``` ```none NAME AGE inte-bz-harbor-1 34d ``` ```shell kubectl -n kangaroo-system describe registrysecrets.kangaroo.io inte-bz-harbor-1 ``` !!! tip - The above A1 and A2 are all troubleshooting on the cluster hosting Harbor, and the target cluster can be viewed through the following page path: `registry Instance` -> `Overview` -> `Deployment Location`. - The above A3 was verified on `kpanda-global-cluster` cluster. ## Issue with registry space and storage after creating a Project or uploading an image If you have created a `Project` or uploaded an image, but found that there has been no increase in the registry space or available storage on the page, this might be due to the asynchronous nature of obtaining statistical information on the `managed Harbor` home page and registry integration details on the UI page. The data retrieval process can take up to `10` minutes, causing a certain delay before any changes are reflected. ## Registry integration status is unhealthy If you encounter an issue where the registry integration status is unhealthy, follow these steps: 1. First, check whether the instance is healthy. If it's not, then troubleshoot the instance. 2. If the instance is healthy, verify whether the resource `registrysecrets.kangaroo.io` on the `kpanda-global-cluster` cluster has been created or not. 3. Check the status of the resource `status` to identify the problem initially. **Note:** Ensure to check the default namespace, which is `kangaroo-system`. ```shell kubectl -n kangaroo-system get registrysecrets.kangaroo.io ``` ```none NAME AGE trust-test-xjw 34d ``` ```shell kubectl -n kangaroo-system get registrysecrets.kangaroo.io trust-test-xjw -o yaml ``` ```yaml apiVersion: kangaroo.io/v1alpha1 kind: RegistrySecret metadata: name: trust-test-xjw namespace: kangaroo-system spec: .... status: state: lastTransitionTime: "2023-03-29T03:27:31Z" message: 'Get "https://harbor.kangaroo.daocloud.io": dial tcp: lookup harbor.kangaroo.daocloud.io on 10.233.0.3:53: no such host' reason: RegistryHealthCheckFail status: "False" type: HealthCheckFail ``` ## After integrating the registry, it cannot be viewed in the instance list page of the image Please confirm if the resources integrated into the registry are healthy. If they are unhealthy, they won't appear in the instance list on the image page. For the confirmation method, please refer to [Unhealthy Confirmation Method after Registry Integration](#registry-integration-status-is-unhealthy). ## Selecting a Private `Project` Image in the `Kpanda` Image Selector results in a failed image pull prompt during deployment - A1: If you can see the private `Project` in the image selector, which means that `Project` and `Workspace` have already been bound. At this point, check if a `secret` named `registry-secret` has been generated in the target cluster's `namespace` for image deployment. ```shell kubectl -n default get secret registry-secret ``` ```none NAME TYPE DATA AGE registry-secret kubernetes.io/dockerconfigjson 1 78d ``` - A2: If you confirm that the `secret` named `registry-secret` has been generated, you need to confirm whether the `dockerconfigjson` in the `secret` is correct. ```shell kubectl get secret registry-secret -o jsonpath='{.data.*}'| base64 -d | jq ``` ```json { "auths": { "127.0.0.1:5000": { "auth": "YWRtaW46SGFyYm9yMTIzNDU=" } } } ``` ```shell echo "YWRtaW46SGFyYm9yMTIzNDU=" | base64 -d ``` ```none admin:Harbor12345 ```