개인 VPC 클러스터: OpenShift 콘솔에 연결할 수 없는 이유는 무엇입니까?

비공개 서비스 엔드포인트만 있는 클러스터에서 OpenShift 콘솔에 연결하는 문제를 해결하세요.

이 문제 해결 안내서의 정보는 개인 서비스 엔드포인트만 있는 VPC 클러스터에 관한 것입니다.

1. 클러스터 연결 흐름 이해하기

다음 다이어그램은 개인 서비스 엔드포인트가 있는 VPC 클러스터가 OpenShift 웹 콘솔에 연결되는 연결 흐름을 보여줍니다. 이 다이어그램은 클러스터에 기본 설정( OAuth )이 있다고 가정합니다. 문제 해결에 필요한 단계를 더 잘 이해하기 위해 이 다이어그램과 다음 설명을 검토하십시오.

OpenShift 개인 서비스 엔드포인트가 있는 VPC 클러스터의 웹 콘솔 연결 흐름 개인 서비스 엔드포인트가 있는 VPC 클러스터의 웹 콘솔 연결 흐름. — OpenShift

웹 브라우저는 VPN을 통해 클러스터 마스터 API 서버에 연결합니다. 서명된 인증서가 교환되고, 리디렉션은 웹 브라우저가 대신 OpenShift 콘솔 로드 밸런서에 연결하도록 지시합니다.
(a) 웹 브라우저는 VPN을 통해 OpenShift 콘솔 로드 밸런서에 연결하여 OpenShift 콘솔을 노출합니다. (b) 이 요청은 두 개의 openshift-console pod 중 하나에 전송됩니다.
Openshift-console 파드는 클러스터 마스터 OAuth 서버 포트에 연결하여 연결이 이미 인증되었는지 확인합니다. 요청이 이미 인증된 경우 OpenShift 웹 콘솔에 대한 연결이 완료되어 웹 콘솔에 액세스할 수 있습니다. 요청이 인증되지 않으면 사용자는 클러스터 마스터의 클러스터 OAuth 서비스로 리디렉션됩니다.
웹 브라우저는 VPN을 통해 클러스터의 OAuth 서버 포트에 연결되며, 이 포트는 클라이언트를 IAM으로 리디렉션합니다.
웹 브라우저는 공용 네트워크를 통해 IAM에 연결합니다. 사용자는 비밀번호를 입력하고, 필요한 경우, 2FA 인증을 거칩니다. 이 단계가 성공하면 사용자는 클러스터의 OAuth 서버로 다시 리디렉션됩니다.
웹 브라우저는 VPN을 통해 클러스터의 OAuth 서버 포트에 다시 연결합니다. 연결이 OpenShift 콘솔 부하 분산 장치로 다시 리디렉션됩니다.
웹 브라우저는 VPN을 통해 OpenShift 콘솔 로드 밸런서에 연결되어 OpenShift 콘솔을 노출시킵니다. 이 요청은 두 개의 오픈시프트 콘솔 포드 중 하나로 전송되며, 이 포드는 다시 클러스터 마스터 OAuth 서버 포트에 연결하여 연결이 이미 인증되었는지 확인합니다. 사용자가 비밀번호와 2FA 인증을 입력하면 인증이 확인되고 사용자는 OpenShift 콘솔 기본 웹 페이지에 연결됩니다.

2. VPC와 클러스터 구성을 확인하세요

VPC와 클러스터가 제대로 구성되어 있는지 확인하십시오. 잘못된 설정으로 인해 OpenShift 웹 콘솔에 액세스하지 못할 수 있습니다.

