지원

프로세스

1. 클러스터에 로그인합니다.
2. 다음 명령을 실행하여 클러스터의 Prometheus 서비스를 쿼리하고 Telemetry에서 캡처한 전체 시계열 데이터 세트를 반환합니다.

프로세스

1. OpenShift Cluster Manager 에서 Advisor → Recommendations 로 이동합니다.

   결과에 따라 Insights 권고 서비스에 다음 중 하나가 표시됩니다.

   • Insights에서 문제를 식별하지 않은 경우 일치하는 권장 사항을 찾을 수 없습니다.
   • Insights가 감지한 문제 목록으로 위험(낮음, 중간, 중요 및 심각)으로 그룹화되어 있습니다.
   • Insights 가 아직 클러스터를 분석하지 않은 경우 아직 클러스터가 없습니다. 클러스터가 설치, 등록 및 인터넷에 연결된 직후 분석이 시작됩니다.

2. 문제가 표시되면 항목 앞의 > 아이콘을 클릭하여 자세한 내용을 확인합니다.

   문제에 따라 세부 정보에는 문제에 대한 Red Hat의 자세한 정보 링크가 포함될 수 있습니다.

프로세스

1. OpenShift Cluster Manager 에서 Advisor → Recommendations 로 이동합니다.

2. 영향을 받는 클러스터 및 상태 필터 옆에 있는 X 아이콘을 클릭합니다.

   이제 클러스터에 대한 모든 잠재적인 권장 사항을 확인할 수 있습니다.

프로세스

1. OpenShift Cluster Manager 에서 Advisor → Recommendations 로 이동합니다.
2. 선택 사항: 필요에 따라 클러스터에 영향을 미치는 상태 필터를 사용합니다.

3. 다음 방법 중 하나를 사용하여 경고를 비활성화합니다.

   • 경고를 비활성화하려면 다음을 수행합니다.

     1. 해당 경고에 대한 옵션 메뉴 를 클릭한 다음 권장 사항 비활성화 를 클릭합니다.
     2. 확인 참고 사항을 입력하고 저장을 클릭합니다.

   • 경고를 비활성화하기 전에 이 경고의 영향을 받는 클러스터를 보려면 다음을 수행합니다.

     1. 비활성화할 권장 사항 이름을 클릭합니다. 단일 권장 사항 페이지로 이동합니다.
     2. 영향을 받는 클러스터 섹션의 클러스터 목록을 검토합니다.
     3. 동작 → 권장 사항 비활성화 를 클릭하여 모든 클러스터에 대한 경고를 비활성화합니다.
     4. 확인 참고 사항을 입력하고 저장을 클릭합니다.

프로세스

1. OpenShift Cluster Manager 에서 Advisor → Recommendations 로 이동합니다.

2. 비활성화된 권장 사항에 표시할 권장 사항을 필터링합니다.

   1. Status 드롭다운 메뉴에서 Status 를 선택합니다.
   2. Filter by status 드롭다운 메뉴에서 Disabled 를 선택합니다.
   3. 선택 사항: 영향을 받는 클러스터 필터를 지웁니다.
3. 활성화할 권장 사항을 찾습니다.
4. 옵션 메뉴 를 클릭한 다음 권장 사항 사용을 클릭합니다.

프로세스

1. OpenShift Dedicated 웹 콘솔에서 홈 → 개요 로 이동합니다.

2. 상태 카드에서 Insights를 클릭합니다.

   팝업 창에 잠재적인 문제가 위험으로 그룹화되어 나열됩니다. 개별 카테고리를 클릭하거나 Insights Advisor의 모든 권장 사항 보기를 클릭하여 자세한 내용을 표시합니다.

프로세스

1. 워크로드 → ConfigMaps 로 이동하여 Project: openshift-insights 를 선택합니다.
2. insights-config ConfigMap 오브젝트를 클릭하여 엽니다.
3. 작업을 클릭하고 ConfigMap 편집을 선택합니다.
4. YAML 보기 라디오 버튼을 클릭합니다.

5. 파일에서 workload_names 값을 사용하여 난독 처리 속성을 설정합니다.

   apiVersion: v1
   kind: ConfigMap
   # ...
   data:
     config.yaml: |
       dataReporting:
         obfuscation:
           - workload_names
   # ...

   Copy to Clipboard Toggle word wrap
6. 저장을 클릭합니다. insights-config config-map 세부 정보 페이지가 열립니다.
7. config.yaml 난독 처리 속성 값이 - workload_names 로 설정되어 있는지 확인합니다.

프로세스

1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

2. oc adm must-gather 명령을 실행합니다.

   $ oc adm must-gather

   Copy to Clipboard Toggle word wrap
   참고

   이 명령은 기본적으로 임의의 컨트롤 플레인 노드를 선택하므로 Pod가 NotReady 및 SchedulingDisabled 상태인 컨트롤 플레인 노드로 예약할 수 있습니다.

   1. 예를 들어 클러스터에서 Pod를 예약할 수 없는 경우와 같이 명령이 실패하면 oc adm inspect 명령을 사용하여 특정 리소스에 대한 정보를 수집합니다.

      참고

      권장되는 리소스를 얻으려면 Red Hat 지원에 문의하십시오.

