8.6. 문제 해결

프로세스

1. 부트스트랩 VM에 로그인합니다.

   $ ssh core@172.22.0.2

2. 컨테이너 로그를 확인하려면 다음을 실행합니다.

   [core@localhost ~]$ sudo podman logs -f <container-name>

   <container-name>을 ironic-api, ironic-conductor 또는 ironic-inspector 중 하나로 바꿉니다. 컨트롤 플레인 노드가 PXE를 통해 부팅되지 않는 문제가 발생하면 ironic-conductor Pod를 확인하십시오. ironic-conductor Pod는 IPMI를 통해 노드에 로그인을 시도하기 때문에 클러스터 노드 부팅 시도에 대한 가장 자세한 정보가 포함되어 있습니다.

프로세스

1. 부트스트랩 VM에 로그인합니다.

   $ ssh core@172.22.0.2

2. 부트스트랩 VM 내에서 ipa-downloader 및 coreos-downloader 컨테이너의 상태를 확인합니다.

   [core@localhost ~]$ sudo podman logs -f ipa-downloader

   [core@localhost ~]$ sudo podman logs -f coreos-downloader

   부트스트랩 VM이 이미지의 URL에 액세스할 수 없는 경우 curl 명령을 사용하여 VM이 이미지에 액세스할 수 있는지 확인합니다.

3. 배포 단계에서 모든 컨테이너가 시작되었는지 여부를 나타내는 bootkube 로그를 검사하려면 다음을 실행합니다.

   [core@localhost ~]$ journalctl -xe

   [core@localhost ~]$ journalctl -b -f -u bootkube.service

4. dnsmasq, mariadb, httpd 및 ironic를 포함한 모든 Pod가 실행 중인지 확인합니다.

   [core@localhost ~]$ sudo podman ps

5. Pod에 문제가 있는 경우 문제가있는 컨테이너의 로그를 확인합니다. ironic-api의 로그를 확인하려면 다음을 실행합니다.

   [core@localhost ~]$ sudo podman logs <ironic-api>

프로세스

1. openshift-network-operator 네임 스페이스에서 Pod를 검사합니다.

   $ oc get all -n openshift-network-operator

   NAME                                    READY STATUS            RESTARTS   AGE
   pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m

2. provisioner 노드에서 네트워크 구성이 존재하는지 확인합니다.

   $ kubectl get network.config.openshift.io cluster -oyaml

   apiVersion: config.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     serviceNetwork:
     - 172.30.0.0/16
     clusterNetwork:
     - cidr: 10.128.0.0/14
       hostPrefix: 23
     networkType: OpenShiftSDN

   존재하지 않는 경우 설치 프로그램이 이를 생성하지 않은 것입니다. 설치 프로그램이 생성하지 않은 이유를 확인하려면 다음을 실행합니다.

   $ openshift-install create manifests

3. network-operator가 실행되고 있는지 확인합니다.

   $ kubectl -n openshift-network-operator get pods

4. 로그를 검색합니다.

   $ kubectl -n openshift-network-operator logs -l "name=network-operator"

   3 개 이상의 컨트롤 플레인 (마스터) 노드가 있는 고가용성 클러스터에서 Operator는 리더의 선택을 실행하고 다른 Operator는 절전 모드로 전환합니다. 자세한 내용은 Troubleshooting을 참조하십시오.

1. 예약 된 IPv6 주소가 DHCP 범위 밖에 있는지 확인합니다.

2. DHCP 서버의 IP 주소 예약에서 예약에 올바른 DHCP 고유 식별자 (DUID)가 지정되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

   # This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC
   id:00:03:00:01:18:db:f2:8c:d5:9f,openshift-master-1,[2620:52:0:1302::6]

3. 경로 알림 (Route Announcement)이 제대로 작동하는지 확인합니다.
4. DHCP 서버가 IP 주소 범위를 제공하는 데 필요한 인터페이스에서 수신하고 있는지 확인합니다.

프로세스

1. hostname을 검색합니다.

   [core@master-X ~]$ hostname

   호스트 이름이 localhost인 경우 다음 단계를 진행합니다.

   참고

   여기서 X는 컨트롤 플레인 노드(마스터 노드라고도 함) 번호입니다.

2. 클러스터 노드가 DHCP 임대를 갱신하도록 합니다.

   [core@master-X ~]$ sudo nmcli con up "<bare-metal-nic>"

   <bare-metal-nic>을 baremetal 네트워크에 해당하는 유선 연결로 바꿉니다.

3. hostname 다시 확인하십시오.

   [core@master-X ~]$ hostname

4. 호스트 이름이 여전히 localhost.localdomain인 경우 NetworkManager를 다시 시작합니다.

   [core@master-X ~]$ sudo systemctl restart NetworkManager

5. 호스트 이름이 여전히 localhost.localdomain 인 경우 몇 분 기다린 후 다시 확인하십시오. 호스트 이름이 localhost.localdomain으로 남아 있으면 이전 단계를 반복합니다.

6. nodeip-configuration 서비스를 다시 시작합니다.

   [core@master-X ~]$ sudo systemctl restart nodeip-configuration.service

   이 서비스는 올바른 호스트 이름 참조를 사용하여 kubelet 서비스를 재구성합니다.

