지원

프로세스

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

프로세스

1. Insights Operator에 대해 현재 실행 중인 Pod의 이름을 검색합니다.

   $ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running)

2. Insights Operator가 수집한 최근 데이터 아카이브를 복사합니다.

   $ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data

프로세스

1. 로컬 파일 시스템에 글로벌 클러스터 풀 시크릿을 다운로드합니다.

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. 텍스트 편집기에서 다운로드한 .dockerconfigjson 파일을 편집합니다.

3. 다음과 같이 cloud.openshift.com JSON 항목을 제거합니다.

   "cloud.openshift.com":{"auth":"<hash>","email":"<email_address>"}

4. 파일을 저장합니다.

프로세스

1. Red Hat Hybrid Cloud Console의 연결이 끊긴 클러스터 웹 페이지로 이동합니다.
2. 선택 사항: Red Hat Hybrid Cloud Console의 홈 페이지에서 연결이 끊긴 클러스터 웹 페이지에 액세스하려면 Cluster List 탐색 메뉴 항목으로 이동한 다음 Register cluster 버튼을 선택합니다.
3. 등록 연결이 끊긴 클러스터 페이지의 제공된 필드에 클러스터의 세부 정보를 입력합니다.
4. 페이지의 서브스크립션 설정 섹션에서 Red Hat 서브스크립션 오퍼링에 적용되는 하위 생성 설정을 선택합니다.
5. 연결이 끊긴 클러스터를 등록하려면 클러스터 동록 버튼을 선택합니다.

프로세스

1. 선택 사항: 기존 풀 시크릿에 새 풀 시크릿을 추가하려면 다음 단계를 완료합니다.

   1. 다음 명령을 입력하여 풀 시크릿을 다운로드합니다.

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

      1

      풀 시크릿 파일에 경로를 제공합니다.

   2. 다음 명령을 입력하여 새 풀 시크릿을 추가합니다.

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3

      1

      새 레지스트리를 제공합니다. 동일한 레지스트리에 여러 리포지토리를 포함할 수 있습니다 (예: --registry="<registry/my-namespace/my-repository&gt;).

      2

      새 레지스트리의 인증 정보를 제공합니다.

      3

      풀 시크릿 파일에 경로를 제공합니다.

      또는 가져오기 시크릿 파일에 대한 수동 업데이트를 수행할 수 있습니다.

2. 다음 명령을 입력하여 클러스터의 글로벌 풀 시크릿을 업데이트합니다.

   $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

   1

   새 풀 시크릿 파일의 경로를 제공합니다.

   이 업데이트는 모든 노드로 롤아웃되며 클러스터 크기에 따라 작업에 약간의 시간이 걸릴 수 있습니다.

   참고

   OpenShift Container Platform 4.7.4부터 글로벌 풀 시크릿을 변경해도 더 이상 노드 드레이닝 또는 재부팅이 트리거되지 않습니다.

프로세스

1. https://console.redhat.com/openshift/downloads 로 이동합니다.

2. 토큰 → 시크릿 가져오기 에서 다운로드를 클릭합니다.

   cloud.openshift.com 액세스 토큰이 포함된 pull-secret.txt 파일은 JSON 형식으로 다운로드됩니다.

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "<your_token>",
         "email": "<email_address>"
       }
     }
   }

3. 로컬 파일 시스템에 글로벌 클러스터 풀 시크릿을 다운로드합니다.

   $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' > pull-secret

4. 풀 시크릿의 백업 사본을 만듭니다.

   $ cp pull-secret pull-secret-backup

5. 텍스트 편집기에서 pull-secret 파일을 엽니다.
6. pull-secret.txt 의 cloud.openshift.com JSON 항목을 auths 에 추가합니다.
7. 파일을 저장합니다.

8. 클러스터에서 시크릿을 업데이트합니다.

   oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=pull-secret

검증

1. OpenShift Container Platform 웹 콘솔 개요 페이지로 이동합니다.
2. 상태 타일의 Insights 는 발견된 문제 수를 보고합니다.

프로세스

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

   결과에 따라 Insights Advisor는 다음 중 하나를 표시합니다.

   • 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 Container Platform 웹 콘솔에서 홈 → 개요로 이동합니다.

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

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

프로세스

1. Insights Operator에 대해 실행 중인 Pod의 이름을 찾습니다.

   $ oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running

2. Insights Operator가 수집한 최근 데이터 아카이브를 복사합니다.

   $ oc cp openshift-insights/<insights_operator_pod_name>:/var/lib/insights-operator ./insights-data 1

   1

   <insights_operator_pod_name>을 이전 명령의 Pod 이름 출력으로 바꿉니다.

프로세스

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
   # ...

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

프로세스

1. 이 템플릿을 사용하여 gather-job.yaml이라는 파일을 생성합니다.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: insights-operator-job
     annotations:
       config.openshift.io/inject-proxy: insights-operator
   spec:
     backoffLimit: 6
     ttlSecondsAfterFinished: 600
     template:
       spec:
         restartPolicy: OnFailure
         serviceAccountName: operator
         nodeSelector:
           beta.kubernetes.io/os: linux
           node-role.kubernetes.io/master: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/master
           operator: Exists
         - effect: NoExecute
           key: node.kubernetes.io/unreachable
           operator: Exists
           tolerationSeconds: 900
         - effect: NoExecute
           key: node.kubernetes.io/not-ready
           operator: Exists
           tolerationSeconds: 900
         volumes:
         - name: snapshots
           emptyDir: {}
         - name: service-ca-bundle
           configMap:
             name: service-ca-bundle
             optional: true
         initContainers:
         - name: insights-operator
           image: quay.io/openshift/origin-insights-operator:latest
           terminationMessagePolicy: FallbackToLogsOnError
           volumeMounts:
           - name: snapshots
             mountPath: /var/lib/insights-operator
           - name: service-ca-bundle
             mountPath: /var/run/configmaps/service-ca-bundle
             readOnly: true
           ports:
           - containerPort: 8443
             name: https
           resources:
             requests:
               cpu: 10m
               memory: 70Mi
           args:
           - gather
           - -v=4
           - --config=/etc/insights-operator/server.yaml
         containers:
           - name: sleepy
             image: quay.io/openshift/origin-base:latest
             args:
               - /bin/sh
               - -c
               - sleep 10m
             volumeMounts: [{name: snapshots, mountPath: /var/lib/insights-operator}]

2. insights-operator 이미지 버전을 복사합니다.

   $ oc get -n openshift-insights deployment insights-operator -o yaml

   출력 예

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: insights-operator
     namespace: openshift-insights
   # ...
   spec:
     template:
   # ...
       spec:
         containers:
         - args:
   # ...
           image: registry.ci.openshift.org/ocp/4.15-2023-10-12-212500@sha256:a0aa581400805ad0... 1
   # ...

   1

   insights-operator 이미지 버전을 지정합니다.

3. gather-job.yaml에 이미지 버전을 붙여 넣습니다.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: insights-operator-job
   # ...
   spec:
   # ...
     template:
       spec:
       initContainers:
       - name: insights-operator
         image: image: registry.ci.openshift.org/ocp/4.15-2023-10-12-212500@sha256:a0aa581400805ad0... 1
         terminationMessagePolicy: FallbackToLogsOnError
         volumeMounts:

   1

   기존 값을 insights-operator 이미지 버전으로 교체합니다.