웹 브라우저가 클러스터와 동일한 VPC 내에 있거나 해당 VPC에 VPN으로 연결된 클라이언트 시스템에서 실행되고 있는지 확인하십시오. OpenShift 의 콘솔은 VPC의 사설 네트워크에서만 접근할 수 있는 사설 VPC 로드 밸런서에 의해 노출됩니다.
클라이언트 시스템이 IAM용 공공 서비스 엔드포인트에 액세스할 수 있는지 확인하십시오. 이 엔드포인트는 iam.cloud.ibm.com 및 login.ibm.com 를 통해 액세스할 수 있습니다.
버전을 실행하는 클러스터의 경우 4.13:
- 클러스터가 기본 Oauth 구성( 4.13 )을 사용하거나 Oauth에 VPE 게이트웨이를 사용하도록 클러스터를 설정한 경우, 클라이언트가 VPC에 대한 개인 DNS를 사용하고 있고, 이 DNS 트래픽이 VPN을 통해 VPC로 라우팅되는지 확인하십시오. 개인 DNS는 일반적으로 161.26.0.7 및 161.26.0.8 입니다. 사용자 지정 DNS 확인자를 사용하지 않는 한. 이는 공용 DNS에 존재하지 않는 VPC( apiserver )와 VPC( Oauth )의 VPE 게이트웨이를 VPC의 사설 DNS에서 찾을 수 있도록 하기 위해 필요합니다.
지원되는 버전 이외의 버전을 실행하는 클러스터의 경우 4.13:
- 기본 Oauth 클러스터 설정을 사용하는 경우, 모든 166.8.0.0/14 트래픽이 동일한 VPN 또는 IBM Cloud 에 연결하는 다른 VPN을 통해 라우팅되도록 VPN 구성에 경로가 있는지 확인하십시오. 클러스터의 API 서버 및 OAuth 서버 포트에 연결하는 데 필요합니다.

3. 클러스터 데이터 수집

문제 해결에 필요한 클러스터 정보를 수집하려면 다음 단계를 따르십시오. 이 명령으로 수집한 결과물은 이후 단계에서 사용됩니다.

클러스터 API 서버 URL 를 찾으십시오. 이후의 명령어에서 이 " URL "는 " ${CLUSTER_APISERVER_URL} "로 불립니다.

ibmcloud ks cluster get -c CLUSTER_ID 명령을 실행하십시오.

    ibmcloud oc cluster get -c CLUSTER_ID
    ```
2. 출력물의 " `Master` " 섹션에서 " `URL` "를 찾습니다. URL 는 다음과 같은 형식이어야 합니다: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<YYYYY>`.

클러스터 찾기 OAuth URL. 이후의 명령어에서 이 " URL "는 " ${CLUSTER_OAUTH_URL} "로 불립니다.

kubectl get --raw /.well-known/oauth-authorization-server | grep issuer 명령을 실행하십시오. ibmcloud oc cluster get -c CLUSTER_ID 를 사용하지 마십시오. 이 명령은 다른 URL 를 반환할 수 있습니다.

    kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
    ```
2. 출력물에서 다음 형식 중 하나를 가진 ' URL '를 찾습니다.
    - VPE 게이트웨이를 사용하지 않는 경우 OAuth: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
    - VPE 게이트웨이를 사용하는 경우 OAuth: `https://<CLUSTERID>.vpe.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.

Ingress 하위 도메인을 찾습니다. 이후의 명령에서 이 하위 도메인은 ${CONSOLE_LOAD_BALANCER} 로 참조됩니다.

ibmcloud oc cluster get -c CLUSTER_ID 명령을 실행하십시오.

    ibmcloud oc cluster get -c CLUSTER_ID
    ```
2. 출력물에서 다음 형식과 일치하는 하위 도메인을 찾습니다: `<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud`. 사용자 지정 Ingress 하위 도메인을 구성한 경우, 형식이 사용자 지정 구성과 일치한다는 점에 유의하시기 바랍니다.

4. 연결 확인 및 문제 해결

연결 흐름에 설명된 연결을 확인하려면 다음 단계를 따르십시오. 연결에 문제가 있는 경우, 이 정보를 사용하여 문제를 해결하십시오.

Ingress가 정상이고 라우터와 콘솔 포드가 정상인지 확인하십시오.

명령을 실행합니다.

    ibmcloud oc cluster get -c CLUSTERID
    ibmcloud oc ingress status-report get -c CLUSTERID
    ```
2. 출력 화면에 오류 상태가 표시되면, [Ingress 문제 해결 문서를](/docs/openshift?topic=openshift-ingress-status) 참고하여 문제를 해결하십시오.

OpenShift 클러스터 운영자가 정상적으로 작동하는지 확인하십시오.