3. 작업 디렉토리에서 생성된 must-gather 디렉토리에서 압축 파일을 만듭니다. 고유한 must-gather 데이터에 대한 날짜 및 클러스터 ID를 제공해야 합니다. 클러스터 ID를 찾는 방법에 대한 자세한 내용은 OpenShift 클러스터에서 클러스터 ID 또는 이름을 찾는 방법을 참조하십시오. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir> 

   1

   Copy to Clipboard Toggle word wrap

   1

   & lt;must_gather_local_dir&gt;을 실제 디렉터리 이름으로 바꿉니다.

4. 압축 파일을 Red Hat 고객 포털 의 고객 지원 페이지의 지원 케이스에 첨부합니다.

프로세스

1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

2. --image 또는 --image-stream 인수를 하나 이상 사용하여 oc adm must-gather 명령을 실행합니다.

   참고
   • 특정 기능 데이터 외에도 기본 must-gather 데이터를 수집하려면 --image-stream=openshift/must-gather 인수를 추가하십시오.

   예를 들어 다음 명령은 기본 클러스터 데이터와 OpenShift Virtualization 관련 정보를 모두 수집합니다.

   $ oc adm must-gather \
     --image-stream=openshift/must-gather \ 

   1

   
     --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.19.6 

   2

   Copy to Clipboard Toggle word wrap

   1

   기본 OpenShift Dedicated must-gather 이미지

   2

   OpenShift Virtualization의 must-gather 이미지

   must-gather 툴을 추가 인수와 함께 사용하여 클러스터의 OpenShift 로깅 및 Cluster Logging Operator와 관련된 데이터를 수집할 수 있습니다. OpenShift 로깅의 경우 다음 명령을 실행합니다.

   $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \
     -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

   Copy to Clipboard Toggle word wrap

   예 5.1. OpenShift 로깅의 must-gather 출력 예

   ├── cluster-logging
   │  ├── clo
   │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
   │  │  ├── clusterlogforwarder_cr
   │  │  ├── cr
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── logforwarding_cr
   │  ├── collector
   │  │  ├── fluentd-2tr64
   │  ├── curator
   │  │  └── curator-1596028500-zkz4s
   │  ├── eo
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── elasticsearch-operator-7dc7d97b9d-jb4r4
   │  ├── es
   │  │  ├── cluster-elasticsearch
   │  │  │  ├── aliases
   │  │  │  ├── health
   │  │  │  ├── indices
   │  │  │  ├── latest_documents.json
   │  │  │  ├── nodes
   │  │  │  ├── nodes_stats.json
   │  │  │  └── thread_pool
   │  │  ├── cr
   │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  │  └── logs
   │  │     ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  ├── install
   │  │  ├── co_logs
   │  │  ├── install_plan
   │  │  ├── olmo_logs
   │  │  └── subscription
   │  └── kibana
   │     ├── cr
   │     ├── kibana-9d69668d4-2rkvz
   ├── cluster-scoped-resources
   │  └── core
   │     ├── nodes
   │     │  ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml
   │     └── persistentvolumes
   │        ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml
   ├── event-filter.html
   ├── gather-debug.log
   └── namespaces
      ├── openshift-logging
      │  ├── apps
      │  │  ├── daemonsets.yaml
      │  │  ├── deployments.yaml
      │  │  ├── replicasets.yaml
      │  │  └── statefulsets.yaml
      │  ├── batch
      │  │  ├── cronjobs.yaml
      │  │  └── jobs.yaml
      │  ├── core
      │  │  ├── configmaps.yaml
      │  │  ├── endpoints.yaml
      │  │  ├── events
      │  │  │  ├── curator-1596021300-wn2ks.162634ebf0055a94.yaml
      │  │  │  ├── curator.162638330681bee2.yaml
      │  │  │  ├── elasticsearch-delete-app-1596020400-gm6nl.1626341a296c16a1.yaml
      │  │  │  ├── elasticsearch-delete-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
      │  │  │  ├── elasticsearch-delete-infra-1596020400-v98tk.1626341a2d821069.yaml
      │  │  │  ├── elasticsearch-rollover-app-1596020400-cc5vc.1626341a3019b238.yaml
      │  │  │  ├── elasticsearch-rollover-audit-1596020400-s8d5s.1626341a31f7b315.yaml
      │  │  │  ├── elasticsearch-rollover-infra-1596020400-7mgv8.1626341a35ea59ed.yaml
      │  │  ├── events.yaml
      │  │  ├── persistentvolumeclaims.yaml
      │  │  ├── pods.yaml
      │  │  ├── replicationcontrollers.yaml
      │  │  ├── secrets.yaml
      │  │  └── services.yaml
      │  ├── openshift-logging.yaml
      │  ├── pods
      │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
      │  │  │  ├── cluster-logging-operator
      │  │  │  │  └── cluster-logging-operator
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  └── cluster-logging-operator-74dd5994f-6ttgt.yaml
      │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff
      │  │  │  ├── cluster-logging-operator-registry
      │  │  │  │  └── cluster-logging-operator-registry
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml
      │  │  │  └── mutate-csv-and-generate-sqlite-db
      │  │  │     └── mutate-csv-and-generate-sqlite-db
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── curator-1596028500-zkz4s
      │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
      │  │  ├── elasticsearch-delete-app-1596030300-bpgcx
      │  │  │  ├── elasticsearch-delete-app-1596030300-bpgcx.yaml
      │  │  │  └── indexmanagement
      │  │  │     └── indexmanagement
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── fluentd-2tr64
      │  │  │  ├── fluentd
      │  │  │  │  └── fluentd
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── fluentd-2tr64.yaml
      │  │  │  └── fluentd-init
      │  │  │     └── fluentd-init
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── kibana-9d69668d4-2rkvz
      │  │  │  ├── kibana
      │  │  │  │  └── kibana
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── kibana-9d69668d4-2rkvz.yaml
      │  │  │  └── kibana-proxy
      │  │  │     └── kibana-proxy
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  └── route.openshift.io
      │     └── routes.yaml
      └── openshift-operators-redhat
         ├── ...

   Copy to Clipboard Toggle word wrap