4. 수집 작업을 생성합니다.

   $ oc apply -n openshift-insights -f gather-job.yaml

5. 작업 Pod의 이름을 찾습니다.

   $ oc describe -n openshift-insights job/insights-operator-job

   출력 예

   Name:             insights-operator-job
   Namespace:        openshift-insights
   # ...
   Events:
     Type    Reason            Age    From            Message
     ----    ------            ----   ----            -------
     Normal  SuccessfulCreate  7m18s  job-controller  Created pod: insights-operator-job-<your_job>

   다음과 같습니다.

   insights-operator-job-<your_job >은 Pod의 이름입니다.

6. 작업이 완료되었는지 확인합니다.

   $ oc logs -n openshift-insights insights-operator-job-<your_job> insights-operator

   출력 예

   I0407 11:55:38.192084       1 diskrecorder.go:34] Wrote 108 records to disk in 33ms

7. 생성된 아카이브를 저장합니다.

   $ oc cp openshift-insights/insights-operator-job-<your_job>:/var/lib/insights-operator ./insights-data

8. 작업을 정리합니다.

   $ oc delete -n openshift-insights job insights-operator-job

프로세스

1. dockerconfig.json 파일을 다운로드합니다.

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. dockerconfig.json 파일에서 "cloud.openshift.com" "auth" 토큰을 복사합니다.

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "<your_token>",
         "email": "asd@redhat.com"
       }
   }

3. console.redhat.com에 아카이브를 업로드합니다.

   $ curl -v -H "User-Agent: insights-operator/one10time200gather184a34f6a168926d93c330 cluster/<cluster_id>" -H "Authorization: Bearer <your_token>" -F "upload=@<path_to_archive>; type=application/vnd.redhat.openshift.periodic+tar" https://console.redhat.com/api/ingress/v1/upload

   여기서 <cluster_id>는 클러스터 ID이며 <your_token>은 풀 시크릿의 토큰이며 <path_to_archive>는 Insights Operator 아카이브의 경로입니다.

   작업이 성공하면 명령은 "request_id" 및 "account_number"를 반환합니다.

   출력 예

   * Connection #0 to host console.redhat.com left intact
   {"request_id":"393a7cf1093e434ea8dd4ab3eb28884c","upload":{"account_number":"6274079"}}%

검증 단계

1. https://console.redhat.com/openshift로 로그인합니다.
2. 왼쪽 창에서 Cluster List 메뉴를 클릭합니다.
3. 클러스터 이름을 클릭하여 클러스터의 세부 사항을 표시합니다.

4. 클러스터의 Insights 권고 탭을 엽니다.

   업로드에 성공하면 탭에 다음 중 하나가 표시됩니다.

   • 클러스터에서 모든 권장 사항을 통과: Insights 권고에서 문제가 발견되지 않은 경우 표시됩니다.
   • Insights 권고에서 감지한 문제 목록으로 위험 (낮음, 중간, 중요 및 심각)에 따라 우선 순위가 지정됩니다.

프로세스

1. 워크로드 → 시크릿으로 이동합니다.
2. openshift-config 프로젝트를 선택합니다.
3. 이름으로 검색 필드를 사용하여 지원 시크릿을 검색합니다. 존재하지 않는 경우 생성 → 키/값 시크릿을 클릭하여 생성합니다.
4. 옵션 메뉴를 클릭한 다음 시크릿 편집을 클릭합니다.
5. 키/값 추가 클릭
6. 값이 true인 enableGlobalObfuscation이라는 키를 생성하고 저장을 클릭합니다.
7. 워크로드 → Pod로 이동합니다.
8. openshift-insights 프로젝트를 선택합니다.
9. insights-operator pod를 찾습니다.
10. insights-operator pod를 다시 시작하려면 옵션 메뉴 를 클릭한 다음 Pod 삭제를 클릭합니다.

검증

1. 워크로드 → 시크릿으로 이동합니다.
2. openshift-insights 프로젝트를 선택합니다.
3. 이름으로 검색 필드를 사용하여 난독화-translation-table 시크릿을 검색합니다.

프로세스

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

5. 파일의 sca 특성을 interval: 2h 로 설정하여 2시간마다 콘텐츠를 가져옵니다.

   apiVersion: v1
   kind: ConfigMap
   # ...
   data:
     config.yaml: |
       sca:
         interval: 2h
   # ...

6. 저장을 클릭합니다. insights-config config-map 세부 정보 페이지가 열립니다.
7. config.yaml sca 속성 값이 interval: 2h 로 설정되어 있는지 확인합니다.

프로세스

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

5. 파일에서 sca 속성을 disabled: true 로 설정합니다.

   apiVersion: v1
   kind: ConfigMap
   # ...
   data:
     config.yaml: |
       sca:
         disabled: true
   # ...

6. 저장을 클릭합니다. insights-config config-map 세부 정보 페이지가 열립니다.
7. config.yaml sca 속성 값이 disabled: true 로 설정되어 있는지 확인합니다.

프로세스

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

5. 파일에서 sca 속성을 disabled: false 로 설정합니다.

   apiVersion: v1
   kind: ConfigMap
   # ...
   data:
     config.yaml: |
       sca:
         disabled: false
   # ...

6. 저장을 클릭합니다. insights-config config-map 세부 정보 페이지가 열립니다.
7. config.yaml sca 속성 값이 disabled: false 로 설정되어 있는지 확인합니다.

프로세스

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

   참고

   클러스터가 연결이 끊긴 환경에 있는 경우 추가 단계를 수행해야 합니다. 미러 레지스트리에 신뢰할 수 있는 CA가 있는 경우 먼저 신뢰할 수 있는 CA를 클러스터에 추가해야 합니다. 연결이 끊긴 환경의 모든 클러스터에 대해 기본 must-gather 이미지를 이미지 스트림으로 가져와야 합니다.

   $ oc import-image is/must-gather -n openshift

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

   $ oc adm must-gather

   중요

   연결이 끊긴 환경에 있는 경우 --image 플래그를 must-gather의 일부로 사용하여 페이로드 이미지를 가리킵니다.

   참고

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

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

      참고

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

3. 작업 디렉토리에서 생성된 must-gather 디렉토리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/를 실제 디렉터리 이름으로 교체하십시오.

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.16.4 2

   1

   기본 OpenShift Container Platform must-gather 이미지

   2

   OpenShift Virtualization의 must-gather 이미지

   must-gather 툴을 추가 인수와 함께 사용하여 클러스터의 OpenShift 로깅 및 Red Hat OpenShift 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}')

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

   ├── cluster-logging
   │  ├── clo
   │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
   │  │  ├── clusterlogforwarder_cr
   │  │  ├── cr
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── logforwarding_cr
   │  ├── collector
   │  │  ├── fluentd-2tr64
   │  ├── 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
      │  │  │  ├── elasticsearch-im-app-1596020400-gm6nl.1626341a296c16a1.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
      │  │  │  ├── elasticsearch-im-infra-1596020400-v98tk.1626341a2d821069.yaml
      │  │  │  ├── elasticsearch-im-app-1596020400-cc5vc.1626341a3019b238.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-s8d5s.1626341a31f7b315.yaml
      │  │  │  ├── elasticsearch-im-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
      │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
      │  │  ├── elasticsearch-im-app-1596030300-bpgcx
      │  │  │  ├── elasticsearch-im-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
         ├── ...

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

   1

   기본 OpenShift Container Platform must-gather 이미지

   2

   KubeVirt의 must-gather 이미지