명령을 실행하십시오.

    oc get clusteroperators
    ```
2. 출력 결과에서 어떤 운영자도 건강하지 않거나 현재 버전에서 실행되지 않는 것으로 표시되면, [OpenShift 클러스터 버전 문제 해결 문서를](/docs/openshift?topic=openshift-ts-cluster-version-downlevel) 사용하여 문제를 해결하십시오. 또는, IBM 와 Red Hat 문서를 검색하여 표시된 특정 오류를 찾을 수 있습니다.
3. 콘솔 운영자가 특별히 정상적이지 않은 경우, `openshift-console/console...` 및 `openshift-console-operator/console-operator...` 파드 로그에서 보안 그룹, ACL 또는 DNS 사용자 정의로 인해 파드가 OAuth 포트 또는 OpenShift 콘솔 URL 에 연결되지 못하는지 확인한다. 보안 그룹, ACL 또는 DNS가 연결을 차단하는 방식으로 구성되어 있을 수 있습니다.

클러스터 마스터 API 서버에 연결이 성공했는지 확인합니다.

명령을 실행하십시오. 이전 단계에서 찾은 클러스터 API 서버 URL 를 지정합니다.

    curl -k -vvv ${CLUSTER_APISERVER_URL}/version
    ```
2. 연결에 실패한 경우, 다음 사항을 확인하고 발견된 문제를 해결하십시오.
    1. `ibmcloud oc cluster get -c <CLUSTER-ID>` 명령을 실행하여 클러스터 마스터가 정상 작동하는지 확인하십시오. 클러스터 마스터 문제 해결에 대한 정보는 [마스터 건강 상태 검토를](/docs/openshift?topic=openshift-debug_master) 참조하십시오.
    2. URL 의 호스트 이름 부분이 DNS를 통해 확인되는지 확인하십시오. `dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)` 명령어를 사용하고 클러스터 API 서버 URL 를 지정합니다.
    3. VPN을 통해 클러스터 API 서버 URL 에 연결할 수 있는 경로가 있는지 확인하십시오.
    4. 클러스터 apiserver URL 에 클러스터 ID가 포함되어 있다면(클러스터가 클러스터 apiserver에 연결하기 위해 VPE 게이트웨이를 사용함을 나타냄), 클러스터 마스터의 VPE 게이트웨이 보안 그룹이 VPN 클라이언트 서브넷의 트래픽을 허용하는지 확인하십시오. [OAuth 액세스가 VPE 게이트웨이로 설정된 경우 OpenShift 콘솔에 액세스하기의](/docs/openshift?topic=openshift-console-apiserver-oauthvpe) 단계를 따르세요.
    5. VPN에 적용된 보안 그룹, ACL 또는 사용자 지정 VPC 경로가 VPN과 클러스터 API 서버 간의 트래픽을 차단하는지 확인하십시오. VPN 보안 그룹과 ACL을 통해 모든 인바운드 및 아웃바운드 트래픽을 일시적으로 허용한 다음, 이 방법으로 문제가 해결되는지 확인해 보세요. 그렇다면 보안 그룹, ACL 또는 사용자 지정 경로에 필요한 변경을 수행하여 트래픽을 허용하십시오.
    6. 클러스터의 컨텍스트 기반 제한(CBR) 규칙으로 인해 클라이언트가 클러스터 API 서버에 연결할 수 없는지 확인합니다. 모든 IP와 서브넷을 허용하는 네트워크 영역을 CBR 규칙에 임시로 추가하여 테스트해 볼 수 있습니다. 이 임시 변경으로 문제가 해결되면 트래픽을 허용하는 데 필요한 규칙을 변경하세요.

OpenShift 콘솔을 노출하는 클러스터 로드 밸런서와의 연결이 성공적으로 이루어졌는지 확인하십시오.