7. 이전 단계에서 kubelet이 변경되었으므로 단위 파일 정의를 다시 로드하십시오.

   [core@master-X ~]$ sudo systemctl daemon-reload

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

   [core@master-X ~]$ sudo systemctl restart kubelet.service

9. kubelet 이 올바른 호스트 이름으로 부팅되었는지 확인합니다.

   [core@master-X ~]$ sudo journalctl -fu kubelet.service

CSR 처리

1. 클러스터에서 CSR을 가져옵니다.

   $ oc get csr

2. 보류중인 CSR 에 Subject Name: localhost.localdomain이 포함되어 있는지 확인합니다.

   $ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text

3. Subject Name: localhost.localdomain이 포함된 모든 csr을 제거합니다.

   $ oc delete csr <wrong_csr>

1. 루트를 가져옵니다.

   $ oc get route oauth-openshift

2. 서비스 엔드 포인트를 확인합니다.

   $ oc get svc oauth-openshift

   NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
   oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m

3. 컨트롤 플레인 (마스터) 노드에서 서비스에 연결을 시도합니다.

   [core@master0 ~]$ curl -k https://172.30.19.162

   {
     "kind": "Status",
     "apiVersion": "v1",
     "metadata": {
     },
     "status": "Failure",
     "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
     "reason": "Forbidden",
     "details": {
     },
     "code": 403

4. provisioner 노드에서 authentication-operator 오류를 식별합니다.

   $ oc logs deployment/authentication-operator -n openshift-authentication-operator

   Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"

해결책

1. 모든 배포의 클러스터 이름이 고유한지 확인하여 충돌이 발생하지 않도록합니다.
2. 동일한 클러스터 이름을 사용하는 클러스터 배포의 일부가 아닌 잘못된 노드 모두를 종료합니다. 그렇지 않으면 OpenShift Container Platform 클러스터의 인증 pod가 정상적으로 시작되지 않을 수 있습니다.

프로세스

1. Ignition 설정이 실패한 노드에 연결합니다.

   Failed Units: 1
     machine-config-daemon-firstboot.service

2. machine-config-daemon-firstboot 서비스를 다시 시작합니다.

   [core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service

프로세스

1. 클러스터 노드의 AGE 차이를 확인하십시오. 예를 들면 다음과 같습니다.

   $ oc get nodes

   NAME                         STATUS   ROLES    AGE   VERSION
   master-0.cloud.example.com   Ready    master   145m   v1.16.2
   master-1.cloud.example.com   Ready    master   135m   v1.16.2
   master-2.cloud.example.com   Ready    master   145m   v1.16.2
   worker-2.cloud.example.com   Ready    worker   100m   v1.16.2

2. 클럭 드리프트로 인한 일관성없는 시간 지연을 확인하십시오. 예를 들면 다음과 같습니다.

   $ oc get bmh -n openshift-machine-api

   master-1   error registering master-1  ipmi://<out-of-band-ip>

   $ sudo timedatectl

                  Local time: Tue 2020-03-10 18:20:02 UTC
              Universal time: Tue 2020-03-10 18:20:02 UTC
                    RTC time: Tue 2020-03-10 18:36:53
                   Time zone: UTC (UTC, +0000)
   System clock synchronized: no
                 NTP service: active
             RTC in local TZ: no

기존 클러스터에서 클럭 드리프트 처리

1. 노드에 전송할 chrony.conf 파일의 내용을 포함하여 Butane 구성 파일을 만듭니다. 다음 예제에서 99-master-chrony.bu를 생성하여 파일을 컨트롤 플레인 노드에 추가합니다. 작업자 노드의 파일을 변경하거나 작업자 역할에 대해 이 절차를 반복할 수 있습니다.

   참고

   Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

   variant: openshift
   version: 4.8.0
   metadata:
     name: 99-master-chrony
     labels:
       machineconfiguration.openshift.io/role: master
   storage:
     files:
     - path: /etc/chrony.conf
       mode: 0644
       overwrite: true
       contents:
         inline: |
           server <NTP-server> iburst 1
           stratumweight 0
           driftfile /var/lib/chrony/drift
           rtcsync
           makestep 10 3
           bindcmdaddress 127.0.0.1
           bindcmdaddress ::1
           keyfile /etc/chrony.keys
           commandkey 1
           generatecommandkey
           noclientlog
           logchange 0.5
           logdir /var/log/chrony

   1

   <NTP-server>를 NTP 서버의 IP 주소로 바꿉니다.

2. Butane을 사용하여 노드에 전달할 구성이 포함된 MachineConfig 파일 99-master-chrony.yaml을 생성합니다.

   $ butane 99-master-chrony.bu -o 99-master-chrony.yaml

3. MachineConfig 오브젝트를 적용합니다.

   $ oc apply -f 99-master-chrony.yaml

4. System clock synchronized 값이 yes 인지 확인하십시오.

   $ sudo timedatectl

                  Local time: Tue 2020-03-10 19:10:02 UTC
              Universal time: Tue 2020-03-10 19:10:02 UTC
                    RTC time: Tue 2020-03-10 19:36:53
                   Time zone: UTC (UTC, +0000)
   System clock synchronized: yes
                 NTP service: active
             RTC in local TZ: no

   배포 전에 클럭 동기화를 설정하려면 매니페스트 파일을 생성하고이 파일을 openshift 디렉터리에 추가합니다. 예를 들면 다음과 같습니다.

   $ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml

   그런 다음 계속해서 클러스터를 만듭니다.