4. 작업 디렉토리에서 생성된 must-gather 디렉토리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/를 실제 디렉터리 이름으로 교체하십시오.

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

프로세스

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

   $ oc adm must-gather -- gather_network_logs

   참고

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

2. 작업 디렉토리에서 생성된 must-gather 디렉토리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1

   1

   must-gather-local.472290403699006248 을 실제 디렉터리 이름으로 교체합니다.

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

1. Ignition 구성 파일이 생성됩니다.
2. 부트스트랩 머신이 부팅되고 컨트롤 플레인 머신을 부팅하는 데 필요한 원격 리소스 호스팅이 시작됩니다.
3. 컨트롤 플레인 머신은 부트스트랩 머신에서 원격 리소스를 가져오고 부팅을 완료합니다.
4. 컨트롤 플레인 머신은 부트스트랩 머신을 사용하여 etcd 클러스터를 만듭니다.
5. 부트스트랩 머신은 새로운 etcd 클러스터를 사용하여 임시 Kubernetes 컨트롤 플레인을 시작합니다.
6. 임시 컨트롤 플레인은 프로덕션 컨트롤러 플레인을 컨트롤 플레인 머신에 예약합니다.
7. 임시 컨트롤 플레인이 종료되고 제어를 프로덕션 컨트롤 플레인에 전달합니다.
8. 부트스트랩 머신은 OpenShift Container Platform 구성 요소를 프로덕션 컨트롤 플레인에 추가합니다.
9. 설치 프로그램이 부트 스트랩 머신을 종료합니다.
10. 컨트롤 플레인이 작업자 노드를 설정합니다.
11. 컨트롤 플레인은 일련의 Operator 형태로 추가 서비스를 설치합니다.
12. 클러스터는 지원되는 환경에서 작업자 머신 생성을 포함하여 일상적인 작업에 필요한 나머지 구성 요소를 다운로드하고 구성합니다.

프로세스

1. haproxy systemd 서비스가 활성화되어 있는지 확인합니다.

   $ ssh <user_name>@<load_balancer> systemctl status haproxy

2. 로드 밸런서가 필요한 포트에서 수신하고 있는지 확인합니다. 다음 예에서는 포트 80, 443, 6443, 22623을 참조합니다.

   • RHEL (Red Hat Enterprise Linux) 6에서 실행되는 HAProxy 인스턴스의 경우 netstat 명령을 사용하여 포트 상태를 확인합니다.

     $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

   • RHEL (Red Hat Enterprise Linux) 7 또는 8에서 실행되는 HAProxy 인스턴스의 경우 ss 명령을 사용하여 포트 상태를 확인합니다.

     $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

     참고

     Red Hat Enterprise Linux(RHEL) 7 이상에서는 netstat 대신 ss 명령을 사용하는 것이 좋습니다. ss는 iproute 패키지에서 제공합니다. ss 명령에 대한 자세한 내용은 Red Hat Enterprise Linux (RHEL) 7 성능 조정 가이드를 참조하십시오.

3. 와일드 카드 DNS 레코드가 로드 밸런서로 해결되어 있는지 확인합니다.

   $ dig <wildcard_fqdn> @<dns_server>

프로세스

1. 설치가 진행되는 동안 설치 로그를 모니터링합니다.

   $ tail -f ~/<installation_directory>/.openshift_install.log

2. 부트스트랩 노드에서 bootkube.service journald 장치 로그를 모니터링합니다. 이를 통해 첫 번째 컨트롤 플레인의 부트 스트랩을 시각화할 수 있습니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   참고

   부트스트랩 노드의 bootkube.service 로그는 etcd connection rejectd 오류를 출력하고 부트스트랩 서버가 컨트롤 플레인 노드의 etcd에 연결할 수 없음을 나타냅니다. 각 컨트롤 플레인 노드에서 etcd를 시작하고 노드가 클러스터에 가입되면 오류가 중지됩니다.

3. 컨트롤 플레인 노드가 부팅된 후 kubelet.service journald 장치 로그를 모니터링합니다. 이를 통해 컨트롤 플레인 노드 에이전트 활동을 시각화할 수 있습니다.

   1. oc를 사용하여 로그를 모니터링합니다.

      $ oc adm node-logs --role=master -u kubelet

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

4. 컨트롤 플레인 노드가 부팅된 후 crio.service journald 장치 로그를 모니터링합니다. 이를 통해 컨트롤 플레인 노드 CRI-O 컨테이너 런타임 활동을 시각화할 수 있습니다.

   1. oc를 사용하여 로그를 모니터링합니다.

      $ oc adm node-logs --role=master -u crio

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

프로세스

1. 부트 스트랩 노드의 콘솔에 액세스할 경우 노드가 로그인 프롬프트에 도달할 때까지 콘솔을 모니터링합니다.

2. Ignition 파일 구성을 확인합니다.

   • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우:

     1. 부트 스트랩 노드 Ignition 파일 URL을 확인합니다. <http_server_fqdn>을 HTTP 서버의 정규화된 도메인 이름으로 바꿉니다.

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

        1

        -I 옵션은 헤더만 반환합니다. 지정된 URL에서 Ignition 파일을 사용할 수있는 경우 명령은 200 OK 상태를 반환합니다. 사용할 수없는 경우 명령은 404 file not found를 반환합니다.

     2. 부트 스트랩 노드에서 Ignition 파일을 수신했는지 확인하려면 제공 호스트에서 HTTP 서버 로그를 쿼리합니다. 예를 들어 Apache 웹 서버를 사용하여 Ignition 파일을 제공하는 경우 다음 명령을 입력합니다.

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        부트 스트랩 Ignition 파일이 수신되면 연결된 HTTP GET 로그 메시지에 요청이 성공했음을 나타내는 200 OK 성공 상태가 포함됩니다.

     3. Ignition 파일이 수신되지 않은 경우 Ignition 파일이 존재하고 제공 호스트에 대한 적절한 파일 및 웹 서버 권한이 있는지 직접 확인합니다.

   • 클라우드 공급자 메커니즘을 사용하여 초기 배포의 일부로 호스트에 Ignition 구성 파일을 삽입하는 경우:

     1. 부트 스트랩 노드의 콘솔을 확인하고 부트 스트랩 노드 Ignition 파일을 삽입하는 메커니즘이 올바르게 작동하고 있는지 확인합니다.
3. 부트 스트랩 노드에 할당된 저장 장치의 가용성을 확인합니다.
4. 부트 스트랩 노드에 DHCP 서버의 IP 주소가 할당되었는지 확인합니다.

5. 부트 스트랩 노드에서 bootkube.service journald 장치 로그를 수집합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   참고

   부트스트랩 노드의 bootkube.service 로그는 etcd connection rejectd 오류를 출력하고 부트스트랩 서버가 컨트롤 플레인 노드의 etcd에 연결할 수 없음을 나타냅니다. 각 컨트롤 플레인 노드에서 etcd를 시작하고 노드가 클러스터에 가입되면 오류가 중지됩니다.