3. --image 또는 --image-stream 인수를 하나 이상 사용하여 oc adm must-gather 명령을 실행합니다. 예를 들어 다음 명령은 기본 클러스터 데이터와 KubeVirt 관련 정보를 모두 수집합니다.

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 

   1

   
    --image=quay.io/kubevirt/must-gather 

   2

   Copy to Clipboard Toggle word wrap

   1

   기본 OpenShift Dedicated must-gather 이미지

   2

   KubeVirt의 must-gather 이미지

4. 작업 디렉토리에서 생성된 must-gather 디렉토리에서 압축 파일을 만듭니다. 고유한 must-gather 데이터에 대한 날짜 및 클러스터 ID를 제공해야 합니다. 클러스터 ID를 찾는 방법에 대한 자세한 내용은 OpenShift 클러스터에서 클러스터 ID 또는 이름을 찾는 방법을 참조하십시오. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir> 

   1

   Copy to Clipboard Toggle word wrap

   1

   & lt;must_gather_local_dir&gt;을 실제 디렉터리 이름으로 바꿉니다.

5. 압축 파일을 Red Hat 고객 포털 의 고객 지원 페이지의 지원 케이스에 첨부합니다.

프로세스

1. -- gather_network_logs 를 사용하여 oc adm must-gather 명령을 실행합니다.

   $ oc adm must-gather -- gather_network_logs

   Copy to Clipboard Toggle word wrap
   참고

   기본적으로 must-gather 툴은 클러스터의 모든 노드에서 OVN nbdb 및 sbdb 데이터베이스를 수집합니다. OVN nbdb 데이터베이스에 대한 OVN-Kubernetes 트랜잭션이 포함된 추가 로그를 포함하도록 -- gather_network_logs 옵션을 추가합니다.

2. 작업 디렉토리에서 생성된 must-gather 디렉토리에서 압축 파일을 만듭니다. 고유한 must-gather 데이터에 대한 날짜 및 클러스터 ID를 제공해야 합니다. 클러스터 ID를 찾는 방법에 대한 자세한 내용은 OpenShift 클러스터에서 클러스터 ID 또는 이름을 찾는 방법을 참조하십시오. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar cvaf must-gather-`date +"%m-%d-%Y-%H-%M-%S"`-<cluster_id>.tar.gz <must_gather_local_dir>

   1

   Copy to Clipboard Toggle word wrap

   1

   & lt;must_gather_local_dir&gt;을 실제 디렉터리 이름으로 바꿉니다.

3. 압축 파일을 Red Hat 고객 포털 의 고객 지원 페이지의 지원 케이스에 첨부합니다.

프로세스

1. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

   # chroot /host

   Copy to Clipboard Toggle word wrap

2. toolbox 컨테이너를 시작합니다.

   # toolbox

   Copy to Clipboard Toggle word wrap

3. wget과 같은 추가 패키지를 설치합니다.

   # dnf install -y <package_name>

   Copy to Clipboard Toggle word wrap

프로세스

1. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

   # chroot /host

   Copy to Clipboard Toggle word wrap

2. 선택 사항: 기본 이미지 대신 대체 이미지를 사용해야 하는 경우 root 사용자 ID의 홈 디렉터리에 .toolboxrc 파일을 생성하고 이미지 메타데이터를 지정합니다.

   REGISTRY=quay.io             

   1

   
   IMAGE=fedora/fedora:latest   

   2

   
   TOOLBOX_NAME=toolbox-fedora-latest  

   3

   Copy to Clipboard Toggle word wrap

   1

   선택 사항: 대체 컨테이너 레지스트리를 지정합니다.

   2

   시작할 대체 이미지를 지정합니다.

   3

   선택 사항: toolbox 컨테이너의 대체 이름을 지정합니다.

