Skip to main content

Troubleshooting

  1. Why are my requests reaching the baseline version of the microservice and not the one in my Sandbox or RouteGroup?

    1. In-cluster routing is not set up correctly: The most common cause of this issue is that your in-cluster routing setup is not set up correctly. When the request traverses your microservices-based application, it relies on in-cluster routing provided either by Signadot's DevMesh or by using a service mesh like Istio to target a sandboxed service. To understand what Preview URLs do under the hood, see Preview Endpoint Targets.

    2. Lack of context propagation via microservice: If you have verified that the Signadot sidecar (or the service mesh sidecar) already exists and is correctly configured, another potential cause of this issue may be the lack of context propagation through your application. This context propagation is commonly implemented using OpenTelemetry and involves passing headers received on the incoming end of the request to the outgoing request made to a subsequent microservice.

  2. Why are my Sandboxes or RouteGroups not applying routing?

    If Sandboxes or RouteGroups stay NotReady because routing cannot be applied, check whether the operator's controller manager is resource-constrained. Reconciliation log messages such as couldn't reconcile children, object is being deleted ... already exists, or istioroutes ... not found can appear during normal operation, but a sustained increase together with a growing workqueue can indicate that the controller is falling behind.

    Check controller resource usage and logs:

    kubectl logs -n <operator-namespace> deploy/<controller-manager-deployment> -c manager --since=1h
    kubectl top pods -n <operator-namespace>

    Also review controller-runtime workqueue metrics from the controller manager metrics service; see Monitoring.

    If CPU is near its limit, memory is high, or the workqueue keeps growing, increase controllerManager.resources in your Helm values. For larger installations, set a higher CPU limit so the controller can handle short bursts:

    controllerManager:
    resources:
    requests:
    cpu: 500m
    memory: 1Gi
    limits:
    cpu: "2"
    memory: 1Gi

    Then apply the values with Helm:

    helm upgrade <release-name> <chart-name> --reuse-values -f values.yaml