6. 부트 스트랩 노드 컨테이너에서 로그를 수집합니다.

   1. 부트 스트랩 노드에서 podman 을 사용하여 로그를 수집합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'

7. 부트 스트랩 프로세스가 실패한 경우 다음을 확인하십시오.

   • 설치 호스트에서 api.<cluster_name>.<base_domain>을 확인할 수 있습니다.
   • 로드 밸런서는 부트 스트랩 및 컨트롤 플레인 노드에 포트 6443 연결을 프록시합니다. 프록시 구성이 OpenShift Container Platform 설치 요구 사항을 충족하는지 확인합니다.

프로세스

1. 컨트롤 플레인 노드의 콘솔에 액세스할 경우 노드가 로그인 프롬프트에 도달할 때 까지 콘솔을 모니터링합니다. 설치 중에 Ignition 로그 메시지가 콘솔에 출력됩니다.

2. Ignition 파일 설정을 확인합니다.

   • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우:

     1. 컨트롤 플레인 노드의 Ignition 파일 URL을 확인합니다. <http_server_fqdn>을 HTTP 서버의 정규화된 도메인 이름으로 바꿉니다.

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1

        1

        -I 옵션은 헤더만 반환합니다. 지정된 URL에서 Ignition 파일을 사용할 수있는 경우 명령은 200 OK 상태를 반환합니다. 사용할 수없는 경우 명령은 404 file not found를 반환합니다.

     2. Ignition 파일이 컨트롤 플레인 노드에서 수신되었는지 확인하려면 제공 호스트에서 HTTP 서버 로그를 쿼리합니다. 예를 들어 Apache 웹 서버를 사용하여 Ignition 파일을 제공하는 경우 다음을 확인합니다.

        $ grep -is 'master.ign' /var/log/httpd/access_log

        마스터 Ignition 파일이 수신되면 연결된 HTTP GET 로그 메시지에 요청이 성공했음을 나타내는 200 OK 성공 상태가 포함됩니다.

     3. Ignition 파일이 수신되지 않은 경우 제공 호스트에 존재하는지 확인합니다. 적절한 파일 및 웹 서버 권한이 있는지 확인합니다.

   • 클라우드 공급자 메커니즘을 사용하여 초기 배포의 일부로 호스트에 Ignition 구성 파일을 삽입하는 경우:

     1. 컨트롤 플레인 노드의 콘솔을 확인하고 컨트롤 플레인 노드의 Ignition 파일을 삽입하는 메커니즘이 올바르게 작동하고 있는지 확인합니다.
3. 컨트롤 플레인 노드에 할당된 스토리지 장치의 가용성을 확인합니다.
4. 컨트롤 플레인 노드에 DHCP 서버의 IP 주소가 지정되었는지 확인합니다.

5. 컨트롤 플레인 노드 상태를 확인합니다.

   1. 컨트롤 플레인 노드 상태를 쿼리합니다.

      $ oc get nodes

   2. 컨트롤 플레인 노드 중 하나가 Ready 상태에 도달하지 않으면 자세한 노드 설명을 검색합니다.

      $ oc describe node <master_node>

      참고

      설치 문제로 인해 OpenShift Container Platform API가 실행되지 않거나 kubelet이 각 노드에서 실행되지 않는 경우 oc 명령을 실행할 수 없습니다.

6. OpenShift Container Platform SDN의 상태를 확인합니다.

   1. openshift-sdn 네임스페이스에서 sdn-controller, sdn, ovs 데몬 세트 상태를 검토합니다.

      $ oc get daemonsets -n openshift-sdn

   2. 해당 리소스가 Not found로 나열되어 있는 경우 openshift-sdn 네임스페이스의 Pod를 검토합니다.

      $ oc get pods -n openshift-sdn

   3. openshift-sdn 네임스페이스에서 실패한 OpenShift Container Platform SDN Pod에 대한 로그를 검토합니다.

      $ oc logs <sdn_pod> -n openshift-sdn

7. 클러스터의 네트워크 구성 상태를 확인합니다.

   1. 클러스터의 네트워크 구성이 존재하는지 확인합니다.

      $ oc get network.config.openshift.io cluster -o yaml

   2. 설치 프로그램이 네트워크 구성을 만드는 데 실패한 경우 Kubernetes 매니페스트를 다시 생성하고 메시지 출력을 확인합니다.

      $ ./openshift-install create manifests

   3. openshift-network-operator 네임스페이스에서 Pod 상태를 검토하고 CNO(Cluster Network Operator)가 실행 중인지 확인합니다.

      $ oc get pods -n openshift-network-operator

   4. openshift-network-operator 네임스페이스에서 네트워크 Operator Pod 로그를 수집합니다.

      $ oc logs pod/<network_operator_pod_name> -n openshift-network-operator

8. 컨트롤 플레인 노드가 부팅된 후 kubelet.service journald 장치 로그를 모니터링합니다. 이를 통해 컨트롤 플레인 노드 에이전트 활동을 시각화할 수 있습니다.

   1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u kubelet

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      참고

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

9. 컨트롤 플레인 노드가 부팅 된 후 crio.service journald 장치 로그를 검색합니다. 이를 통해 컨트롤 플레인 노드 CRI-O 컨테이너 런타임 활동을 시각화할 수 있습니다.

   1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u crio

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

10. 컨트롤 플레인 노드의 /var/log/ 아래에있는 특정 하위 디렉터리에서 로그를 수집합니다.

    1. /var/log/ 하위 디렉토리에 포함된 로그 목록을 검색합니다. 다음 예제는 모든 컨트롤 플레인 노드의 /var/log/openshift-apiserver/에 있는 파일을 나열합니다.

       $ oc adm node-logs --role=master --path=openshift-apiserver

    2. /var/log/ 하위 디렉터리 내의 특정 로그를 확인합니다. 다음 예제는 모든 컨트롤 플레인 노드에서 /var/log/openshift-apiserver/audit.log 내용을 출력합니다.

       $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

    3. API가 작동하지 않는 경우 SSH를 사용하여 각 노드의 로그를 확인합니다. 다음은 /var/log/openshift-apiserver/audit.log 예제입니다.

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

11. SSH를 사용하여 컨트롤 플레인 노드 컨테이너 로그를 확인합니다.

    1. 컨테이너를 나열합니다.

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

    2. crictl를 사용하여 컨테이너의 로그를 검색합니다.

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