3. 다음 명령을 입력하여 toolbox 컨테이너를 시작합니다.

   # toolbox

   Copy to Clipboard Toggle word wrap
   참고

   기존 toolbox Pod가 이미 실행 중인 경우 toolbox 명령은 'toolbox-' already exists를 출력합니다. Trying to start…​를 출력합니다. sosreport 플러그인 문제를 방지하려면 podman rm toolbox- 에서 실행중인 toolbox 컨테이너를 제거한 다음 새 toolbox 컨테이너를 생성합니다.

프로세스

1. Operator 서브스크립션을 나열합니다.

   $ oc get subs -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

2. oc describe 명령을 사용하여 Subscription 리소스를 검사합니다.

   $ oc describe sub <subscription_name> -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

3. 명령 출력에서 Operator 서브스크립션 조건 유형의 상태에 대한 Conditions 섹션을 확인합니다. 다음 예에서 사용 가능한 모든 카탈로그 소스가 정상이므로 CatalogSourcesUnhealthy 조건 유형의 상태가 false입니다.

   출력 예

   Name:         cluster-logging
   Namespace:    openshift-logging
   Labels:       operators.coreos.com/cluster-logging.openshift-logging=
   Annotations:  <none>
   API Version:  operators.coreos.com/v1alpha1
   Kind:         Subscription
   # ...
   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy
   # ...

   Copy to Clipboard Toggle word wrap

프로세스

1. 네임스페이스의 카탈로그 소스를 나열합니다. 예를 들어 클러스터 전체 카탈로그 소스에 사용되는 openshift-marketplace 네임스페이스를 확인할 수 있습니다.

   $ oc get catalogsources -n openshift-marketplace

   Copy to Clipboard Toggle word wrap

   출력 예

   NAME                  DISPLAY               TYPE   PUBLISHER   AGE
   certified-operators   Certified Operators   grpc   Red Hat     55m
   community-operators   Community Operators   grpc   Red Hat     55m
   example-catalog       Example Catalog       grpc   Example Org 2m25s
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

   Copy to Clipboard Toggle word wrap

2. oc describe 명령을 사용하여 카탈로그 소스에 대한 자세한 내용 및 상태를 가져옵니다.

   $ oc describe catalogsource example-catalog -n openshift-marketplace

   Copy to Clipboard Toggle word wrap

   출력 예

   Name:         example-catalog
   Namespace:    openshift-marketplace
   Labels:       <none>
   Annotations:  operatorframework.io/managed-by: marketplace-operator
                 target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
   API Version:  operators.coreos.com/v1alpha1
   Kind:         CatalogSource
   # ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace
   # ...

   Copy to Clipboard Toggle word wrap

   앞의 예제 출력에서 마지막으로 관찰된 상태는 TRANSIENT_FAILURE입니다. 이 상태는 카탈로그 소스에 대한 연결을 설정하는 데 문제가 있음을 나타냅니다.

3. 카탈로그 소스가 생성된 네임스페이스의 Pod를 나열합니다.

   $ oc get pods -n openshift-marketplace

   Copy to Clipboard Toggle word wrap

   출력 예

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-operators-smxx8                  1/1     Running            0          36m

   Copy to Clipboard Toggle word wrap

   카탈로그 소스가 네임스페이스에 생성되면 해당 네임스페이스에 카탈로그 소스의 Pod가 생성됩니다. 위 예제 출력에서 example-catalog-bwt8z pod의 상태는 ImagePullBackOff입니다. 이 상태는 카탈로그 소스의 인덱스 이미지를 가져오는 데 문제가 있음을 나타냅니다.

4. 자세한 정보는 oc describe 명령을 사용하여 Pod를 검사합니다.

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   Copy to Clipboard Toggle word wrap

   출력 예

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

   Copy to Clipboard Toggle word wrap

   앞의 예제 출력에서 오류 메시지는 권한 부여 문제로 인해 카탈로그 소스의 인덱스 이미지를 성공적으로 가져오지 못한 것으로 표시됩니다. 예를 들어 인덱스 이미지는 로그인 인증 정보가 필요한 레지스트리에 저장할 수 있습니다.

프로세스

1. 클러스터에서 실행중인 Operator를 나열합니다. 출력에는 Operator 버전, 가용성 및 가동 시간 정보가 포함됩니다.

   $ oc get clusteroperators

   Copy to Clipboard Toggle word wrap

2. Operator의 네임스페이스에서 실행 중인 Operator Pod와 Pod 상태, 재시작, 경과 시간을 표시합니다.

   $ oc get pod -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

3. 자세한 Operator Pod 요약을 출력합니다.

   $ oc describe pod <operator_pod_name> -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

프로세스

1. Operator의 네임스페이스에서 실행 중인 Operator Pod와 Pod 상태, 재시작, 경과 시간을 표시합니다.

   $ oc get pods -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

2. Operator Pod의 로그를 검토합니다.

   $ oc logs pod/<pod_name> -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

   Operator Pod에 컨테이너가 여러 개 있는 경우 위 명령에 의해 각 컨테이너의 이름이 포함된 오류가 생성됩니다. 개별 컨테이너의 로그를 쿼리합니다.

   $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>

   Copy to Clipboard Toggle word wrap

