You can also view the resources with the gpc-addons command for more
information.
Check the AddOnSet resources:
kubectlgetAddOnSet-A
If the control plane bootstrap does not finish processing after the creation
of the org infrastructure cluster, such as during a resource pivot, export the
kubeconfig file manually:
To troubleshoot the cluster creation process, follow these steps:
Examine the current stage of the cluster and check whether the object
Harbor-operator or Harbor exists and check its status from the KIND
cluster in the AddOnSet resource by running the following command:
kubectlgetaddonset-nfleet-rootroot-admin-oyaml
After running this command, find the current stage in status.currentStage.
From the org infrastructure cluster, check the resources in the harbor-system
namespace. If you deployed the HarborCluster object through the
kubectl get harborcluster harbor -n harbor-system command, that indicates
the installation has moved to the second stage, the Harbor stage.
Inspect the status field in the HarborCluster object:
kubectl-nharbor-systemgetharborclusterharbor
If the status indicates healthy, verify its functionality through the web
portal by using the docker push command.
Access the web portal at the reported URL. For example:
https://10.200.0.36:10443.
In the bootstrapper, run the command docker push.
If the status is unhealthy, review the details from the status conditions
by executing the following entry:
These steps only need to be performed if the harbor-system resources do not
have a status of healthy. To check the status of your harbor-system
resources, see Troubleshoot cluster creation.
Evaluate the harbor-system namespace resources:
kubectlgetall-nharbor-system
Check the status for resources related to the Harbor operator, including the
PostgreSQL and Redis operators that are built as sub-charts during the
second stage of the org infrastructure cluster creation process. Validate the
following operators are in the Running state:
Verify the resources for PostgreSQL, Redis, and Harbor components all have a
state of healthy. If some Pods are not in a healthy state, review the
details from the failing Pod using these commands:
kubectlgetpod-owide
kubectldescribepod
You can also view the logs from the managing operator using this command:
To check the PostgreSQL resource, view
statefulset/postgresql-harbor-system-harbor.
To check the Redis resource, view the:
Redis instance:statefulset/rfr-harbor-redis
Redis sentinel:deployment/rfs-harbor-redis
The Harbor core components only deploy when the two components are ready.
If some Harbor core component Pods fail, review the logs from the failing
Pod. In some cases, there is a communication issue with PostgreSQL or Redis
instances.
For example, if the Harbor core component cannot connect to PostgreSQL or
Redis with the provided credentials, there is a potential issue with the
Harbor Operator, which is responsible for setting up the credentials before
deploying Harbor core components.
Check the istio status
To verify the Pod status is istio, such as istio-system and
service/istio-ingressgateway, check whether port 10443 is exposed.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eThis guide provides troubleshooting steps for common software provisioning issues, specifically focusing on control plane bootstrapping and cluster creation.\u003c/p\u003e\n"],["\u003cp\u003eTo troubleshoot control plane bootstrapping, you can examine the \u003ccode\u003eanthos-cluster-operator\u003c/code\u003e Pod and inspect both \u003ccode\u003eAddOn\u003c/code\u003e and \u003ccode\u003eAddOnSet\u003c/code\u003e resources within the KIND cluster.\u003c/p\u003e\n"],["\u003cp\u003eCluster creation issues can be diagnosed by checking the \u003ccode\u003eHarbor-operator\u003c/code\u003e status and then the \u003ccode\u003eHarborCluster\u003c/code\u003e status within the \u003ccode\u003eharbor-system\u003c/code\u003e namespace, utilizing commands to check if the cluster is healthy or unhealthy.\u003c/p\u003e\n"],["\u003cp\u003eIf the \u003ccode\u003eharbor-system\u003c/code\u003e resources are unhealthy, you can evaluate the namespace resources to check the status of the Harbor operator, PostgreSQL, and Redis operators and components and determine whether or not they are in a running or healthy state.\u003c/p\u003e\n"],["\u003cp\u003eTo ensure the istio status is healthy, you should verify the Pod status is \u003ccode\u003eistio\u003c/code\u003e and that the correct ports, such as port 10443, are exposed.\u003c/p\u003e\n"]]],[],null,["# Software provisioning troubleshooting\n\nThis page details how to troubleshoot common software provisioning issues you\nmight face.\n\nTroubleshoot control plane bootstrapping\n----------------------------------------\n\nTo troubleshoot the bootstrap control plane process, check the following\nresources within the KIND cluster:\n\n1. Examine the `anthos-cluster-operator` Pod:\n\n kubectl logs deployment/anthos-cluster-operator -c operator -n kube-system\n\n2. Inspect the `AddOn` resources:\n\n kubectl get AddOn -A\n\n You can also view the resources with the `gpc-addons` command for more\n information.\n3. Check the `AddOnSet` resources:\n\n kubectl get AddOnSet -A\n\n If the control plane bootstrap does not finish processing after the creation\n of the org infrastructure cluster, such as during a resource pivot, export the\n `kubeconfig` file manually: \n\n kubectl get secret root-admin-kubeconfig -n root -o jsonpath=\"{.data.value}\" | base64 -d \u003e /root/path/to/root-admin-kubeconfig.yaml\n\nTroubleshoot cluster creation\n-----------------------------\n\nTo troubleshoot the cluster creation process, follow these steps:\n\n1. Examine the current stage of the cluster and check whether the object\n `Harbor-operator` or Harbor exists and check its status from the KIND\n cluster in the `AddOnSet` resource by running the following command:\n\n kubectl get addonset -n fleet-root root-admin -o yaml\n\n After running this command, find the current stage in `status.currentStage`.\n2. From the org infrastructure cluster, check the resources in the `harbor-system`\n namespace. If you deployed the `HarborCluster` object through the\n `kubectl get harborcluster harbor -n harbor-system` command, that indicates\n the installation has moved to the second stage, the Harbor stage.\n\n3. Inspect the `status` field in the `HarborCluster` object:\n\n kubectl -n harbor-system get harborcluster harbor\n\n If the status indicates `healthy`, verify its functionality through the web\n portal by using the `docker push` command.\n4. Access the web portal at the reported URL. For example:\n `https://10.200.0.36:10443`.\n\n5. In the bootstrapper, run the command `docker push`.\n\n If the status is `unhealthy`, review the details from the status conditions\n by executing the following entry: \n\n kubectl -n harbor-system get harborcluster harbor -o yaml\n\n If the status shows `healthy`, navigate to the\n [Check the istio status](#check-istio-status) section. If the status does\n not show `healthy`, continue to the next section,\n [Evaluate Harbor namespace resources](#evaluate-harbor-namespace-resources).\n\n### Evaluate Harbor namespace resources\n\nThese steps only need to be performed if the `harbor-system` resources do not\nhave a status of `healthy`. To check the status of your `harbor-system`\nresources, see [Troubleshoot cluster creation](#troubleshoot-cluster-creation).\n\n1. Evaluate the `harbor-system` namespace resources:\n\n kubectl get all -n harbor-system\n\n2. Check the status for resources related to the Harbor operator, including the\n PostgreSQL and Redis operators that are built as sub-charts during the\n second stage of the org infrastructure cluster creation process. Validate the\n following operators are in the `Running` state:\n\n deployment/harbor-operator-harbor-operator\n deployment/harbor-operator-postgres-operator\n deployment/harbor-operator-redisoperator\n\n3. Verify the resources for PostgreSQL, Redis, and Harbor components all have a\n state of `healthy`. If some Pods are not in a `healthy` state, review the\n details from the failing Pod using these commands:\n\n kubectl get pod -o wide\n kubectl describe pod\n\n You can also view the logs from the managing operator using this command: \n\n kubectl logs -f deploy/harbor-operator-postgres-operator\n\n4. To check the PostgreSQL resource, view\n `statefulset/postgresql-harbor-system-harbor`.\n\n5. To check the Redis resource, view the:\n\n 1. Redis instance:`statefulset/rfr-harbor-redis`\n 2. Redis sentinel:`deployment/rfs-harbor-redis`\n\n The Harbor core components only deploy when the two components are ready.\n\n If some Harbor core component Pods fail, review the logs from the failing\n Pod. In some cases, there is a communication issue with PostgreSQL or Redis\n instances.\n\n For example, if the Harbor core component cannot connect to PostgreSQL or\n Redis with the provided credentials, there is a potential issue with the\n Harbor Operator, which is responsible for setting up the credentials before\n deploying Harbor core components.\n\n### Check the istio status\n\nTo verify the Pod status is `istio`, such as `istio-system` and\n`service/istio-ingressgateway`, check whether port 10443 is exposed."]]