12. 컨트롤 플레인 노드 구성 문제가 발생하는 경우 MCO, MCO 엔드 포인트 및 DNS 레코드가 작동하는지 확인합니다. MCO (Machine Config Operator)는 설치 시 운영 체제 구성을 관리합니다. 또한 시스템 클럭의 정확성과 인증서의 유효성을 확인하합니다.

    1. MCO 엔드 포인트를 사용할 수 있는지 테스트합니다. <cluster_name>을 적절한 값으로 바꿉니다.

       $ curl https://api-int.<cluster_name>:22623/config/master

    2. 엔드 포인트가 응답하지 않는 경우 로드 밸런서 구성을 확인합니다. 엔드 포인트가 포트 22623에서 실행되도록 구성되었는지 확인합니다.

    3. MCO 엔드 포인트의 DNS 레코드가 구성되어 로드 밸런서 문제를 해결하고 있는지 확인합니다.

       1. 정의된 MCO 엔드 포인트 이름에 대한 DNS 조회를 실행합니다.

          $ dig api-int.<cluster_name> @<dns_server>

       2. 로드 밸런서에서 할당된 MCO IP 주소에 대한 역방향 조회를 실행합니다.

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. MCO가 부트 스트랩 노드에서 직접 작동하는지 확인합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

    5. 시스템 클럭은 부트 스트랩, 마스터 및 작업자 노드 간에 동기화되어야 합니다. 각 노드의 시스템 클럭 참조 시간 및 시간 동기화 통계를 확인합니다.

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 인증서의 유효성을 확인합니다.

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

프로세스

1. etcd Pod의 상태를 확인합니다.

   1. openshift-etcd 네임스페이스에서 Pod 상태를 검토합니다.

      $ oc get pods -n openshift-etcd

   2. openshift-etcd-operator 네임스페이스에서 Pod 상태를 검토합니다.

      $ oc get pods -n openshift-etcd-operator

2. 이전 명령으로 나열된 Pod 중 Running 또는 Completed 상태가 표시되지 않는 경우 Pod의 진단 정보를 수집합니다.

   1. Pod의 이벤트를 검토합니다.

      $ oc describe pod/<pod_name> -n <namespace>

   2. Pod의 로그를 검사합니다.

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

   3. Pod에 여러 컨테이너가 있는 경우 위의 명령에서 오류가 생성되고 컨테이너 이름이 오류 메시지에 제공됩니다. 각 컨테이너의 로그를 검사합니다.

      $ oc logs pod/<pod_name> -c <container_name> -n <namespace>

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

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

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

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

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

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

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

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

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

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

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

      참고

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

4. 컨트롤 플레인 노드에서 기본 및 보조 DNS 서버 연결을 확인합니다.

프로세스

1. API 서버의 DNS 레코드가 컨트롤 플레인 노드의 kubelet을 https://api-int.<cluster_name>.<base_domain>:6443으로 전송하는지 확인합니다. 레코드가 로드 밸런서를 참조하는지 확인합니다.
2. 로드 밸런서의 포트 6443 정의가 각 컨트롤 플레인 노드를 참조하는지 확인합니다.
3. DHCP에서 고유한 컨트롤 플레인 노드 호스트 이름이 지정되어 있는지 확인합니다.

4. 각 컨트롤 플레인 노드에서 kubelet.service journald 장치 로그를 검사합니다.

   1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u kubelet

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      참고

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

5. 컨트롤 플레인 노드 kubelet 로그에서 인증서 만료 메시지를 확인합니다.

   1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <master-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

프로세스

1. 작업자 노드의 콘솔에 액세스할 경우 노드가 로그인 프롬프트에 도달할 때 까지 콘솔을 모니터링합니다. 설치 중에 Ignition 로그 메시지가 콘솔에 출력됩니다.

2. Ignition 파일 설정을 확인합니다.

   • HTTP 서버를 사용하여 Ignition 구성 파일을 호스팅하는 경우:

     1. 작업자 노드의 Ignition 파일 URL을 확인합니다. <http_server_fqdn>을 HTTP 서버의 정규화된 도메인 이름으로 바꿉니다.

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

        1

        -I 옵션은 헤더만 반환합니다. 지정된 URL에서 Ignition 파일을 사용할 수있는 경우 명령은 200 OK 상태를 반환합니다. 사용할 수없는 경우 명령은 404 file not found를 반환합니다.

     2. Ignition 파일이 작업자 노드에서 수신 된 것을 확인하려면 HTTP 호스트의 HTTP 서버 로그를 쿼리합니다. 예를 들어 Apache 웹 서버를 사용하여 Ignition 파일을 제공하는 경우 다음을 확인합니다.

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        작업자 Ignition 파일이 수신되면 연결된 HTTP GET 로그 메시지에 요청이 성공했음을 나타내는 200 OK 성공 상태가 포함됩니다.

     3. Ignition 파일이 수신되지 않은 경우 제공 호스트에 존재하는지 확인합니다. 적절한 파일 및 웹 서버 권한이 있는지 확인합니다.

   • 클라우드 공급자 메커니즘을 사용하여 초기 배포의 일부로 호스트에 Ignition 구성 파일을 삽입하는 경우:

     1. 작업자 노드의 콘솔을 확인하고 작업자 노드의 Ignition 파일을 삽입하는 메커니즘이 올바르게 작동하고 있는지 확인합니다.
3. 작업자 노드에 할당된 스토리지 장치의 가용성을 확인합니다.
4. 작업자 노드에 DHCP 서버의 IP 주소가 지정되었는지 확인합니다.

5. 작업자 노드 상태를 확인합니다.

   1. 노드의 상태를 쿼리합니다.

      $ oc get nodes

   2. Ready 상태를 표시하지 않는 작업자 노드에 대한 자세한 노드 설명을 가져옵니다.

      $ oc describe node <worker_node>

      참고

      설치 문제로 인해 OpenShift Container Platform API가 실행되지 않거나 kubelet이 각 노드에서 실행되지 않는 경우 oc 명령을 실행할 수 없습니다.

6. 컨트롤 플레인 노드와 달리 작업자 노드는 Machine API Operator를 사용하여 배포 및 조정됩니다. Machine API Operator의 상태를 확인합니다.

   1. Machine API Operator Pod의 상태를 검토합니다.

      $ oc get pods -n openshift-machine-api

   2. Machine API Operator Pod의 상태가 Ready가 아닌 경우 Pod의 이벤트를 자세히 설명합니다.

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

   3. machine-api-operator 컨테이너 로그를 검사합니다. 컨테이너는 machine-api-operator Pod 내에서 실행됩니다.

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

   4. 또한 kube-rbac-proxy 컨테이너 로그도 검사합니다. 컨테이너는 machine-api-operator Pod 내에서도 실행됩니다.

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

7. 작업자 노드가 부팅된 후 작업자 노드에서 kubelet.service journald 장치 로그를 모니터링합니다. 이를 통해 작업자 노드 에이전트 활동을 시각화할 수 있습니다.

   1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=worker -u kubelet

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <worker-node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      참고

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

8. 작업자 노드가 부팅 된 후 crio.service journald 장치 로그를 검색합니다. 이를 통해 작업자 노드 CRI-O 컨테이너 런타임 활동을 시각화할 수 있습니다.

   1. oc를 사용하여 로그를 검색합니다.

      $ oc adm node-logs --role=worker -u crio

   2. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

9. 작업자 노드의 /var/log/ 아래에 있는 특정 하위 디렉토리에서 로그를 수집합니다.

   1. /var/log/ 하위 디렉토리에 포함된 로그 목록을 검색합니다. 다음 예제는 모든 작업자 노드의 /var/log/sssd/에있는 파일을 나열합니다.

      $ oc adm node-logs --role=worker --path=sssd

   2. /var/log/ 하위 디렉터리 내의 특정 로그를 확인합니다. 다음 예제는 모든 작업자 노드에서 /var/log/sssd/audit.log 컨텐츠를 출력합니다.

      $ oc adm node-logs --role=worker --path=sssd/sssd.log

   3. API가 작동하지 않는 경우 SSH를 사용하여 각 노드의 로그를 확인합니다. 다음은 /var/log/sssd/sssd.log의 예제입니다.

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