명령을 실행하십시오. 이전 단계에서 찾은 Ingress 하위 도메인을 지정합니다.

    curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
    ```
2. 연결에 실패한 경우, 다음 사항을 확인하고 발견된 문제를 해결하십시오.
    1. 서브도메인의 호스트 이름 부분이 DNS를 통해 확인되었는지 확인하십시오. `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` 명령을 사용하십시오.
    2. VPN을 통해 이 로드 밸런서 하위 도메인으로 가는 경로가 있는지 확인하십시오. 경로에 로드 밸런서가 사용하는 모든 IP 또는 서브넷이 포함되어 있는지 확인하십시오. `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` 명령의 출력에는 현재 로드 밸런서의 IP와 서브넷이 포함되지만, 로드 밸런서의 규모가 커지거나 줄어들면 변경될 수 있다는 점에 유의하십시오.
    3. 로드 밸런서에 적용되는 보안 그룹, ACL 또는 사용자 지정 VPC 경로를 수정했다면, 적용한 변경 사항이나 규칙으로 인해 연결이 차단되는지 확인하십시오. 이 구성 요소들을 수정하지 않았고 기본값을 사용하는 경우에는 이 단계를 건너뛸 수 있습니다.
    4. VPN에 적용된 보안 그룹, ACL 또는 사용자 지정 VPC 경로로 인해 VPN과 로드 밸런서 간의 트래픽이 차단되는지 확인하십시오. VPN 보안 그룹과 ACL을 통해 모든 인바운드 및 아웃바운드 트래픽을 일시적으로 허용한 다음, 이 방법으로 문제가 해결되는지 확인해 보세요. 그렇다면 보안 그룹, ACL 또는 사용자 지정 경로에 필요한 변경을 수행하여 트래픽을 허용하십시오.

클러스터 OAuth 서버에 성공적으로 연결되었는지 확인합니다.

명령을 실행하십시오. 이전 단계에서 찾은 OAuth URL 클러스터를 지정합니다.

    curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
    ```
2. 연결에 실패한 경우, 다음 사항을 확인하고 발견된 문제를 해결하십시오.
    1. `ibmcloud oc cluster get -c <CLUSTER-ID>` 명령을 실행하여 클러스터 마스터가 정상 작동하는지 확인하십시오. 클러스터 마스터 문제 해결에 대한 정보는 [마스터 건강 상태 검토를](/docs/openshift?topic=openshift-debug_master) 참조하십시오.
    2. 클러스터의 호스트 이름 부분( OAuth URL )이 DNS를 통해 확인되었는지 확인합니다. `dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)` 을 사용하고 OAuth URL 클러스터를 지정합니다.
    3. VPN을 통해 클러스터 마스터로 연결되는 경로가 있는지 확인 OAuth URL.
    4. VPN에 적용된 보안 그룹, ACL 또는 사용자 지정 VPC 경로가 VPN과 클러스터 OAuth 서버 간의 트래픽을 차단하는지 확인합니다. VPN 보안 그룹과 ACL을 통해 모든 인바운드 및 아웃바운드 트래픽을 일시적으로 허용한 다음, 이 방법으로 문제가 해결되는지 확인해 보세요. 그렇다면 보안 그룹, ACL 또는 사용자 지정 경로에 필요한 변경을 수행하여 트래픽을 허용하십시오.
    5. 클라이언트가 클러스터 OAuth 서버에 연결할 수 없도록 하는 클러스터의 CBR(컨텍스트 기반 제한) 규칙이 있는지 확인합니다. 모든 IP와 서브넷을 허용하는 네트워크 영역을 CBR 규칙에 임시로 추가하여 테스트해 볼 수 있습니다. 이 임시 변경으로 문제가 해결되면 트래픽을 허용하는 데 필요한 규칙을 변경하세요.

IAM에 대한 연결이 성공적으로 이루어졌는지 확인하십시오.

명령을 실행합니다.

    curl -vvv https://iam.cloud.ibm.com/healthz
    curl -vvv -o /dev/null -s https://login.ibm.com/
    ```
2. 이 명령 중 하나라도 실패하면, 클라이언트 시스템이 이 URL에 안정적으로 연결할 수 있는지, 그리고 URL이 클라이언트나 기업 방화벽에 의해 차단되지 않았는지 확인하십시오. 이 URL은 공용 인터넷에 접속해야 한다는 점에 유의하시기 바랍니다.

5. 고객 지원팀에 문의하기

위의 모든 단계를 완료했는데도 문제가 해결되지 않으면 지원팀에 문의하십시오. 지원 케이스 열기 케이스 세부사항에는 관련된 로그 파일, 에러 메시지, 명령어 출력 등을 반드시 포함해야 합니다.