인그레스 오류입니다: ERRODEG

가상 프라이빗 클라우드 클래식 인프라 Satellite

인그레스 오퍼레이터가 성능 저하 상태일 때 ERRIODEG 오류를 해결하는 방법을 알아보세요.

ibmcloud oc ingress status-report ignored-errors add 명령을 사용하여 무시된 오류 목록에 오류를 추가할 수 있습니다. 무시된 오류는 여전히 ibmcloud oc ingress status-report get 명령의 출력에 표시되지만 전체 Ingress 상태를 계산할 때는 무시됩니다.

ibmcloud oc ingress status-report get 명령을 실행하여 클러스터의 Ingress 컴포넌트의 상태를 확인할 때 다음과 유사한 오류가 표시됩니다.

The Ingress Operator is in a degraded state (ERRIODEG).

Ingress 연산자는 Ingress 제어기의 상태를 검사하고 검사가 실패하면 하급 상태가 됩니다.

노드에 과부하가 걸리지 않았는지 확인하십시오. 부하가 과중한 노드는 Ingress Operator의 상태 확인이 실패하는 원인이 될 수 있습니다.

CPU 및 메모리 여유 용량이 충분한지 확인하려면 다음 명령을 실행하십시오.

kubectl top nodes

ingress ( ClusterOperator )에 대한 자세한 내용을 확인하고, 오류 메시지에 따라 해당 단계를 완료하십시오.

ingress ClusterOperator의 상태를 확인하십시오. DEGRADED 열에 False 가 표시되면 10-15분동안 대기하여 Ingress 상태 경고가 사라지는지 확인하십시오. 그렇지 않으면 MESSAGE 열의 메시지를 기반으로 하는 문제점 해결 단계를 진행하십시오.

oc get clusteroperator ingress

하나 이상의 상태 조건이 사용 불가능을 표시합니다. DeploymentAvailable=False

  1. 클러스터에 두 명 이상의 작업자가 있는지 확인하십시오. 자세한 정보는 클래식 클러스터에 작업자 노드 추가 또는 VPC 클러스터에 작업자 노드 추가 를 참조하십시오.
  2. 클러스터 작업자의 상태가 양호한지 확인하십시오. 그렇지 않으면 Ingress 제어기 팟 (Pod) 을 스케줄링할 수 없습니다. 자세한 정보는 작업자 노드 상태를 참조하십시오.

하나 이상의 상태 조건이 사용 불가능을 표시합니다. LoadBalancerReady=False

  1. VPC 전용: LBaaS 인스턴스 할당량에 도달하지 않았는지 확인하십시오. 자세한 정보는 할당량 및 서비스 한계 및 ibmcloud is load-balancers 명령 을 참조하십시오.
  2. 클러스터 마스터의 상태가 양호한지 확인하십시오. 자세한 정보는 마스터 상태 검토 를 참조하십시오.
  3. ibmcloud oc cluster master refresh 명령 를 실행하여 클러스터 마스터를 새로 고치십시오.