10. SSH를 사용하여 작업자 노드 컨테이너 로그를 확인합니다.

    1. 컨테이너를 나열합니다.

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. crictl를 사용하여 컨테이너의 로그를 검색합니다.

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

11. 작업자 노드 구성 문제가 발생하는 경우 MCO, MCO 엔드 포인트 및 DNS 레코드가 작동하는지 확인합니다. MCO (Machine Config Operator)는 설치 시 운영 체제 구성을 관리합니다. 또한 시스템 클럭의 정확성과 인증서의 유효성을 확인하합니다.

    1. MCO 엔드 포인트를 사용할 수 있는지 테스트합니다. <cluster_name>을 적절한 값으로 바꿉니다.

       $ curl https://api-int.<cluster_name>:22623/config/worker

    2. 엔드 포인트가 응답하지 않는 경우 로드 밸런서 구성을 확인합니다. 엔드 포인트가 포트 22623에서 실행되도록 구성되었는지 확인합니다.

    3. MCO 엔드 포인트의 DNS 레코드가 구성되어 로드 밸런서 문제를 해결하고 있는지 확인합니다.

       1. 정의된 MCO 엔드 포인트 이름에 대한 DNS 조회를 실행합니다.

          $ dig api-int.<cluster_name> @<dns_server>

       2. 로드 밸런서에서 할당된 MCO IP 주소에 대한 역방향 조회를 실행합니다.

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. MCO가 부트 스트랩 노드에서 직접 작동하는지 확인합니다. <bootstrap_fqdn>을 부트 스트랩 노드의 정규화된 도메인 이름으로 바꿉니다.

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

    5. 시스템 클럭은 부트 스트랩, 마스터 및 작업자 노드 간에 동기화되어야 합니다. 각 노드의 시스템 클럭 참조 시간 및 시간 동기화 통계를 확인합니다.

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 인증서의 유효성을 확인합니다.

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

프로세스

1. 설치가 끝나면 클러스터 Operator가 모두 사용 가능한 상태인지 확인합니다.

   $ oc get clusteroperators

2. 필요한 모든 CSR(인증서 서명 요청)이 모두 승인되었는지 확인합니다. 일부 노드는 Ready 상태로 이동하지 않을 수 있으며 보류 중인 CSR이 있는 경우 일부 클러스터 Operator를 사용하지 못할 수 있습니다.

   1. CSR의 상태를 검토하고 클러스터에 추가된 각 시스템에 대해 Pending 또는 Approved 상태의 클라이언트 및 서버 요청이 표시되어 있는지 확인합니다.

      $ oc get csr

      출력 예

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1

      클라이언트 요청 CSR.

      2

      서버 요청 CSR.

      예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.

   2. CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이 Pending 상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.

      참고

      CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 첫 번째 CSR을 승인한 후 후속 노드 클라이언트 CSR은 클러스터 kube-controller-manager에 의해 자동으로 승인됩니다.

      참고

      베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로 oc exec, oc rsh, oc logs 명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이 system:node 또는 system:admin 그룹의 node-bootstrapper 서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.

      • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

        $ oc adm certificate approve <csr_name> 1

        1

        <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

      • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

3. Operator 이벤트를 표시합니다.

   $ oc describe clusteroperator <operator_name>

4. Operator의 네임스페이스 내에서 Operator Pod의 상태를 검토합니다.

   $ oc get pods -n <operator_namespace>

5. 상태가 Running이 아닌 Pod에 대한 자세한 설명을 가져옵니다.

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

6. Pod 로그를 검사합니다.

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

7. Pod 기본 이미지 관련 문제가 발생하면 기본 이미지 상태를 검토합니다.

   1. 문제가 있는 Pod에서 사용되는 기본 이미지의 세부 정보를 가져옵니다.

      $ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>

   2. 기본 이미지 릴리스 정보를 나열합니다.

      $ oc adm release info <image_path>:<tag> --commits

프로세스

1. 부트스트랩 및 컨트롤 플레인 시스템에서 설치 로그를 가져오는데 필요한 명령을 생성합니다.

   • 설치 관리자 프로비저닝 인프라를 사용한 경우 설치 프로그램이 포함된 디렉터리로 변경하고 다음 명령을 실행합니다.

     $ ./openshift-install gather bootstrap --dir <installation_directory> 1

     1

     installation_directory는 ./openshift-install create cluster를 실행할 때 지정한 디렉터리입니다. 이 디렉터리에는 설치 프로그램이 생성한 OpenShift Container Platform 정의 파일이 포함되어 있습니다.

     설치 프로그램이 프로비저닝한 인프라의 경우 설치 프로그램은 클러스터에 대한 정보를 저장하므로 호스트 이름 또는 IP 주소를 지정할 필요가 없습니다.

   • 자체적으로 프로비저닝한 인프라를 사용한 경우 설치 프로그램이 포함된 디렉터리로 변경하고 다음 명령을 실행합니다.

     $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
         --bootstrap <bootstrap_address> \ 2
         --master <master_1_address> \ 3
         --master <master_2_address> \ 4
         --master <master_3_address> 5

     1

     installation_directory의 경우 ./openshift-install create cluster를 실행할 때 지정한 것과 동일한 디렉터리를 지정합니다. 이 디렉터리에는 설치 프로그램이 생성한 OpenShift Container Platform 정의 파일이 포함되어 있습니다.

     2

     <bootstrap_address>는 클러스터 부트스트랩 시스템의 정규화된 도메인 이름 또는 IP 주소입니다.

     3 4 5

     클러스터의 각 컨트롤 플레인 또는 마스터 시스템에 대해 <master_*_address>를 정규화된 도메인 이름 또는 IP 주소로 변경합니다.

     참고

     기본 클러스터에는 세 개의 컨트롤 플레인 시스템이 있습니다. 클러스터가 사용하는 수에 관계없이 표시된대로 모든 컨트롤 플레인 시스템을 나열합니다.

   출력 예

   INFO Pulling debug logs from the bootstrap machine
   INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

   설치 실패에 대한 Red Hat 지원 케이스를 만들 경우 압축된 로그를 케이스에 포함해야 합니다.

프로세스

1. kubelet은 각 노드에서 systemd 서비스를 사용하여 관리됩니다. 디버그 Pod 내에서 kubelet systemd 서비스를 쿼리하여 kubelet의 상태를 검토합니다.

   1. 노드의 디버그 Pod를 시작합니다.

      $ oc debug node/my-node

      참고

      컨트롤 플레인 노드에서 oc debug 를 실행하는 경우 /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs 디렉터리에서 관리 kubeconfig 파일을 찾을 수 있습니다.

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

      # chroot /host

      참고

      RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.16 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

   3. kubelet systemd 서비스가 노드에서 활성화되어 있는지 여부를 확인합니다.

      # systemctl is-active kubelet

   4. 더 자세한 kubelet.service 상태 요약을 출력합니다.

      # systemctl status kubelet

프로세스