3. API가 작동하지 않는 경우 대신 SSH를 사용하여 각 컨트롤 플레인 노드에서 Operator Pod 및 컨테이너 로그를 검토합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

   1. 각 컨트롤 플레인 노드에 Pod를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods

      Copy to Clipboard Toggle word wrap

   2. Ready 상태가 표시되지 않는 Operator Pod의 경우 Pod 상태를 자세히 검사합니다. <operator_pod_id>를 이전 명령의 출력에 나열된 Operator Pod의 ID로 교체합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>

      Copy to Clipboard Toggle word wrap

   3. Operator Pod와 관련된 컨테이너를 나열합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>

      Copy to Clipboard Toggle word wrap

   4. Ready 상태가 표시되지 않는 Operator 컨테이너의 경우 컨테이너 상태를 자세히 검사합니다. <container_id>를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

      Copy to Clipboard Toggle word wrap

   5. Ready 상태가 표시되지 않는 Operator 컨테이너의 로그를 확인합니다. <container_id>를 이전 명령의 출력에 나열된 컨테이너 ID로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      Copy to Clipboard Toggle word wrap
      참고

      RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Dedicated 4 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. SSH를 통해 진단 데이터를 수집하기 전에 oc adm must gather 및 기타 oc 명령을 실행하여 충분한 데이터를 수집할 수 있는지 확인하십시오. 그러나 OpenShift Dedicated API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 ssh core@<node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

프로세스

1. 프로젝트로 전환합니다.

   $ oc project <project_name>

   Copy to Clipboard Toggle word wrap

2. 네임스페이스 내에서 실행 중인 Pod와 Pod 상태, 오류 상태, 재시작, 경과 시간을 표시합니다.

   $ oc get pods

   Copy to Clipboard Toggle word wrap

3. 네임 스페이스가 배포 구성에 의해 관리되는지 확인합니다.

   $ oc status

   Copy to Clipboard Toggle word wrap

   네임 스페이스가 배포 구성으로 관리되는 경우 출력에 배포 구성 이름과 기본 이미지 참조가 포함됩니다.

4. 이전 명령의 출력에서 참조되는 기본 이미지를 검사합니다.

   $ skopeo inspect docker://<image_reference>

   Copy to Clipboard Toggle word wrap

5. 기본 이미지 참조가 올바르지 않으면 배치 구성에서 참조를 업데이트합니다.

   $ oc edit deployment/my-deployment

   Copy to Clipboard Toggle word wrap

6. 배포 구성이 완료된 후 변경되면 구성이 자동으로 다시 배포됩니다. 배포가 진행되는 동안 Pod 상태를 확인하여 문제가 해결되었는지 확인합니다.

   $ oc get pods -w

   Copy to Clipboard Toggle word wrap

7. Pod 실패와 관련된 진단 정보를 보려면 네임스페이스 내의 이벤트를 검토합니다.

   $ oc get events

   Copy to Clipboard Toggle word wrap

프로세스

1. 특정 Pod의 로그를 쿼리합니다.

   $ oc logs <pod_name>

   Copy to Clipboard Toggle word wrap

2. Pod에서 특정 컨테이너의 로그를 쿼리합니다.

   $ oc logs <pod_name> -c <container_name>

   Copy to Clipboard Toggle word wrap

   이전 oc logs 명령을 사용하여 검색된 로그는 Pod 또는 컨테이너 내에서 stdout으로 전송된 메시지로 구성됩니다.

3. Pod에서 /var/log/에 포함된 로그를 검사합니다.

   1. Pod에서 /var/log에 포함된 로그 파일 및 하위 디렉터리를 나열합니다.

      $ oc exec <pod_name>  -- ls -alh /var/log

      Copy to Clipboard Toggle word wrap

      출력 예

      total 124K
      drwxr-xr-x. 1 root root   33 Aug 11 11:23 .
      drwxr-xr-x. 1 root root   28 Sep  6  2022 ..
      -rw-rw----. 1 root utmp    0 Jul 10 10:31 btmp
      -rw-r--r--. 1 root root  33K Jul 17 10:07 dnf.librepo.log
      -rw-r--r--. 1 root root  69K Jul 17 10:07 dnf.log
      -rw-r--r--. 1 root root 8.8K Jul 17 10:07 dnf.rpm.log
      -rw-r--r--. 1 root root  480 Jul 17 10:07 hawkey.log
      -rw-rw-r--. 1 root utmp    0 Jul 10 10:31 lastlog
      drwx------. 2 root root   23 Aug 11 11:14 openshift-apiserver
      drwx------. 2 root root    6 Jul 10 10:31 private
      drwxr-xr-x. 1 root root   22 Mar  9 08:05 rhsm
      -rw-rw-r--. 1 root utmp    0 Jul 10 10:31 wtmp

      Copy to Clipboard Toggle word wrap

   2. Pod에서 /var/log에 포함된 특정 로그 파일을 쿼리합니다.

      $ oc exec <pod_name> cat /var/log/<path_to_log>

      Copy to Clipboard Toggle word wrap

      출력 예

      2023-07-10T10:29:38+0000 INFO --- logging initialized ---
      2023-07-10T10:29:38+0000 DDEBUG timer: config: 13 ms
      2023-07-10T10:29:38+0000 DEBUG Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile
      2023-07-10T10:29:38+0000 INFO Updating Subscription Management repositories.
      2023-07-10T10:29:38+0000 INFO Unable to read consumer identity
      2023-07-10T10:29:38+0000 INFO Subscription Manager is operating in container mode.
      2023-07-10T10:29:38+0000 INFO

      Copy to Clipboard Toggle word wrap

   3. 특정 컨테이너의 /var/log에 포함된 로그 파일 및 하위 디렉토리를 나열합니다.

      $ oc exec <pod_name> -c <container_name> ls /var/log

      Copy to Clipboard Toggle word wrap

   4. 특정 컨테이너의 /var/log에 포함된 특정 로그 파일을 쿼리합니다.

      $ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>

      Copy to Clipboard Toggle word wrap