하나 이상의 다른 상태 조건이 성능 저하 상태를 표시합니다. CanaryChecksSucceeding=False

  1. Red Hat OpenShift 클러스터에 액세스하십시오.

  2. Ingress 하위 도메인에 대해 올바른 LoadBalancer 서비스 주소가 등록되었는지 확인하십시오.

    1. ibmcloud oc cluster get 명령 를 실행하여 Ingress 하위 도메인을 확인하십시오.
    2. ibmcloud oc nlb-dns get 명령 를 실행하여 등록된 주소를 확인하십시오.
    3. oc get services -n openshift-ingress 명령을 실행하여 실제 로드 밸런서 주소를 가져오십시오.
    4. 등록된 주소와 실제 주소를 비교하고 다른 경우 서브도메인을 업데이트하십시오. VPC: ibmcloud oc nlb-dns replace 명령 를 실행하여 현재 주소를 대체하십시오. 클래식: ibmcloud oc nlb-dns rm classic 명령 를 실행하여 현재 등록된 주소를 제거한 후 ibmcloud oc nlb-dns add 명령 를 사용하여 새 주소를 추가하십시오. Satellite: 실제 주소는 구성에 따라 달라집니다. 워커 노드를 외부 로드 밸런서를 통해 노출하는 경우 해당 로드 밸런서 주소를 등록하고, 그렇지 않은 경우 openshift-ingress 네임스페이스 내의 router-external-default 서비스에 할당된 IP 주소를 등록하십시오(주소를 확인하려면 oc get services -n openshift-ingress router-external-default -o yaml 명령어를 사용하십시오). ibmcloud oc nlb-dns rm classic 명령 를 실행하여 현재 등록된 주소를 제거한 후 ibmcloud oc nlb-dns add 명령 을 사용하여 새 주소를 추가하십시오.

  3. VPC 전용: 카나리아 상태 검사 트래픽은 클러스터의 작업자 노드 중 하나에서 시작됩니다.

    • 상태 검사 트래픽은 클러스터의 작업자 노드 중 하나에서 시작됩니다. 공용 서비스 엔드포인트가 있는 클러스터의 경우 트래픽은 VPC 로드 밸런서 인스턴스의 공용 부동 IP 주소로 경로 지정되므로 모든 작업자 서브넷에 Public Gateway 가 연결되어 있어야 합니다. 사설 서비스 엔드포인트만 있는 클러스터의 경우 트래픽이 VPC 로드 밸런서의 VPC 서브넷 IP 주소로 경로 지정되므로 Public Gateway 가 필요하지 않습니다. 공용 서비스 엔드포인트가 있는 클러스터의 경우:
      1. ibmcloud is public-gateways 를 실행하여 퍼블릭 게이트웨이를 확인하십시오.
      2. ibmcloud is subnets 를 실행하여 서브넷을 확인하십시오.
      3. 모든 서브넷에 대해 ibmcloud is subnet <subnet-id> 를 실행하여 퍼블릭 게이트웨이가 있을 때마다 확인하십시오.
        1. 서브넷에 연결된 퍼블릭 게이트웨이가 없는 경우 하나를 연결해야 합니다. 자세한 정보는 퍼블릭 게이트웨이 작성 을 참조하십시오.
    • VPC 로드 밸런서가 클러스터의 작업자 노드 이외의 서브넷에 있는 경우, 작업자 서브넷에서 수신되는 트래픽을 허용하도록 VPC 로드 밸런서 서브넷에 연결된 보안 그룹을 업데이트해야 합니다.
    • 자세한 정보는 가상 프라이빗 클라우드에서 Red Hat OpenShift 클러스터 작성, VPC 서브넷 구성 및 VPC 보안 그룹 작성 및 관리 를 참조하십시오.

  4. UDP 및 TCP 을 통해 전송되는 카나리아 트래픽이나 DNS 트래픽을 차단하는 방화벽 규칙이 없는지 확인하십시오. VPC: 카나리아 트래픽은 워커 노드 중 하나에서 시작되어 VPC Public Gateway 를 통과한 후 VPC 로드 밸런서 인스턴스의 공용 측으로 도달합니다. 이 통신을 허용하도록 VPC 보안 그룹을 구성하십시오. 자세한 내용은 기본 클러스터 VPC 네트워킹을 통한 보안 이해하기 및 VPC 보안 그룹 만들기 및 관리하기를 참조하세요. 클래식: 카나리아 트래픽은 워커 노드 중 하나의 공용 IP 주소에서 시작하여 클래식 로드 밸런서의 공용 IP 주소로 도착합니다. 이 통신을 허용하도록 네트워크 정책을 구성하십시오. 자세한 내용은 클래식 클러스터에서 네트워크 정책으로 트래픽 제어하기를 참조하세요.

다음 단계

  1. 30분 동안 기다린 후 oc get clusteroperator ingress 명령을 실행하고 MESSAGE 컬럼을 다시 확인하십시오.
  2. 다른 오류 메시지가 표시되면 문제점 해결 단계를 반복하십시오.
  3. 문제가 계속되면 지원에 문의하십시오. 지원 케이스 열기 케이스 세부사항에는 관련 로그 파일, 오류 메시지 또는 명령 출력이 포함되어야 합니다.