---
name: containers-ts-ingress-erradruh
title: 'Ingress error: ERRADRUH'
description: '[Virtual Private Cloud] [Classic infrastructure]'
last-updated: 2026-07-30
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/containers?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Ingress error: ERRADRUH
{: #ts-ingress-erradruh}
{: troubleshoot}
{: support}

[Virtual Private Cloud]{: tag-vpc} [Classic infrastructure]{: tag-classic-inf}

You can use the `ibmcloud ks ingress status-report ignored-errors add` command to add an error to the ignored-errors list. Ignored errors still appear in the output of the `ibmcloud ks ingress status-report get` command, but are ignored when calculating the overall Ingress Status.
{: tip}

When you check the status of your cluster's Ingress components by running the `ibmcloud ks ingress status-report get` command, you see an error like the following example.
{: tsSymptoms}

```sh
One or more ALB pods are not in the running state (ERRADRUH).
```
{: screen}

One or more ALBs have replicas that are not running.
{: tsCauses}

Complete the following steps to verify your cluster setup.
{: tsResolve}

1. List your ALB pods.
    ```sh
    kubectl get pods -n kube-system | grep -E "public-cr|private-cr"
    ```
    {: pre}

    Example output
    ```sh
    public-crcn0hav5w07nccmt0iufg-alb1-7df65f554f-nkgzl   1/1     Running   0          30h
public-crcn0hav5w07nccmt0iufg-alb1-7df65f554f-qk97w   0/1     Pending   0          30h
    ```
    {: screen}

1. Describe the ALB pods that are not running and review the `Events` section.
    ```sh
    kubectl describe pod POD -n kube-system
    ```
    {: pre}


1. If you notice scheduler problems, complete the following steps:
    1. List your ALBs using the **`ibmcloud ks ingress alb ls`** [command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&format=markdown#ingress-alb-ls-cli).
    1. List your workers using the **`ibmcloud ks worker ls`** [command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&format=markdown#worker-ls-cli).
    1. **Classic clusters**: Ensure you have at least two worker nodes in the VLANs where your ALBs are deployed. See [Adding worker nodes and zones to clusters](https://cloud.ibm.com/docs/containers?topic=containers-add-workers-classic&format=markdown).
    1. **VPC clusters**: Ensure you have at least two worker nodes in the zones where your ALBs are deployed. See [Adding worker nodes and zones to clusters](https://cloud.ibm.com/docs/containers?topic=containers-add-workers-vpc&format=markdown).
    1. Ensure that your workers are healthy. For more information, see [Worker node states](https://cloud.ibm.com/docs/containers?topic=containers-worker-node-state-reference&format=markdown).
    1. Ensure that your nodes are not tainted or cordoned. For more information, see [Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/){: external} and [Safely drain a node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/){: external}.

1. If you notice pod restarts, complete the following steps.
    1. Get the logs for the failing pod.
        ```sh
        kubectl logs --previous -n kube-system <POD NAME>
        ```
        {: pre}

    1. Review the logs and adjust the Ingress resource configurations or the Ingress ConfigMap in the `kube-system` namespace. For more information, see the NGINX Ingress [Annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/) and [ConfigMap](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/).

1. Wait a few minutes, and verify that the failing pods are now running.

1. If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/support?topic=support-using-avatar&format=markdown). In the case details, be sure to include any relevant log files, error messages, or command outputs.