Custom resources

Sometimes, you might create Gloo resources and expect a certain result, such as a policy applying to traffic or a gateway listening for traffic. If you do not get the expected result, try the following general debugging steps.

1. Check the Gloo resources in your management and remote clusters. You might find the following commands useful.

   • All Gloo resources
   • State of all Gloo resources
   • Admin resources
   • Policies
   • Networking resources
   • GraphQL resources
   • Portal resources
   • Istio Lifecycle Manager resources

   You can list all of the Gloo custom resource.

   kubectl get solo-io -A
   

   You can also export them to a YAML file and open with your favorite editor to search or update the configurations.

   kubectl get solo-io -A -o yaml > gloo-resources.yaml
   

   You can use another tool like grep to search for certain information within all the Gloo resources, such as to verify that the resources are all ACCEPTED.

   kubectl get solo-io -A -o yaml | grep 'state'
   

   kubectl get apidocs,workspaces,workspacesettings,roottrustpolicies,dashboards,kubernetesclusters -A
   

   kubectl get ratelimitserverconfigs,RatelimitConfigs,ratelimitserversettings,ratelimitclientconfigs,ratelimitpolicies,wasmdeploymentpolicies,externalendpoints,externalservices,accesslogpolicies,failoverpolicies,faultinjectionpolicies,outlierdetectionpolicies,jwtpolicies,wafpolicies,retrytimeoutpolicies,accesspolicies,connectionpolicies,corspolicies,csrfpolicies,dlppolicies,extauthpolicies,extauthserver,mirrorpolicies,transformationpolicies,authorizationpolicies,headermanipulationpolicies,proxyprotocolpolicies,trimproxyconfigpolicies -A
   

   kubectl get virtualgateways,routetables,virtualdestinations,virtualservices,externalservices,externalendpoints -A
   

   kubectl get apidocs,graphqlresolvermaps,graphqlschemas,graphqlstitchedschemas -A
   

   kubectl get apidocs,ratelimitserverconfigs,RatelimitConfigs,ratelimitserversettings,ratelimitclientconfigs,ratelimitpolicies,extauthpolicies,extauthserver,routetables,portals,portalgroups,virtualgateways -A
   

   kubectl get gatewaylifecyclemanagers,istiolifecyclemanagers -A
   

2. Describe the resource, and look at the status, events, and other areas for more information.

   kubectl describe virtualgateway $GATEWAY_NAME -n $NAMESPACE
   

3. If you see an error or warning in the global status, launch the Gloo UI, find the resource, and click View YAML. You can review workspace and cluster-specific details about the status in the UI.

4. Verify that the resource is in the workspace that you expect it to be in. You can check the resource's namespace against the namespaces that are included in the workspace resource on the management cluster.

   kubectl describe workspace -n gloo-mesh
   

   In the output, check the Status sections to make sure that the workspace includes each cluster and namespace that you want to be part of the workspace.

   Status:
     Clusters:
       Name:  cluster1
       Namespaces:
         bookinfo
         default
         gloo-mesh
   ...
   

5. Verify that related resources are in the same workspace, or are exported and imported appropriately. For example, your virtual gateway must be in the same workspace as the route table and policy that you want it to work with.

6. If applicable, verify that the ports are set up appropriately on the resource and the backing service. For example, your virtual gateway might listen on port 80, which matches the port of the Kubernetes service for the gateway deployment.

7. Check the logs of the management server in the management cluster for accepted or translated resource messages.

8. Check the logs of agent pods on the remote cluster that the resource is created in.

9. If you upgraded Gloo versions recently, make sure that you applied the CRDs as part of the upgrade.

10. If you continue to see error messages that indicate state reconciliation issues, try restarting the Redis pod.