5.16. 기타 문제
5.16.1. runtime network not ready 오류 해결 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 배포 후 다음과 같은 오류가 발생할 수 있습니다.
`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`
Cluster Network Operator는 설치 프로그램에서 생성된 특수 오브젝트에 대한 응답으로 네트워킹 구성 요소를 배포합니다. 컨트롤 플레인 (마스터) 노드가 시작된 후 부트스트랩 컨트롤 플레인이 중지되기 전에 설치 프로세스 초기에 실행됩니다. 컨트롤 플레인 (마스터) 노드를 가져오는 데 긴 지연 또는 apiserver 통신 문제와 같은 미묘한 설치 프로그램 문제를 나타낼 수 있습니다.
프로세스
openshift-network-operator네임 스페이스에서 Pod를 검사합니다.$ oc get all -n openshift-network-operatorNAME READY STATUS RESTARTS AGE pod/network-operator-69dfd7b577-bg89v 0/1 ContainerCreating 0 149mprovisioner노드에서 네트워크 구성이 존재하는지 확인합니다.$ kubectl get network.config.openshift.io cluster -oyamlapiVersion: 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: OVNKubernetes존재하지 않는 경우 설치 프로그램이 이를 생성하지 않았습니다. 설치 프로그램이 생성하지 않은 이유를 확인하려면 다음을 실행합니다.
$ openshift-install create manifestsnetwork-operator가 실행되고 있는지 확인합니다.$ kubectl -n openshift-network-operator get pods로그를 검색합니다.
$ kubectl -n openshift-network-operator logs -l "name=network-operator"3 개 이상의 컨트롤 플레인 (마스터) 노드가 있는 고가용성 클러스터에서 Operator는 리더의 선택을 실행하고 다른 Operator는 절전 모드로 전환합니다. 자세한 내용은 Troubleshooting을 참조하십시오.
클러스터를 배포한 후 다음과 같은 오류 메시지가 표시될 수 있습니다.
No disk found with matching rootDeviceHints
rootDeviceHints 오류 메시지와 일치하는 No disk found 를 해결하기 위해 임시 해결 방법은 rootDeviceHints 를 minSizeGigabytes: 300 로 변경하는 것입니다.
rootDeviceHints 설정을 변경한 후 CoreOS를 부팅한 다음 다음 명령을 사용하여 디스크 정보를 확인합니다.
$ udevadm info /dev/sda
DL360keygen 10 서버를 사용하는 경우 /dev/sda 장치 이름이 할당될 수 있는 SD 카드 슬롯이 있다는 점에 유의하십시오. 서버에 SD 카드가 없으면 충돌이 발생할 수 있습니다. 서버의 BIOS 설정에서 SD 카드 슬롯이 비활성화되어 있는지 확인합니다.
minSizeGigabytes 해결방법이 요구 사항을 충족하지 않는 경우 rootDeviceHints 를 /dev/sda 로 되돌려야 할 수 있습니다. 이러한 변경을 통해 ironic 이미지를 성공적으로 부팅할 수 있습니다.
이 문제를 해결하기 위한 대체 방법은 디스크의 직렬 ID를 사용하는 것입니다. 그러나 직렬 ID를 찾는 것은 어려울 수 있으며 구성 파일을 읽을 수 없게 만들 수 있습니다. 이 경로를 선택하는 경우 이전에 문서화한 명령을 사용하여 직렬 ID를 수집하여 구성에 통합해야 합니다.
5.16.3. DHCP를 통해 올바른 IPv6 주소를 얻지 못하는 클러스터 노드 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 노드가 DHCP를 통해 올바른 IPv6 주소를 얻지 못하는 경우 다음을 확인합니다.
- 예약 된 IPv6 주소가 DHCP 범위 밖에 있는지 확인합니다.
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]- 경로 알림 (Route Announcement)이 제대로 작동하는지 확인합니다.
- DHCP 서버가 IP 주소 범위를 제공하는 데 필요한 인터페이스에서 수신하고 있는지 확인합니다.
5.16.4. DHCP를 통해 올바른 호스트 이름을 얻지 못하는 클러스터 노드 링크 복사링크가 클립보드에 복사되었습니다!
IPv6 배포 중에 클러스터 노드는 DHCP를 통해 호스트 이름을 검색해야 합니다. 경우에 따라 NetworkManager가 호스트 이름을 즉시 할당하지 않을 수 있습니다. 컨트롤 플레인 (마스터) 노드는 다음과 같은 오류를 보고할 수 있습니다.
Failed Units: 2
NetworkManager-wait-online.service
nodeip-configuration.service
이 오류는 클러스터 노드가 DHCP 서버에서 호스트 이름을 받지 않고 부팅되었을 가능성이 있음을 나타냅니다. 이로 인해 kubelet이 localhost.localdomain 호스트 이름으로 부팅됩니다. 이 문제를 해결하려면 노드가 호스트 이름을 업데이트하도록 합니다.
프로세스
hostname을 검색합니다.[core@master-X ~]$ hostname호스트 이름이
localhost인 경우 다음 단계를 진행합니다.참고여기서
X는 컨트롤 플레인 노드 번호입니다.클러스터 노드가 DHCP 임대를 갱신하도록 합니다.
[core@master-X ~]$ sudo nmcli con up "<bare_metal_nic>"&
lt;bare_metal_nic>을baremetal네트워크에 해당하는 유선 연결로 바꿉니다.hostname다시 확인하십시오.[core@master-X ~]$ hostname호스트 이름이 여전히
localhost.localdomain인 경우NetworkManager를 다시 시작합니다.[core@master-X ~]$ sudo systemctl restart NetworkManager-
호스트 이름이 여전히
localhost.localdomain인 경우 몇 분 기다린 후 다시 확인하십시오. 호스트 이름이localhost.localdomain으로 남아 있으면 이전 단계를 반복합니다. nodeip-configuration서비스를 다시 시작합니다.[core@master-X ~]$ sudo systemctl restart nodeip-configuration.service이 서비스는 올바른 호스트 이름 참조를 사용하여
kubelet서비스를 재구성합니다.이전 단계에서 kubelet이 변경되었으므로 단위 파일 정의를 다시 로드하십시오.
[core@master-X ~]$ sudo systemctl daemon-reloadkubelet서비스를 다시 시작합니다.[core@master-X ~]$ sudo systemctl restart kubelet.servicekubelet이 올바른 호스트 이름으로 부팅되었는지 확인합니다.[core@master-X ~]$ sudo journalctl -fu kubelet.service
클러스터 가동 후 (예: 클러스터를 다시 시작) 클러스터 노드가 DHCP를 통해 올바른 호스트 이름을 얻지 못하는 경우 클러스터에 csr은 보류 처리됩니다. csr을 승인 하지 마십시오. 그렇지 않으면 다른 문제가 발생할 수 있습니다.
CSR 처리
클러스터에서 CSR을 가져옵니다.
$ oc get csr보류중인
CSR에Subject Name: localhost.localdomain이 포함되어 있는지 확인합니다.$ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -textSubject Name: localhost.localdomain이 포함된 모든csr을 제거합니다.$ oc delete csr <wrong_csr>
5.16.5. 루트가 엔드 포인트에 도달하지 않음 링크 복사링크가 클립보드에 복사되었습니다!
설치 프로세스 중에 VRRP (Virtual Router Redundancy Protocol) 충돌이 발생할 수 있습니다. 특정 클러스터 이름을 사용하여 클러스터 배포의 일부였던 이전에 사용된 OpenShift Container Platform 노드가 여전히 실행 중이지만 동일한 클러스터 이름을 사용하는 현재 OpenShift Container Platform 클러스터 배포의 일부가 아닌 경우 이러한 충돌이 발생할 수 있습니다. 예를 들어 클러스터는 클러스터 이름 openshift를 사용하여 3 개의 컨트롤 플레인 (마스터) 노드와 3 개의 작업자 노드를 배포합니다. 나중에 다른 설치에서 동일한 클러스터 이름 openshift를 사용하지만 이 재배포에서는 3 개의 컨트롤 플레인 (마스터) 노드 만 설치하여 이전 배포의 작업자 노드 3 개를 ON 상태로 유지합니다. 이로 인해 VRID (Virtual Router Identifier) 충돌 및 VRRP 충돌이 발생할 수 있습니다.
루트를 가져옵니다.
$ oc get route oauth-openshift서비스 엔드 포인트를 확인합니다.
$ oc get svc oauth-openshiftNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE oauth-openshift ClusterIP 172.30.19.162 <none> 443/TCP 59m컨트롤 플레인 (마스터) 노드에서 서비스에 연결을 시도합니다.
[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": 403provisioner노드에서authentication-operator오류를 식별합니다.$ oc logs deployment/authentication-operator -n openshift-authentication-operatorEvent(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"
해결책
- 모든 배포의 클러스터 이름이 고유한지 확인하여 충돌이 발생하지 않도록합니다.
- 동일한 클러스터 이름을 사용하는 클러스터 배포의 일부가 아닌 잘못된 노드 모두를 종료합니다. 그렇지 않으면 OpenShift Container Platform 클러스터의 인증 pod가 정상적으로 시작되지 않을 수 있습니다.
5.16.6. Firstboot 동안 Ignition 실패 링크 복사링크가 클립보드에 복사되었습니다!
Firstboot 중에 Ignition 설정이 실패할 수 있습니다.
프로세스
Ignition 설정이 실패한 노드에 연결합니다.
Failed Units: 1 machine-config-daemon-firstboot.servicemachine-config-daemon-firstboot서비스를 다시 시작합니다.[core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service
5.16.7. NTP가 동기화되지 않음 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터를 배포하려면 클러스터 노드 간의 NTP 시계가 동기화되어야합니다. 동기화된 시계가 없으면 시간 차이가 2 초보다 크면 클럭 드리프트로 인해 배포 실패할 수 있습니다.
프로세스
클러스터 노드의
AGE차이를 확인하십시오. 예를 들면 다음과 같습니다.$ oc get nodesNAME STATUS ROLES AGE VERSION master-0.cloud.example.com Ready master 145m v1.29.4 master-1.cloud.example.com Ready master 135m v1.29.4 master-2.cloud.example.com Ready master 145m v1.29.4 worker-2.cloud.example.com Ready worker 100m v1.29.4클럭 드리프트로 인한 일관성없는 시간 지연을 확인하십시오. 예를 들면 다음과 같습니다.
$ oc get bmh -n openshift-machine-apimaster-1 error registering master-1 ipmi://<out_of_band_ip>$ sudo timedatectlLocal 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
기존 클러스터에서 클럭 드리프트 처리
노드에 전송할
chrony.conf파일의 내용을 포함하여 Butane 구성 파일을 만듭니다. 다음 예제에서99-master-chrony.bu를 생성하여 파일을 컨트롤 플레인 노드에 추가합니다. 작업자 노드의 파일을 변경하거나 작업자 역할에 대해 이 절차를 반복할 수 있습니다.참고Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.
variant: openshift version: 4.16.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> iburst1 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
- &
lt;NTP_server>를 NTP 서버의 IP 주소로 바꿉니다.
Butane을 사용하여 노드에 전달할 구성이 포함된
MachineConfig파일99-master-chrony.yaml을 생성합니다.$ butane 99-master-chrony.bu -o 99-master-chrony.yamlMachineConfig오브젝트를 적용합니다.$ oc apply -f 99-master-chrony.yamlSystem clock synchronized값이 yes 인지 확인하십시오.$ sudo timedatectlLocal 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그런 다음 계속해서 클러스터를 만듭니다.