1. OpenShift Container Platform 클러스터 노드에서 kubelet journald 장치 로그를 쿼리합니다. 다음 예제에서는 컨트롤 플레인 노드만 쿼리합니다.

   $ oc adm node-logs --role=master -u kubelet  1

   1

   다른 장치 로그를 쿼리하려면 kubelet을 적절하게 대체합니다.

2. 클러스터 노드의 /var/log/ 아래에있는 특정 하위 디렉터리에서 로그를 수집합니다.

   1. /var/log/ 하위 디렉토리에 포함된 로그 목록을 검색합니다. 다음 예제는 모든 컨트롤 플레인 노드의 /var/log/openshift-apiserver/에 있는 파일을 나열합니다.

      $ oc adm node-logs --role=master --path=openshift-apiserver

   2. /var/log/ 하위 디렉터리 내의 특정 로그를 확인합니다. 다음 예제는 모든 컨트롤 플레인 노드에서 /var/log/openshift-apiserver/audit.log 내용을 출력합니다.

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

   3. API가 작동하지 않는 경우 SSH를 사용하여 각 노드의 로그를 확인합니다. 다음은 /var/log/openshift-apiserver/audit.log 예제입니다.

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

      참고

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

프로세스

1. 디버그 Pod 내에서 노드의 crio systemd 서비스를 쿼리하여 CRI-O 상태를 검토합니다.

   1. 노드의 디버그 Pod를 시작합니다.

      $ oc debug node/my-node

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

      # chroot /host

      참고

      RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.16 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

   3. crio systemd 서비스가 노드에서 활성 상태인지 확인합니다.

      # systemctl is-active crio

   4. 보다 자세한 crio.service 상태 요약을 출력합니다.

      # systemctl status crio.service

프로세스

1. CRI-O journald 장치 로그를 수집합니다. 다음 예제는 클러스터 내의 모든 컨트롤 플레인 노드에서 로그를 수집합니다.

   $ oc adm node-logs --role=master -u crio

2. 특정 노드에서 CRI-O journald 장치 로그를 수집합니다.

   $ oc adm node-logs <node_name> -u crio

3. API가 작동하지 않으면 대신 SSH를 사용하여 로그를 확인합니다. <node>.<cluster_name>.<base_domain>을 적절한 값으로 바꿉니다.

   $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

   참고

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

프로세스

1. 노드에서 cordon을 사용합니다. 이는 노드가 Ready 상태가 되면 워크로드가 예약되지 않도록 하기 위한 것입니다. SchedulingDisabled가 상태 섹션에 있으면 예약이 비활성화되어 있음을 알 수 있습니다.

   $ oc adm cordon <node_name>

2. 노드를 cluster-admin으로 드레이닝합니다.

   $ oc adm drain <node_name> --ignore-daemonsets --delete-emptydir-data

   참고

   Pod 또는 Pod 템플릿의 terminationGracePeriodSeconds 속성은 정상 종료 기간을 제어합니다. 이 속성은 30초에 기본값으로 설정되지만 필요에 따라 각 애플리케이션에 맞게 사용자 지정할 수 있습니다. 90초 이상으로 설정하면 Pod가 SIGKILLed 로 표시되고 성공적으로 종료되지 않을 수 있습니다.

3. 노드가 반환되면 SSH 또는 콘솔을 통해 노드에 다시 연결합니다. 그런 다음 root 사용자에 연결합니다.

   $ ssh core@node1.example.com
   $ sudo -i

4. kubelet을 수동으로 중지합니다.

   # systemctl stop kubelet

5. 컨테이너 및 pod를 중지합니다.

   1. 다음 명령을 사용하여 HostNetwork 에 없는 Pod를 중지합니다. 제거를 통해 HostNetwork 에 있는 네트워킹 플러그인 pod를 사용하므로 먼저 제거해야 합니다.

      .. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

   2. 다른 모든 Pod를 중지합니다.

      # crictl rmp -fa

6. crio 서비스를 수동으로 중지합니다.

   # systemctl stop crio

7. 이러한 명령을 실행한 후 임시 스토리지를 완전히 초기화할 수 있습니다.

   # crio wipe -f

8. crio 및 kubelet 서비스를 시작합니다.

   # systemctl start crio
   # systemctl start kubelet

9. crio 및 kubelet 서비스가 시작되고 노드가 Ready 상태에 있으면 정리가 작동했는지 알 수 있습니다.

   $ oc get nodes

   출력 예

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.29.4

10. 노드를 예약 가능으로 표시합니다. SchedulingDisabled 상태가 더 이상 아닐 때 예약이 활성화되어 있음을 알 수 있습니다.

    $ oc adm uncordon <node_name>

    출력 예

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.29.4

프로세스

1. 다음 명령을 실행하여 어떤 서비스 단위가 실패했는지 표시합니다.

   $ systemctl --failed

2. 선택 사항: 개별 서비스 장치에서 다음 명령을 실행하여 자세한 정보를 확인합니다.

   $ journalctl -u <unit>.service

프로세스

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

   $ oc get subs -n <operator_namespace>

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

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

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
   # ...

프로세스

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

   $ oc get catalogsources -n openshift-marketplace

   출력 예

   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-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

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

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

   출력 예

   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
   # ...

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

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

   $ oc get pods -n openshift-marketplace

   출력 예

   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-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

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

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

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

   출력 예

   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

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

프로세스

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

   $ oc get clusteroperators

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

   $ oc get pod -n <operator_namespace>

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

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

4. Operator 문제가 노드와 관련된 경우 해당 노드에서 Operator 컨테이너 상태를 쿼리합니다.

   1. 노드의 디버그 Pod를 시작합니다.

      $ oc debug node/my-node

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

      # chroot /host

      참고

      RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.16 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

   3. 상태 및 관련 Pod ID를 포함하여 노드의 컨테이너에 대한 세부 정보를 나열합니다.

      # crictl ps

   4. 노드의 특정 Operator 컨테이너에 대한 정보를 나열합니다. 다음 예는 network-operator 컨테이너에 대한 정보를 나열합니다.

      # crictl ps --name network-operator

   5. 디버그 쉘을 종료합니다.

프로세스

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

   $ oc get pods -n <operator_namespace>

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

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

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

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

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

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

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

   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>

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

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

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

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

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

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

      참고

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

프로세스

1. Operator가 설치된 네임스페이스에서 Subscription 및 ClusterServiceVersion 오브젝트의 이름을 가져옵니다.

   $ oc get sub,csv -n <namespace>

   출력 예

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

2. 서브스크립션을 삭제합니다.

   $ oc delete subscription <subscription_name> -n <namespace>

3. 클러스터 서비스 버전을 삭제합니다.

   $ oc delete csv <csv_name> -n <namespace>

4. openshift-marketplace 네임스페이스에서 실패한 모든 작업 및 관련 구성 맵의 이름을 가져옵니다.

   $ oc get job,configmap -n openshift-marketplace

   출력 예

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. 작업을 삭제합니다.

   $ oc delete job <job_name> -n openshift-marketplace

   이렇게 하면 액세스할 수 없는 이미지를 가져오려는 Pod가 다시 생성되지 않습니다.

6. 구성 맵을 삭제합니다.

   $ oc delete configmap <configmap_name> -n openshift-marketplace