프로세스

1. 액세스하려는 Pod가 포함된 프로젝트로 전환합니다. 이는 oc rsh 명령이 -n namespace 옵션을 허용하지 않기 때문에 필요합니다.

   $ oc project <namespace>

   Copy to Clipboard Toggle word wrap

2. Pod에서 원격 쉘을 시작합니다.

   $ oc rsh <pod_name>  

   1

   Copy to Clipboard Toggle word wrap

   1

   Pod에 컨테이너가 여러 개 있는 경우 -c <container_name>을 지정하지 않으면 oc rsh는 첫 번째 컨테이너로 기본 설정됩니다.

3. Pod에서 특정 컨테이너로 원격 쉘을 시작합니다.

   $ oc rsh -c <container_name> pod/<pod_name>

   Copy to Clipboard Toggle word wrap

4. Pod에서 포트로의 포트 전달 세션을 만듭니다.

   $ oc port-forward <pod_name> <host_port>:<pod_port>  

   1

   Copy to Clipboard Toggle word wrap

   1

   Ctrl+C를 입력하여 포트 전달 세션을 취소합니다.

프로세스

1. 배포에 따라 루트 액세스 권한으로 디버그 Pod를 시작합니다.

   1. 프로젝트의 배포 이름을 가져옵니다.

      $ oc get deployment -n <project_name>

      Copy to Clipboard Toggle word wrap

   2. 배포에 따라 루트 권한으로 디버그 Pod를 시작합니다.

      $ oc debug deployment/my-deployment --as-root -n <project_name>

      Copy to Clipboard Toggle word wrap

2. 배포 구성에 따라 루트 액세스 권한으로 디버그 Pod를 시작합니다.

   1. 프로젝트의 배포 구성 이름을 가져옵니다.

      $ oc get deploymentconfigs -n <project_name>

      Copy to Clipboard Toggle word wrap

   2. 배포 구성에 따라 루트 권한으로 디버그 Pod를 시작합니다.

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>

      Copy to Clipboard Toggle word wrap

프로세스

1. 파일을 Pod에 복사합니다.

   $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  

   1

   Copy to Clipboard Toggle word wrap

   1

   -c 옵션이 지정되지 않은 경우 Pod의 첫 번째 컨테이너가 선택됩니다.

2. Pod에서 파일을 복사합니다.

   $ oc cp <pod_name>:/<path>  -c <container_name> <local_path>  

   1

   Copy to Clipboard Toggle word wrap

   1

   -c 옵션이 지정되지 않은 경우 Pod의 첫 번째 컨테이너가 선택됩니다.

   참고

   oc cp 가 작동하려면 컨테이너 내에서 tar 바이너리를 사용할 수 있어야합니다.

1. 빌드 구성 단계에서 빌드 Pod는 기본 이미지 및 애플리케이션 소스 코드에서 애플리케이션 컨테이너 이미지를 만드는 데 사용됩니다.
2. 배포 구성 단계에서 배포 Pod는 빌드 구성 단계에서 빌드된 애플리케이션 컨테이너 이미지에서 애플리케이션 Pod를 배포하는 데 사용됩니다. 배포 Pod는 서비스 및 경로와 같은 다른 리소스도 배포합니다. 배포 구성은 빌드 구성이 성공한 후에 시작됩니다.
3. 배포 Pod에서 애플리케이션 Pod를 시작한 후 실행 중인 애플리케이션 Pod 내에서 애플리케이션 오류가 발생할 수 있습니다. 예를 들어 애플리케이션 Pod가 Running 상태인 경우에도 애플리케이션이 예상대로 작동하지 않을 수 있습니다. 이 시나리오에서는 실행 중인 애플리케이션 Pod에 액세스하여 Pod 내의 애플리케이션 오류를 조사할 수 있습니다.

1. 빌드, 배포 및 애플리케이션 Pod 상태 모니터링
2. 문제가 발생한 S2I 프로세스 단계 확인
3. 실패한 단계에 해당하는 로그 확인

프로세스

1. S2I 프로세스 전체에서 Pod의 상태를 확인하고 오류가 발생하는 단계를 확인합니다.

   $ oc get pods -w  

   1

   Copy to Clipboard Toggle word wrap

   1

   Ctrl+C를 사용하여 명령을 종료할 때까지 -w를 사용하여 Pod의 변경 사항을 모니터링합니다.