7. 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.

프로세스

1. "종료 중" 상태로 중단된 Operator와 관련된 네임스페이스가 있는지 확인합니다.

   $ oc get namespaces

   출력 예

   operator-ns-1                                       Terminating

2. 실패한 제거 후에도 여전히 존재하는 Operator와 관련된 CRD가 있는지 확인합니다.

   $ oc get crds

   참고

   CRD는 글로벌 클러스터 정의입니다. CRD와 관련된 실제 CR(사용자 정의 리소스) 인스턴스는 다른 네임스페이스에 있거나 글로벌 클러스터 인스턴스일 수 있습니다.

3. Operator에서 제공하거나 관리하는 CRD가 있고 제거 후 삭제해야 하는 CRD가 있는 경우 CRD를 삭제합니다.

   $ oc delete crd <crd_name>

4. 제거 후에도 여전히 존재하는 Operator와 관련된 나머지 CR 인스턴스가 있는지 확인하고 CR을 삭제합니다.

   1. 검색할 CR 유형은 제거 후 결정하기 어려울 수 있으며 Operator에서 관리하는 CRD를 알아야 할 수 있습니다. 예를 들어 EtcdCluster CRD를 제공하는 etcd Operator의 설치 제거 문제를 해결하는 경우 네임스페이스에서 나머지 EtcdCluster CR을 검색할 수 있습니다.

      $ oc get EtcdCluster -n <namespace_name>

      또는 모든 네임스페이스에서 검색할 수 있습니다.

      $ oc get EtcdCluster --all-namespaces

   2. 제거해야 하는 나머지 CR이 있는 경우 인스턴스를 삭제합니다.

      $ oc delete <cr_name> <cr_instance_name> -n <namespace_name>

5. 네임스페이스 삭제가 성공적으로 해결되었는지 확인합니다.

   $ oc get namespace <namespace_name>

   중요

   네임스페이스 또는 기타 Operator 리소스가 여전히 제거되지 않은 경우 Red Hat 지원팀에 문의하십시오.

6. 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.

프로세스

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

   $ oc project <project_name>

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

   $ oc get pods

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

   $ oc status

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

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

   $ skopeo inspect docker://<image_reference>

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

   $ oc edit deployment/my-deployment

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

   $ oc get pods -w

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

   $ oc get events

프로세스

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

   $ oc logs <pod_name>

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

   $ oc logs <pod_name> -c <container_name>

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

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

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

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

      출력 예

      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

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

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

      출력 예

      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

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

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

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

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

프로세스

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

   $ oc project <namespace>

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

   $ oc rsh <pod_name>  1

   1

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

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

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

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

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

   1

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

프로세스

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

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

      $ oc get deployment -n <project_name>

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

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

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

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

      $ oc get deploymentconfigs -n <project_name>

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

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

프로세스

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

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

   1

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

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

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

   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

   1

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

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

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

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

     참고

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

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

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

     참고

     또는 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>

프로세스

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

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

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

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

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

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

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

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

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

      참고

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

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

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

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

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

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

      참고

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

5. 컨테이너 내에서 진단 바이너리를 사용할 수 없는 경우 nsenter를 사용하여 컨테이너의 네임 스페이스에서 호스트의 진단 바이너리를 실행할 수 있습니다. 다음 예제는 호스트의 IP 바이너리를 사용하여 컨테이너의 네임 스페이스에서 ip ad를 실행합니다.

   1. 대상 노드에서 디버그 세션으로 들어갑니다. 이 단계는 <node_name>-debug라는 디버그 Pod를 인스턴스화합니다.

      $ oc debug node/my-cluster-node

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

      # chroot /host

      참고

      RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 OpenShift Container Platform 4.16 클러스터 노드는 변경할 수 없으며 Operator를 사용하여 클러스터 변경 사항을 적용합니다. SSH를 사용하여 클러스터 노드에 액세스하는 것은 권장되지 않습니다. 그러나 OpenShift Container Platform API를 사용할 수 없거나 kubelet이 대상 노드에서 제대로 작동하지 않는 경우 oc 작업이 영향을 받습니다. 이러한 상황에서 대신 ssh core @ <node>.<cluster_name>.<base_domain>을 사용하여 노드에 액세스할 수 있습니다.

   3. 대상 컨테이너 ID를 확인합니다.

      # crictl ps

   4. 컨테이너의 프로세스 ID를 확인합니다. 이 예에서 대상 컨테이너 ID는 a7fe32346b120입니다.

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

   5. 호스트의 ip 바이너리를 사용하여 컨테이너의 네임 스페이스에서 ip ad를 실행합니다. 이 예에서는 컨테이너의 프로세스 ID로 31150을 사용합니다. nsenter 명령은 대상 프로세스의 네임 스페이스를 입력하고 네임 스페이스에서 명령을 실행합니다. 이 경우 대상 프로세스는 컨테이너의 프로세스 ID이므로 ip ad 명령은 호스트의 컨테이너 네임 스페이스에서 실행됩니다.

      # nsenter -n -t 31150 -- ip ad

      참고

      컨테이너의 네임 스페이스 에서 호스트의 진단 바이너리를 실행하는 것은 디버그 노드와 같은 권한 있는 컨테이너를 사용하는 경우에만 가능합니다.

프로세스

1. C:\var\logs의 모든 디렉터리에 있는 로그를 보려면 다음 명령을 실행합니다.

   $ oc adm node-logs -l kubernetes.io/os=windows --path= \
       /ip-10-0-138-252.us-east-2.compute.internal containers \
       /ip-10-0-138-252.us-east-2.compute.internal hybrid-overlay \
       /ip-10-0-138-252.us-east-2.compute.internal kube-proxy \
       /ip-10-0-138-252.us-east-2.compute.internal kubelet \
       /ip-10-0-138-252.us-east-2.compute.internal pods

2. 동일한 명령을 사용하여 디렉터리의 파일을 나열하고 개별 로그 파일을 볼 수 있습니다. 예를 들어 kubelet 로그를 보려면 다음 명령을 실행합니다.

   $ oc adm node-logs -l kubernetes.io/os=windows --path=/kubelet/kubelet.log

프로세스

1. Windows 노드에 SSH로 연결하고 PowerShell로 이동합니다.

   C:\> powershell

2. 다음 명령을 실행하여 Docker 로그를 확인합니다.

   C:\> Get-EventLog -LogName Application -Source Docker

프로세스

1. 서비스 및 ServiceMonitor 리소스 구성에서 해당 라벨이 일치하는지 확인합니다.

   1. 서비스에 정의된 라벨을 가져옵니다. 다음 예제에서는 ns1 프로젝트의 prometheus-example-app 서비스를 쿼리합니다.

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

      출력 예

        labels:
          app: prometheus-example-app

   2. ServiceMonitor 리소스 구성의 matchLabels 정의가 이전 단계의 라벨 출력과 일치하는지 확인합니다. 다음 예제에서는 ns1 프로젝트의 prometheus-example-monitor 서비스 모니터를 쿼리합니다.

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

      출력 예

      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

      참고

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

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

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

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

      출력 예

      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

   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

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

      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

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

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

4. 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

   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
      # ...

   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"

      출력 예

              - --log-level=debug

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

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

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

      참고

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

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