2. 실패한 Pod 로그에서 오류가 있는지 확인합니다.

   • 빌드 Pod가 실패하면 빌드 Pod의 로그를 검토합니다.

     $ oc logs -f pod/<application_name>-<build_number>-build

     Copy to Clipboard Toggle word wrap
     참고

     또는 oc logs -f bc/<application_name>을 사용하여 빌드 구성의 로그를 확인할 수 있습니다. 빌드 구성의 로그에는 빌드 Pod의 로그가 포함됩니다.

   • 배포 Pod가 실패하면 배포 Pod의 로그를 검토합니다.

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     Copy to Clipboard Toggle word wrap
     참고

     또는 oc logs -f dc/<application_name>을 사용하여 배포 구성의 로그를 확인할 수 있습니다. 이렇게 하면 배포 Pod가 성공적으로 완료될 때까지 배포 Pod의 로그가 출력됩니다. 이 명령을 배포 Pod가 완료된 후 실행하면 애플리케이션 Pod에서 로그를 출력합니다. 배포 Pod가 완료된 후에도 oc logs -f pod/<application_name>-<build_number>-deploy를 실행하여 로그에 계속 액세스할 수 있습니다.

   • 애플리케이션 Pod가 실패하거나 애플리케이션이 실행 중인 애플리케이션 Pod 내에서 예상대로 작동하지 않으면 애플리케이션 Pod의 로그를 확인합니다.

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

     Copy to Clipboard Toggle word wrap

프로세스

1. 특정 애플리케이션 Pod와 관련된 이벤트를 나열합니다. 다음 예에서는 my-app-1-akdlg라는 애플리케이션 Pod의 이벤트를 검색합니다.

   $ oc describe pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

2. 애플리케이션 Pod에서 로그를 검토합니다.

   $ oc logs -f pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

3. 실행 중인 애플리케이션 Pod 내에서 특정 로그를 쿼리합니다. stdout으로 전송되는 로그는 OpenShift Logging 프레임 워크에서 수집되며 위의 명령의 출력에 포함됩니다. 다음 쿼리는 stdout으로 전송되지 않은 로그에만 필요합니다.

   1. Pod 내에서 루트 권한 없이 애플리케이션 로그에 액세스할 수 있는 경우 다음과 같이 로그 파일을 연결합니다.

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap

   2. 애플리케이션 로그를 보기 위해 root 액세스가 필요한 경우 root 권한으로 디버그 컨테이너를 시작한 다음 컨테이너 내에서 로그 파일을 볼 수 있습니다. 프로젝트의 DeploymentConfig 개체에서 디버그 컨테이너를 시작합니다. 일반적으로 Pod 사용자는 루트 이외의 권한으로 실행되지만 임시 루트 권한으로 문제 해결 Pod를 실행하면 문제 해결에 유용할 수 있습니다.

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap
      참고

      -- <command>를 추가하지 않고 oc debug dc/<deployment_configuration> --as-root를 실행하면 디버그 Pod에서 루트 액세스 권한으로 대화형 쉘에 액세스할 수 있습니다.

4. 대화형 쉘이 있는 애플리케이션 컨테이너에서 대화형으로 애플리케이션 기능을 테스트하고 진단 도구를 실행합니다.

   1. 애플리케이션 컨테이너에서 대화형 쉘을 시작합니다.

      $ oc exec -it my-app-1-akdlg /bin/bash

      Copy to Clipboard Toggle word wrap
   2. 쉘에서 대화형으로 애플리케이션 기능을 테스트합니다. 예를 들어 컨테이너의 엔트리 포인트 명령을 실행하고 결과를 확인할 수 있습니다. 그런 다음 S2I 프로세스를 통해 소스 코드를 업데이트하고 애플리케이션 컨테이너를 다시 빌드하기 전에 명령 줄에서 직접 변경 사항을 테스트합니다.

   3. 컨테이너에서 사용 가능한 진단 바이너리를 실행합니다.

      참고

      일부 진단 바이너리를 실행하려면 root 권한이 필요합니다. 이러한 상황에서는 oc debug dc/<deployment_configuration> --as-root를 실행하여 문제가 있는 Pod의 DeploymentConfig 개체에 따라 루트 액세스 권한으로 디버그 Pod를 시작할 수 있습니다. 그런 다음 디버그 Pod 내에서 루트로 진단 바이너리를 실행할 수 있습니다.

프로세스

1. 프로젝트 및 리소스가 사용자 워크로드 모니터링에서 제외되지 않았는지 확인합니다. 다음 예제에서는 ns1 프로젝트를 사용합니다.

   1. 프로젝트에 openshift.io/user-monitoring=false 라벨이 연결되어 있지 않은지 확인합니다.

      $ oc get namespace ns1 --show-labels | grep 'openshift.io/user-monitoring=false'

      Copy to Clipboard Toggle word wrap
      참고

      사용자 워크로드 프로젝트에 설정된 기본 레이블은 openshift.io/user-monitoring=true 입니다. 그러나 수동으로 적용하지 않는 한 레이블은 표시되지 않습니다.

   2. ServiceMonitor 및 PodMonitor 리소스에 openshift.io/user-monitoring=false 레이블이 연결되어 있지 않은지 확인합니다. 다음 예제에서는 prometheus-example-monitor 서비스 모니터를 확인합니다.

      $ oc -n ns1 get servicemonitor prometheus-example-monitor --show-labels | grep 'openshift.io/user-monitoring=false'

      Copy to Clipboard Toggle word wrap

   3. 라벨이 연결된 경우 라벨을 제거하십시오.

      프로젝트에서 레이블 제거 예

      $ oc label namespace ns1 'openshift.io/user-monitoring-'

      Copy to Clipboard Toggle word wrap

      리소스에서 라벨을 제거하는 예

      $ oc -n ns1 label servicemonitor prometheus-example-monitor 'openshift.io/user-monitoring-'

      Copy to Clipboard Toggle word wrap

      출력 예

      namespace/ns1 unlabeled

      Copy to Clipboard Toggle word wrap

2. 서비스 및 ServiceMonitor 리소스 구성에서 해당 레이블이 일치하는지 확인하세요. 다음 예제에서는 prometheus-example-app 서비스, prometheus-example-monitor 서비스 모니터 및 ns1 프로젝트를 사용합니다.

   1. 서비스에 정의된 라벨을 가져옵니다.

      $ oc -n ns1 get service prometheus-example-app -o yaml

      Copy to Clipboard Toggle word wrap

      출력 예

        labels:
          app: prometheus-example-app

      Copy to Clipboard Toggle word wrap

   2. ServiceMonitor 리소스 구성의 matchLabels 정의가 이전 단계의 라벨 출력과 일치하는지 확인합니다.

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      Copy to Clipboard Toggle word wrap

      출력 예

      apiVersion: v1
      kind: ServiceMonitor
      metadata:
        name: prometheus-example-monitor
        namespace: ns1
      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      Copy to Clipboard Toggle word wrap

      참고

      프로젝트 보기 권한이 있는 개발자로서 서비스 및 ServiceMonitor 리소스 라벨을 확인할 수 있습니다.

3. openshift-user-workload-monitoring 프로젝트에서 Prometheus Operator에 대한 로그를 검사합니다.

   1. openshift-user-workload-monitoring 프로젝트의 Pod를 나열합니다.

      $ oc -n openshift-user-workload-monitoring get pods

      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

      Copy to Clipboard Toggle word wrap

   2. prometheus-operator pod의 prometheus-operator 컨테이너에서 로그를 가져옵니다. 다음 예에서 Pod는 prometheus-operator-776fcbbd56-2nbfm입니다.

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      Copy to Clipboard Toggle word wrap

      서비스 모니터에 문제가 있는 경우 로그에 다음과 유사한 오류가 포함될 수 있습니다.

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

      Copy to Clipboard Toggle word wrap

4. OpenShift Dedicated 웹 콘솔 UI의 Metrics 대상 페이지에서 끝점의 대상 상태를 확인합니다.

   1. OpenShift Dedicated 웹 콘솔에 로그인하고 Observe → Targets 로 이동합니다.
   2. 목록에서 지표 끝점을 찾고 상태 열에서 대상의 상태를 검토합니다.
   3. 상태 가 Down 인 경우 끝점의 URL을 클릭하여 해당 지표 대상의 대상 세부 정보 페이지에 대한 자세한 정보를 확인합니다.

5. openshift-user-workload-monitoring 프로젝트에서 Prometheus Operator에 대한 디버그 수준 로깅을 구성합니다.

   1. openshift-user-workload-monitoring 프로젝트에서 user-workload-monitoring-config ConfigMap 오브젝트를 편집합니다.

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

      Copy to Clipboard Toggle word wrap

   2. prometheusOperator의 logLevel:debug를 data / config.yaml 아래에 추가하여 로그 수준을 debug로 설정합니다.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug
      # ...

      Copy to Clipboard Toggle word wrap
   3. 파일을 저장하여 변경 사항을 적용합니다. 영향을 받는 prometheus-operator Pod가 자동으로 재배포됩니다.

   4. openshift-user-workload-monitoring 프로젝트의 prometheus-operator 배포에 debug 로그 수준이 적용되었는지 확인합니다.

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      Copy to Clipboard Toggle word wrap

      출력 예

              - --log-level=debug

      Copy to Clipboard Toggle word wrap

      디버그 수준 로깅은 Prometheus Operator가 수행한 모든 호출을 표시합니다.

   5. prometheus-operator Pod가 실행되고 있는지 확인합니다.

      $ oc -n openshift-user-workload-monitoring get pods

      Copy to Clipboard Toggle word wrap
      참고

      구성 맵에 인식할 수 없는 Prometheus Operator loglevel 값이 포함된 경우 prometheus-operator Pod가 재시작되지 않을 수 있습니다.

   6. 디버그 로그를 검토하여 Prometheus Operator에서 ServiceMonitor 리소스를 사용하고 있는지 확인합니다. 기타 관련 오류에 대한 로그를 확인합니다.